Stimare la pianificazione delle prestazioni e della capacità per il flusso di lavoro in SharePoint Server 2010

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

In questo articolo sulla pianificazione delle prestazioni e della capacità vengono fornite indicazioni sull'effetto dell'utilizzo del flusso di lavoro sulle topologie in cui viene eseguito Microsoft SharePoint Server 2010.

Per informazioni generali sulla pianificazione della capacità di SharePoint Server 2010, vedere Gestione di prestazioni e capacità (SharePoint Server 2010).

Sommario

• Caratteristiche della farm di testing

• Risultati dei test

• Suggerimenti

• Risoluzione dei problemi

Caratteristiche della farm di testing

Nelle sezioni successive verranno descritte le caratteristiche della farm di testing.

• Set di dati

• Carico di lavoro

• Hardware, impostazioni e topologia

Set di dati

Per ottenere i benchmark, la maggior parte dei test è stata eseguita su un sito del team predefinito in un'unica raccolta siti della farm. I test con avvio manuale hanno avviato flussi di lavoro tramite un elenco con 8.000 voci.

Carico di lavoro

Il testing per questo scenario consente di stimare le risposte delle diverse configurazioni della farm alle modifiche apportate alle variabili seguenti:

• Effetto del numero di server front-end sulla velocità effettiva per l'avvio manuale di flussi di lavoro dichiarativi su più computer

• Effetto del numero di server front-end sulla velocità effettiva per l'avvio automatico di flussi di lavoro dichiarativi in corrispondenza della creazione di voci su più computer

• Effetto del numero di server front-end sulla velocità effettiva per il completamento di attività su più computer

I valori specifici della capacità e delle prestazioni presentati in questo articolo sono diversi da quelli degli ambienti reali. I valori presentati hanno lo scopo di fornire un punto di partenza per la progettazione di un ambiente con scalabilità appropriata. Dopo aver completato la progettazione iniziale del sistema, testare la configurazione per determinare se sarà in grado di supportare i fattori specifici del proprio ambiente.

In questa sezione vengono definiti gli scenari di testing e viene illustrato il processo di verifica utilizzato per ogni scenario. Per informazioni dettagliate, ad esempio i risultati dei test e i parametri specifici, vedere la sezione dedicata ai risultati di ogni test più avanti in questo articolo.

Hardware, impostazioni e topologia

Le topologie utilizzate per questi test utilizzano un solo computer per il database del contenuto e da uno a quattro computer front-end con l'installazione predefinita di SharePoint Server 2010. I flussi di lavoro utilizzati in questi test non sono disponibili in Microsoft SharePoint Foundation 2010, tuttavia i risultati possono essere utilizzati per valutare scenari simili in tali distribuzioni. Il set di dati utilizzato per questi test contiene una raccolta siti con un solo sito basato sul modello Sito del team in un unico database del contenuto.

Per offrire informazioni dettagliate sui risultati dei test generali, sono state utilizzate diverse configurazioni di farm per i test. Le configurazioni di farm includono da uno a quattro server Web e un solo computer in cui viene eseguito Microsoft SQL Server 2008. I test sono stati eseguiti con un computer client. Il server di database e tutti i server Web sono a 64 bit, mentre il computer client è a 32 bit.

Nella tabella riportata di seguito vengono elencati i componenti hardware specifici utilizzati per i test.

Topologia della pianificazione della capacità del flusso di lavoro

Risultati dei test

Nelle tabelle riportate di seguito vengono mostrati i risultati dei test per il flusso di lavoro in SharePoint Server 2010. Per ogni gruppo di test sono state modificate solo alcune variabili specifiche per illustrare l'effetto progressivo sulle prestazioni della farm.

Tutti i test descritti in questo articolo sono stati effettuati senza un tempo interazione utente, ovvero un ritardo naturale tra operazioni consecutive. In un ambiente reale, ogni operazione è seguita da un ritardo dovuto al tempo necessario all'utente per eseguire il passaggio successivo dell'attività. Durante il test, invece, ogni operazione è seguita immediatamente da quella successiva, il che provoca un carico continuo sulla farm. Questo carico può generare conflitti tra database e altri fattori che possono avere un effetto negativo sulle prestazioni.

Effetto della scalabilità del server Web sulla velocità effettiva

I seguenti test sulla velocità effettiva sono stati eseguiti con il flusso di lavoro di approvazione incluso in SharePoint Server 2010. L'associazione del flusso di lavoro assegna una sola attività e tutte le istanze vengono eseguite su un unico elenco. Ogni istanza di questo flusso di lavoro crea gli elementi seguenti nel database del contenuto:

• Una voce nella tabella Flussi di lavoro per archiviare lo stato del flusso di lavoro

• Cinque voci di elenco secondarie (un'attività e quattro elementi della cronologia)

• Quattro ricevitori di eventi per gestire gli eventi nell'elemento padre e nell'attività del flusso di lavoro

La soglia per il posticipo dei flussi di lavoro è stata impostata su un valore molto elevato per evitare le code di operazioni del flusso di lavoro. Ogni test è stato eseguito cinque volte per una durata di cinque minuti.

Velocità effettiva del flusso di lavoro ad avvio manuale

Il test descritto nella tabella seguente illustra l'effetto dell'aggiunta di server front-end sulla velocità effettiva dell'avvio di flussi di lavoro in modo sincrono tramite il servizio Web. Questo test è stato eseguito con un carico di utenti di 25 utenti simultanei che chiamano il metodo StartWorkflow continuamente su Workflow.asmx e nessun altro carico sulla farm. Il carico di utenti era ottimale prima del verificarsi dell'eliminazione di richieste Web. L'elenco è stato precompilato con un massimo di 8.000 voci.

Nel grafico seguente viene illustrato come cambia la velocità effettiva. L'aggiunta di server front-end non influisce necessariamente sulla velocità effettiva della farm in modo lineare, ma provoca invece un picco intorno ai tre o quattro server front-end. Riepilogando, la velocità effettiva massima per l'avvio manuale dei flussi di lavoro è di circa 30 flussi di lavoro al secondo e l'aggiunta di più di quattro server front-end probabilmente non determina alcun cambiamento significativo.

Velocità effettiva del flusso di lavoro ad avvio manuale

Velocità effettiva dell'avvio automatico dei flussi di lavoro quando vengono create voci

Il test descritto nella tabella seguente illustra l'effetto dell'aggiunta di server front-end sulla velocità effettiva dell'avvio di flussi di lavoro in modo automatico quando vengono create voci. Questo test è stato eseguito con un carico di utenti di 150 utenti simultanei che chiamano continuamente il servizio Web dell'elenco per creare nuove voci di elenco in un unico elenco e nessun'altra operazione sul server. L'elenco è inizialmente vuoto.

Nel grafico seguente viene illustrato come cambia la velocità effettiva, che è molto simile a quella delle operazioni di avvio manuale. In modo analogo al test di avvio manuale, la velocità effettiva presenta un picco a circa tre o quattro server front-end con un massimo di circa 32 flussi di lavoro al secondo. L'aggiunta di più di tre o quattro server front-end non determina alcun cambiamento significativo.

Velocità effettiva del flusso di lavoro ad avvio automatico

Velocità effettiva di completamento dell'attività

Il test descritto nella tabella seguente illustra l'effetto dell'aggiunta di server front-end sulla velocità effettiva del completamento delle attività del flusso di lavoro. L'elenco delle attività utilizzato dai flussi di lavoro ad avvio automatico nel test precedente era quello utilizzato per completare le attività. Il test è stato eseguito con un carico di utenti di 25 utenti simultanei che chiamano il metodo AlterToDo continuamente su Workflow.asmx e nessun'altra operazione sul server. L'elenco è inizialmente vuoto.

Nel grafico seguente viene illustrato come cambia la velocità effettiva. In modo analogo al test di avvio manuale, la velocità effettiva presenta un picco a circa tre o quattro server front-end con un massimo di circa 32 flussi di lavoro al secondo. L'aggiunta di più di tre server front-end non determina alcun cambiamento significativo.

Velocità effettiva di completamento dell'attività

Effetto della dimensione dell'elenco e del numero di istanze del flusso di lavoro sulla velocità effettiva

Il test descritto nella tabella seguente illustra il variare della velocità effettiva con l'aumentare della dimensione dell'elenco e del numero di flussi di lavoro. La compilazione dei dati è stata effettuata eseguendo il test del flusso di lavoro ad avvio automatico continuamente fino alla creazione di 1 milione di voci nell'elenco e arrestando il processo in punti di arresto diversi durante il test per eseguire le misurazioni della velocità effettiva come per i test principali della velocità effettiva. I test sono stati eseguiti su una topologia 4x1.

Per mantenere l'affidabilità durante la compilazione dei dati, è stato necessario mantenere attivo l'accodamento dei flussi di lavoro per evitare di raggiungere il numero massimo di connessioni nel server di database. Se non sono disponibili connessioni e un'operazione del flusso di lavoro non è in grado di connettersi al database del contenuto, non sarà possibile eseguire l'operazione. Per ulteriori informazioni sull'accodamento dei flussi di lavoro, vedere la sezione Suggerimenti.

Velocità effettiva ad avvio automatico con l'aumentare del numero delle voci e dei flussi di lavoro

Per un solo elenco e una singola attività ed elenco della cronologia, la velocità effettiva diminuisce costantemente tra le 1.000 e le 100.000 voci. Tuttavia il peggioramento rallenta oltre tale punto. La diminuzione della velocità effettiva viene attribuita a molti fattori.

Un fattore è il numero di righe aggiunte a molte tabelle del database del contenuto per ogni istanza. Come indicato in precedenza, i flussi di lavoro creano numerose voci di elenco oltre a ricevitori di eventi registrati da ogni istanza del flusso di lavoro. Con l'aumentare della dimensione della tabella in diversi ambiti, l'aggiunta delle righe rallenta e la somma dei rallentamenti di tali aggiunte provoca un peggioramento più significativo rispetto a quanto si osserva con la sola creazione di voci di elenco.

La dimensione dell'elenco di attività provoca un ulteriore sovraccarico. Confrontando la velocità effettiva per i flussi di lavoro eseguiti su nuovi elenchi rispetto a quelli eseguiti su nuovi elenchi di attività, questi ultimi hanno un impatto maggiore sulle prestazioni. Ciò accade perché gli elenchi di attività registrano un numero maggiore di ricevitori di eventi rispetto alle voci degli elenchi principali. Nel grafico seguente vengono descritte le differenze.

Se si prevede di dover eseguire molti flussi di lavoro su elenchi di grandi dimensioni ed è necessaria una velocità effettiva maggiore di quella indicata come possibile nei test, è consigliabile valutare se l'elenco di attività può essere suddiviso tra associazioni del flusso di lavoro.

Suggerimenti

In questa sezione vengono forniti suggerimenti generali sulle prestazioni e sulla capacità che consentono di determinare le caratteristiche di capacità e prestazioni della topologia iniziale creata in modo da decidere se sarà necessario applicare la scalabilità orizzontale o verticale a tale topologia.

Per informazioni specifiche sui requisiti di sistema minimi e consigliati, vedere Requisiti hardware e software (SharePoint Server 2010).

Topologie con scalabilità orizzontale

È possibile aumentare la velocità effettiva dei flussi di lavoro applicando la scalabilità orizzontale o verticale su un massimo di quattro server Web. Ulteriori aumenti danno risultati non significativi. La velocità effettiva dei flussi di lavoro può essere limitata da impostazioni del flusso di lavoro correlate con le prestazioni. Tali impostazioni sono descritte in maggiore dettaglio in Accodamento dei flussi di lavoro e impostazioni correlate con le prestazioni.

Stima degli obiettivi di velocità effettiva

Molti fattori possono influire sulla velocità effettiva. Tali fattori includono il numero di utenti e il tipo, la complessità e la frequenza delle operazioni degli utenti. I flussi di lavoro più complessi che eseguono molte operazioni nel database del contenuto o registrano un numero maggiore di eventi vengono eseguiti più lentamente e utilizzano più risorse rispetto agli altri flussi di lavoro.

Il flusso di lavoro utilizzato in questo test crea numerose voci nel database del contenuto che vengono incorporate nelle attività. Se si prevede di utilizzare flussi di lavoro con un numero limitato di attività, è possibile aspettarsi caratteristiche di velocità effettiva simili. Se la maggior parte dei flussi di lavoro contiene operazioni molto leggere, la velocità effettiva può risultare maggiore. Se i flussi i lavoro saranno costituiti da molte attività o da operazioni back-end o di elaborazione complesse, è possibile prevedere una minore velocità effettiva.

Oltre a comprendere le operazioni eseguite dai flussi di lavoro, è necessario tenere presente dove verranno eseguiti tali flussi di lavoro e se verranno eseguiti su elenchi di grandi dimensioni, nel qual caso la velocità effettiva diminuirà nel tempo.

SharePoint Server 2010 può essere distribuito e configurato in diversi modi. Non esiste pertanto una soluzione semplice per stimare il numero di utenti che possono essere supportati da un determinato numero di server. È quindi necessario eseguire test nell'ambiente in uso prima di distribuire SharePoint Server 2010 in un ambiente di produzione.

Accodamento dei flussi di lavoro e impostazioni correlate con le prestazioni

Il flusso di lavoro utilizza un sistema di accodamento per controllare il carico relativo al flusso di lavoro sulle risorse della farm e sul database del contenuto. Utilizzando questo sistema, quando il numero di flussi di lavoro in esecuzione su un database raggiunge una soglia configurata dall'amministratore, le operazioni successive dei flussi di lavoro vengono aggiunte alla coda che deve essere eseguita dal servizio timer flussi di lavoro. Per impostazione predefinita, questo servizio riceve un batch di elementi di lavoro di un flusso di lavoro tramite processi timer ogni minuto.

Numerose impostazioni dell'amministratore della farm correlate direttamente o indirettamente con il meccanismo di accodamento influiscono sulle prestazioni e sulla scalabilità per il flusso di lavoro. Nelle sezioni riportate di seguito vengono descritti gli effetti di tali impostazioni e viene indicato come impostarle per soddisfare i requisiti in termini di prestazioni.

Informazioni sulle impostazioni di base delle code

Gli amministratori di farm possono definire le impostazioni seguenti per configurare le caratteristiche di base del sistema di accodamento.

• Soglia per il posticipo dei flussi di lavoro (Set-SPFarmConfig –WorkflowPostponeThreshold <intero>)

  Numero massimo di flussi di lavoro che può essere eseguito in un database del contenuto singolo prima che le richieste e le operazioni aggiuntive vengano accodate. I flussi di lavoro in coda hanno lo stato Avvio in corso. Si tratta di un'impostazione valida per tutta la farm con valore predefinito 15. Rappresenta il numero di operazioni del flusso di lavoro elaborate alla volta, non il numero massimo di flussi di lavoro che possono essere in corso. Man mano che le operazioni del flusso di lavoro vengono completate, le operazioni successive potranno essere eseguite.

• Dimensione del batch di recapito degli eventi del flusso di lavoro (Set-SPWorkflow –BatchSize <intero>)

  Il servizio timer flussi di lavoro è un'eccezione al limite della soglia per il posticipo e recupera i batch di voci dalla coda e li esegue uno alla volta. Tali batch possono superare la soglia per il posticipo. Il numero di elementi di lavoro ricevuti dal servizio per ogni esecuzione viene impostato tramite la proprietà BatchSize. La proprietà BatchSize può essere impostata una sola volta per ogni istanza del servizio. Il valore predefinito è 100. Quando viene eseguito su server applicazioni non configurati come server front-end, il servizio timer flussi di lavoro richiede l'impostazione di opzioni di configurazione del flusso di lavoro in Web.config nel database di configurazione. Questa operazione deve essere eseguita tramite uno script che chiama UpdateWorkflowConfigurationSettings() sull'oggetto SPWebApplication, che copierà le impostazioni di Web.config da un server front-end.

• Frequenza del processo timer flussi di lavoro (Set-SPTimerJob job-workflow –schedule <stringa>)

  La frequenza con cui viene eseguito il servizio timer flussi di lavoro può essere impostata tramite le opzioni del processo timer. Per impostazione predefinita, il servizio è configurato per essere eseguito ogni cinque minuti. Ne consegue che può verificarsi un ritardo di cinque minuti prima dell'elaborazione degli elementi di lavoro in cima alla coda.

  Nota

  Anche gli elementi di lavoro pianificati quali le date di scadenza delle attività vengono recuperati dallo stesso meccanismo timer e pertanto risulteranno ritardate dello stesso intervallo.

Il servizio timer flusso di lavoro può essere disattivato su ogni server tramite Amministrazione servizi condivisi in Amministrazione centrale. Per impostazione predefinita, verrà eseguito su ogni server front-end della farm. Ogni processo verrà eseguito in modo iterativo su tutte le applicazioni Web e i database di contenuto della farm.

La combinazione della soglia per il posticipo, la dimensione del batch e la frequenza del timer può essere utilizzata per limitare le operazioni del flusso di lavoro sul database. Gli effetti sulla velocità effettiva massima dipenderanno dalla velocità con cui le operazioni vengono accodate ed elaborate dalla coda.

Con le impostazioni predefinite, un solo servizio timer e un unico database del contenuto, ad esempio, se la coda include 1.000 elementi, saranno necessarie dieci esecuzioni del processo timer per eseguirli tutti, ovvero 50 minuti. Se tuttavia si imposta la dimensione del batch su 1.000 e il processo timer in modo che venga eseguito ogni minuto, tutte le operazioni inizieranno a essere eseguite dopo un minuto. Se si imposta la soglia per il posticipo su un valore più elevato, le operazioni eseguite contemporaneamente saranno più numerose e il numero di richieste accodate risulterà ridotto, come anche il tempo totale necessario per elaborare i flussi di lavoro.

Se non si desidera che i flussi di lavoro vengano eseguiti nei server front-end e si conoscono le operazioni da eseguire immediatamente, è possibile isolare il servizio timer flussi di lavoro in modo che venga eseguito su server applicazioni specifici, impostare la soglia per il posticipo su un numero molto piccolo per fare in modo che i flussi di lavoro vengano eseguiti normalmente nel servizio timer e impostare la dimensione del batch su un valore elevato in modo che gli elementi vengano ricevuti più rapidamente e con maggiore frequenza. Se si desidera verificare che i flussi di lavoro vengano eseguiti in modo più sincrono nel sistema, impostare la soglia per il posticipo su un numero ancora maggiore, per evitare che i flussi di lavoro vengano posticipati spesso e per ottenere un effetto più immediato.

Modificare queste impostazioni per ottimizzare il funzionamento dei flussi di lavoro. È consigliabile provare impostazioni diverse ed eseguire test per trovare la configurazione ottimale per l'ambiente in uso e i requisiti specifici.

Modifica delle impostazioni per l'accodamento

Se la farm dovrà sostenere un carico di flussi di lavoro pesante per periodi prolungati o se molti eventi di ritardo verranno accodati dai flussi di lavoro del sistema, il numero di operazioni dei flussi di lavoro accodate aumenterà. Oltre alle impostazioni di base per l'accodamento, potrebbe essere necessario impostare le opzioni descritte di seguito per ottimizzare la coda.

• Dimensione del batch di recapito degli eventi degli elementi di lavoro

  La tabella utilizzata dal flusso di lavoro per gli eventi accodati è una tabella generale di elementi di lavoro condivisa con altre funzionalità non relative al flusso di lavoro di SharePoint Server 2010. Esiste pertanto un altro processo timer che rimuove dalla coda gli elementi di lavoro non relativi al flusso di lavoro. In modo analogo alla dimensione del batch per il recapito degli eventi del flusso di lavoro, la dimensione del batch per il recapito degli eventi degli elementi di lavoro specifica il numero di elementi di lavoro non appartenenti al flusso di lavoro rimossi dalla coda alla volta.

• Frequenza del processo timer di failover per il flusso di lavoro

  In circostanze rare, se gli eventi del flusso di lavoro non possono essere recapitati a un'istanza del flusso di lavoro, il recapito dell'evento verrà pianificato nella coda come elemento di lavoro di failover da ritentare in un secondo momento, a partire da cinque minuti più tardi, 10 minuti in caso di errore, quindi 20 minuti e così via. Un processo timer di failover per il flusso di lavoro rimuove dalla coda gli elementi di lavoro di failover e questa impostazione stabilisce la frequenza di esecuzione del timer di failover. Per impostazione predefinita, viene eseguito ogni 15 minuti.

• Dimensione del batch di failover per il flusso di lavoro

  In modo analogo alle impostazioni delle dimensioni dei batch dei flussi di lavoro e degli elementi di lavoro, questa impostazione controlla il numero di eventi di failover che ogni processo timer di failover rimuoverà dalla coda.

  Poiché molti processi timer utilizzano la stessa tabella, una quantità elevata di elementi accodati può provocare conflitti tra database e ridurre la velocità effettiva e l'affidabilità. Per limitare i conflitti tra database, è consigliabile procedere come indicato di seguito.

  • Bilanciare la soglia per il posticipo e la dimensione del batch di flussi di lavoro in modo che la dimensione del batch sia abbastanza piccola o che la frequenza del processo timer sia abbastanza alta da consentire il completamento di un processo timer prima dell'inizio di quello successivo per evitare l'elaborazione di troppi processi timer paralleli che non possono essere completati.

  • Per evitare blocchi sulla tabella, non impostare nessuna delle due impostazioni della dimensione del batch su un valore maggiore di 5.000.

Miglioramento della scalabilità per gli elenchi delle attività e della cronologia

I flussi di lavoro generano molte attività ed elementi della cronologia per ogni istanza. Per impostazione predefinita, questi elenchi vengono indicizzati per favorire la scalabilità, ma, con l'aumentare delle dimensioni degli elenchi, le prestazioni peggioreranno sempre. Per ridurre questo effetto, utilizzare elenchi di attività e della cronologia separati per associazioni diverse di flussi di lavoro e modificare periodicamente tali elenchi nelle impostazioni di associazione dei flussi di lavoro man mano che le dimensioni degli elenchi aumentano.

Anche il flusso di lavoro ha un processo timer giornaliero (job-workflow-autoclean) che elimina automaticamente le istanze del flusso di lavoro e le attività delle istanze che sono state completate da più di 60 giorni. Lasciare questo processo timer attivo per mantenere gli elenchi di attività e gli eventi sull'elenco di attività il più puliti possibile. Se è necessario conservare i dati, scriverli in altri elenchi o posizioni di archiviazione. Gli elementi della cronologia del flusso di lavoro non vengono eliminati da questo processo timer. Se è necessario eliminarli, eseguire questa operazione con uno script o manualmente tramite l'interfaccia utente dell'elenco.

Altre considerazioni

La rimozione di colonne negli elenchi provoca un'operazione del database proporzionale al numero di voci dell'elenco. La rimozione di associazioni del flusso di lavoro provoca la rimozione della colonna dello stato del flusso di lavoro dall'elenco. Ciò comporta un'operazione impegnativa sugli elenchi di grandi dimensioni. Se è noto che un elenco contiene milioni di voci, impostare il flusso di lavoro su Nuove istanze non consentite anziché rimuovere i flussi di lavoro.

Risoluzione dei problemi

Server Web

Nella tabella riportata di seguito sono indicati i contatori delle prestazioni e i processi per monitorare i server Web di una farm.

Server di database.

Nella tabella riportata di seguito sono indicati i contatori delle prestazioni e i processi per monitorare i server di database di una farm.

See Also

Other Resources

Scalabilità e prestazioni del flusso di lavoro in Windows SharePoint Services 3.0 (https://go.microsoft.com/fwlink/?linkid=207353&clcid=0x410) (le informazioni potrebbero essere in lingua inglese)