Stimare i requisiti di prestazioni e capacità per Access Services in SharePoint Server 2010

Si applica a: SharePoint Server 2010 Enterprise

Ultima modifica dell'argomento: 2016-11-30

In questo articolo vengono fornite informazioni aggiuntive sugli effetti dell'utilizzo di Access Services in Microsoft SharePoint Server 2010 su topologie in cui viene eseguito Microsoft SharePoint Server 2010.

Contenuto dell'articolo:

• Caratteristiche della farm di testing

• Risultati dei test

• Suggerimenti

• Risoluzione dei problemi

Caratteristiche della farm di testing

In questa sezione vengono descritti il set di dati utilizzato durante il testing, i carichi di lavoro applicati al prodotto durante la raccolta dei dati relativi alle prestazioni, l'hardware utilizzato nel corso del testing e la topologia di distribuzione di tale hardware.

Set di dati

La capacità e le prestazioni di Access Services dipendono in modo significativo dalla struttura delle applicazioni ospitate nel servizio. Su tali fattori spesso incidono soprattutto la dimensione delle tabelle e la complessità delle query. Per il testing sono state utilizzate dimensioni e complessità rappresentative, ma ogni applicazione e ogni set di dati è diverso. La capacità e le prestazioni varieranno in base alle applicazioni in uso, al relativo grado di complessità specifico e alla dimensione dei dati.

Per valutare il profilo di capacità, le applicazioni di Access Services sono state simulate in una farm dedicata a Access Services, in cui non erano in corso altri test di SharePoint. Nella farm erano inclusi i siti rappresentativi seguenti:

• 1.500 applicazioni di Access Services con un profilo di "piccole" dimensioni; un massimo di 100 elementi per elenco

• 1.500 applicazioni di Access Services con un profilo di "medie" dimensioni; un massimo di 2.000 elementi per elenco

• 1.500 applicazioni di Access Services con un profilo di "grandi" dimensioni; un massimo di 10.000 elementi per elenco

Ogni applicazione è costituita da più elenchi e gli altri elenchi sono dimensionati in modo appropriato in base a tale elenco più grande. Access Services è in grado di gestire una quantità di dati superiore a 10.000 elementi. Questo numero è stato scelto per il profilo di "grandi" dimensioni perché si prevedeva che applicazioni ancora più grandi non fossero molto comuni.

Le applicazioni erano equamente distribuite tra i tipi seguenti:

• Contatti  Una semplice applicazione per la gestione dei contatti, con un solo elenco.

• Progetti   Una semplice applicazione di controllo dell'avanzamento di attività e progetti, con due elenchi (progetti e attività associati a ogni progetto).

• Ordini   Un semplice sistema di gestione degli ordini, simile all'esempio Northwind Traders di Microsoft Access ma con scalabilità ridotta, contenente molti elenchi correlati tra loro (ordini, dettagli degli ordini, fatture, dettagli delle fatture, ordini di acquisto, dettagli degli ordini di acquisto e così via).

Carico di lavoro

Per simulare l'utilizzo delle applicazioni, sono stati creati carichi di lavoro per l'esecuzione di una o più operazioni seguenti:

• Apertura dei moduli

• Spostamento all'interno dei moduli

• Applicazione di filtri e ordinamento dei fogli dati

• Aggiornamento, eliminazione e inserimento di record

• Pubblicazione dell'applicazione

• Rendering dei report

In ogni carico di lavoro è incluso il "tempo interazione utente", ovvero un intervallo dai 5 ai 20 secondi tra un'azione dell'utente e l'altra. Questo aspetto differisce da quanto definito in altri documenti sulla pianificazione della capacità di SharePoint. Access Services è una piattaforma con stato e i cursori di memoria e i set di record sono stati gestiti tra le interazioni utente. Era importante simulare un'intera sessione utente e non solo le singole richieste. Per un singolo carico di lavoro utente, la media è di due richieste al secondo.

Nella tabella seguente sono riportate le percentuali utilizzate per determinare quale applicazione e quale dimensione di applicazione utilizzare.

Definizione di area verde e di area rossa

Per ogni configurazione, sono stati eseguiti due test per determinare un'"area verde" e un'"area rossa". La prima corrisponde alla velocità effettiva consigliata che può essere sostenuta. La seconda corrisponde alla velocità effettiva massima che può essere tollerata per un breve periodo di tempo, ma che è opportuno evitare.

L'area verde è stata definita come punto in cui il test in esecuzione utilizza al massimo metà della risorsa che causa il collo di bottiglia. In questo caso, tale risorsa era la percentuale di CPU in uno qualsiasi dei tre livelli, ovvero server Web front-end, server applicazioni (Access Data Services) o server di database (SQL Server). Il collo di bottiglia innanzitutto è stato identificato per una particolare configurazione. Quando si è trattato della CPU di Access Data Services, si è fatto in modo che la CPU utilizzata dal test relativo all'area verde nei computer Access Data Services fosse compresa tra il 40% e il 50%.

Nel caso dell'area rossa, è stato selezionato un punto in cui è stata raggiunta la velocità effettiva massima, ovvero un utilizzo della CPU compreso tra l'80% e il 90%. Durante la ricerca del collo di bottiglia, sono stati esaminati la percentuale di CPU, l'utilizzo della memoria (byte privati), la lunghezza della coda dischi, l'I/O su rete e altre risorse che potevano dare luogo a un collo di bottiglia.

Il test dell'area verde e quello dell'area rossa sono stati entrambi eseguiti per un'ora con un carico utente fisso.

I propri risultati possono variare

I valori specifici della capacità e delle prestazioni presentati in questo articolo sono diversi da quelli degli ambienti reali. Questa simulazione è basata esclusivamente su una stima delle operazioni che gli utenti effettivi possono eseguire. I valori indicati hanno il solo scopo di fornire un punto di partenza per la progettazione di un ambiente con scalabilità appropriata. Dopo avere completato la progettazione iniziale del sistema, è consigliabile testare la configurazione per determinare se il sistema supporterà i fattori specifici del proprio ambiente.

Impostazione e topologia hardware

Hardware lab

Per offrire informazioni generali sui dettagli dei risultati dei test, sono state utilizzate diverse configurazioni di farm per i test, ovvero da uno a quattro server Web front-end, da uno a quattro server applicazioni (se è presente Access Services o Access Data Services) e un solo computer server di database che esegue Microsoft SQL Server 2008. I test inoltre sono stati eseguiti utilizzando quattro computer client. Tutti i computer server erano a 64 bit, mentre tutti i computer client erano a 32 bit.

Nella tabella seguente sono riportati i componenti hardware specifici utilizzati per i test.

Topologia

Sulla base dell'esperienza acquisita, la CPU al livello del server applicazioni, in cui è in esecuzione Access Data Services, è un importante fattore di limitazione della velocità effettiva. La topologia è stata modificata aggiungendo altri computer Access Data Services fino a eliminare il collo di bottiglia e quindi aggiungendo un server Web front-end per ottenere una velocità effettiva ancora maggiore.

• 1x1: un computer server Web front-end e un computer Access Data Services

• 1x2: un computer server Web front-end e due computer Access Data Services

• 1x3: un computer server Web front-end e tre computer Access Data Services

• 1x4: un computer server Web front-end e quattro computer Access Data Services

• 2x1: due computer server Web front-end e un computer Access Data Services

• 2x2: due computer server Web front-end e due computer Access Data Services

• 2x4: due computer server Web front-end e quattro computer Access Data Services

Il computer che esegue SQL Server è relativamente potente e in nessun caso è diventato un collo di bottiglia (anche se stava iniziando a raggiungere la saturazione della CPU nel test 2x4), pertanto è rimasto invariato nelle topologie utilizzate. A seconda delle query che fanno parte di una combinazione reale di applicazioni, si prevede che il livello del server di database (SQL Server) possa diventare il collo di bottiglia.

Reporting Services era in esecuzione in modalità connessa per tutti i test al livello del server applicazioni (Access Data Services).

Risultati dei test

Nelle tabelle riportate di seguito vengono mostrati i risultati dei test di Access Services. Per ogni gruppo di test, sono state modificate solo alcune variabili specifiche per illustrare l'impatto progressivo sulle prestazioni della farm.

Tutti i test trattati in questo articolo sono stati eseguiti con un tempo interazione utente o tempo di attesa. Questo aspetto differisce dai risultati sulla pianificazione della capacità per altre parti di SharePoint.

Per informazioni sui colli di bottiglia di Access Services, vedere Comuni colli di bottiglia e relative cause (le informazioni potrebbero essere in lingua inglese) più avanti in questo articolo.

Scala generale

Nella tabella e nel grafico seguenti viene riepilogato l'impatto dell'aggiunta di server Web front-end e di computer Acces Data Services dedicati alla farm. Questi valori relativi alla velocità effettiva sono specifici per i computer Access Data Services e non mostrano l'effetto sull'intera farm.

Risultati consigliati

Nel grafico seguente vengono mostrati i risultati per la velocità effettiva sostenibile consigliata.

Come spiegato in precedenza in questo articolo, con l'aggiunta del quarto computer Access Data Services il collo di bottiglia diventa il server Web front-end e con l'aggiunta di un secondo server Web front-end viene risolto il vincolo di risorsa al livello di server Web front-end. Ciò implica che 1x1, 1x2 e 1x3 siano configurazioni ragionevoli. Quando tuttavia viene aggiunto il quarto computer Access Data Services, è consigliabile aggiungere anche un server Web front-end. Poiché l'implementazione della scalabilità avviene in modo lineare (linea retta da 1x1 a 1x4), è possibile presumere che l'aggiunta di un settimo computer Access Data Services implichi anche l'aggiunta di un terzo server Web front-end e così via al fine di soddisfare le necessità della farm.

Ricordare che questi risultati si basano solo su un carico di lavoro simulato e che è consigliabile monitorare l'effettiva distribuzione per trovare il punto in cui sono necessari ulteriori server Web front-end per supportare computer Access Data Services aggiuntivi. I server Web front-end inoltre sono dedicati ad Access Services, mentre nella realtà tali server sono probabilmente condivisi con altri carichi di lavoro di SharePoint. I risultati vengono mostrati nel grafico seguente.

Nel grafico seguente viene mostrato il tempo di risposta a questo livello di velocità effettiva. Il tempo di risposta è molto breve, in media meno di ¼ di secondo per ogni richiesta.

Questi risultati indicano che il computer SQL Server non era un collo di bottiglia perché l'aggiunta di un secondo server Web front-end ha risolto l'insufficienza di risorse e la CPU di SQL Server è sempre rimasta al di sotto del 50%. Tenere tuttavia presente che l'istanza di SQL Server è condivisa con altri servizi di SharePoint e SharePoint stesso, pertanto come effetto cumulativo la CPU o la lunghezza dischi I/O può diventare un collo di bottiglia.

Velocità effettiva massima

Nel grafico seguente vengono mostrati i risultati relativi a una velocità effettiva portata oltre il livello sostenibile.

In questo grafico è possibile vedere ancora come sia stato necessario un secondo server Web front-end per ottimizzare l'utilità del quarto computer Access Data Services. Anche in questo caso i propri risultati potrebbero essere diversi perché dipendono in modo significativo dalle applicazioni e dai relativi modelli di utilizzo.

In questo caso, il tempo di risposta è aumentato, in quanto l'intero sistema è sotto pressione. Questi livelli tuttavia sono ancora prossimi a un secondo e quindi risultano accettabili per la maggior parte degli utenti.

Può sembrare strano che, con quattro computer Access Data Services, due server Web front-end abbiano un tempo di risposta superiore rispetto a un solo server Web front-end. Questa situazione è dovuta al fatto che la velocità effettiva globale del sistema è aumentata con due server Web front-end.

Anche in questo caso SQL Server non è un fattore limitante perché l'aggiunta del secondo server Web front-end riporta a un'implementazione lineare della scalabilità. Si sta comunque raggiungendo il 90% di utilizzo della CPU nell'istanza di SQL Server. La capacità aggiuntiva rimasta è perciò molto ridotta. Se fosse necessario aggiungere un quinto computer Access Data Services, probabilmente il computer SQL Server diventerebbe il collo di bottiglia.

Risultati dettagliati

Nelle tabelle seguenti sono riportati i risultati dettagliati per le configurazioni consigliate.

Nelle tabelle seguenti sono riportati i risultati dettagliati per le configurazioni massime.

Suggerimenti

In questa sezione vengono forniti suggerimenti di carattere generale sulle prestazioni e sulla capacità.

La capacità e le prestazioni di Access Services dipendono in modo significativo dalla struttura delle applicazioni ospitate nel servizio. A incidere sono soprattutto la dimensione delle tabelle e la complessità delle query. Per il testing sono state utilizzate dimensioni e complessità rappresentative, ma ogni applicazione e ogni set di dati è diverso. La capacità e le prestazioni pertanto varieranno in base alle applicazioni in uso, al relativo grado di complessità specifico e alla dimensione dei dati.

Suggerimenti sui componenti hardware

Access Services si avvale di hardware standard sia per i server Web front-end che per i server applicazioni. Non sono pertanto necessari componenti speciali. Per i computer al livello di server applicazioni (Access Data Services) si applicano le linee guida generali di SharePoint Server 2010 relativamente al numero di CPU, alla velocità e alla memoria.

Topologie con scalabilità verticale e orizzontale

Per aumentare la capacità e le prestazioni di una delle topologie di partenza, è possibile procedere in due modi. È possibile implementare la scalabilità verticale aumentando la capacità dei server esistenti oppure implementare la scalabilità orizzontale aggiungendo ulteriori server alla topologia. In questa sezione vengono descritte le caratteristiche di prestazioni generali di diverse topologie con scalabilità orizzontale.

Le topologie di esempio rappresentano le modalità comuni seguenti di implementazione della scalabilità orizzontale per uno scenario di Access Services:

• Per fornire maggiore carico utente, verificare la CPU per i server applicazioni Access Services esistenti. Aggiungere ulteriori CPU o core oppure entrambi a tali server, se possibile. Aggiungere ulteriori computer server Access Services in base alle necessità. Procedere in questo modo finché il server Web front-end non diventa il collo di bottiglia, quindi aggiungere i server Web front-end necessari.

• Nei test eseguiti la memoria al livello di server Web front-end e di server applicazioni (Access Data Services) non era un collo di bottiglia. A seconda delle dimensioni dei set di risultati, la memoria può diventare un problema, anche se questa in genere non è la norma. Tenere traccia dei byte privati per il processo w3wp di Access Data Services, come descritto qui.

• Nei test eseguiti SQL Server non era un collo di bottiglia. Tali test tuttavia sono stati eseguiti in isolamento rispetto ad altri servizi di SharePoint Server 2010. È opportuno monitorare la CPU e l'I/O su disco per SQL Server e aggiungere ulteriori server o assi in base alle necessità.

Impostazioni di Access Services relative alle prestazioni

Un modo per controllare le caratteristiche di prestazioni di Access Services è quello di limitare la dimensione e la complessità delle query che possono essere eseguite. Access Services offre una serie di colli di bottiglia configurabili per controllare le query. Ognuna delle query seguenti può essere impostata mediante Amministrazione centrale SharePoint. A tale scopo, nella sezione Gestione applicazioni fare clic su Gestisci applicazioni di servizio e quindi su Access Services.

La quantità di dati da recuperare da SharePoint per eseguire una query in genere ha un impatto significativo sulle prestazioni. Per controllarla, è possibile procedere in diversi modi. È innanzitutto possibile limitare gli input per una query:

• Numero massimo origini per query

• Numero massimo record per tabella

In secondo luogo è possibile limitare la dimensione risultante di una query:

• Numero massimo colonne per query

• Numero massimo righe per query

• Consenti outer join

Oltre alla dimensione della query (dimensione dei dati in ingresso e in uscita), è possibile controllare la complessità di elaborazione dei dati allo scopo di ridurre il carico sulla CPU al livello di server applicazioni (Access Data Services):

• Numero massimo colonne calcolate per query

• Numero massimo clausole ORDER BY per query

Le impostazioni precedenti ovviamente influiranno sulle applicazioni che possono essere eseguite nel server. Ad esempio, se un'applicazione viene scritta con 40 colonne di output di una query e le impostazioni sono inferiori a tale livello, l'applicazione genererà un errore di runtime. È necessario trovare il giusto compromesso tra le necessità degli utenti e un livello accettabile di prestazioni e questo dipende soprattutto dal tipo di applicazioni Access che si prevede di eseguire nella farm.

È anche possibile adottare un'ulteriore misura più estrema. SharePoint Server 2010 supporta una serie di operazioni di query in modo nativo, che Access Services estende in modo da coprire una gamma più vasta di scenari applicativi. Affinché Access Services migliori le query di SharePoint, è possibile che una grande quantità di dati debba essere recuperata dal database del contenuto di SharePoint. È invece possibile impostare Access Services in modo da vincolarlo alle sole operazioni di query, che possono essere supportate in modo nativo da SharePoint, evitando il recupero dei dati necessario per operazioni più complesse:

• Consenti query non utilizzabili in remoto

Ottimizzazioni

Comuni colli di bottiglia e relative cause

Durante i test delle prestazioni si sono manifestati diversi colli di bottiglia comuni. Un collo di bottiglia è una condizione in cui viene raggiunto il limite di capacità di un singolo componente di una farm. Questa situazione dà origine a un ristagno o a una diminuzione della velocità effettiva della farm.

Nella tabella riportata in Risoluzione dei problemi più avanti in questo articolo vengono elencati alcuni colli di bottiglia comuni e vengono descritte le relative cause con le possibili soluzioni.

Monitoraggio delle prestazioni

Per determinare quando è necessario implementare la scalabilità verticale o orizzontale per il sistema, utilizzare i contatori delle prestazioni per monitorare l'integrità del sistema. Utilizzare le informazioni riportate nelle tabelle seguenti per stabilire quali contatori delle prestazioni monitorare e a quale processo applicarli.

Server Web front-end

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

Access Data Services

Nella tabella riportata di seguito sono indicati i contatori delle prestazioni e i processi da monitorare per i server applicazioni, o Access Data Services (Access Data Services) in questo caso, all'interno della farm.

Server di database

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

Risoluzione dei problemi

Nella tabella riportata di seguito vengono elencati alcuni colli di bottiglia comuni con le relative cause e le possibili soluzioni.