PRESTAZIONI DI SQL SERVER RBS CON SHAREPOINT SERVER 2010 E LA SOLUZIONE DI ARCHIVIAZIONE STORSIMPLE
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Prestazioni di SQL Server RBS con SharePoint
Server 2010 e la soluzione di archiviazione
StorSimple
Questo documento viene fornito “così com’è”. Le informazioni e le opinioni espresse nel presente
documento, inclusi gli URL e altri riferimenti a siti Web Internet, possono essere soggette a modifiche senza
preavviso. L’utente accetta di utilizzarlo a proprio rischio.
Il presente documento non implica la concessione di alcun diritto di proprietà intellettuale relativo ai prodotti
Microsoft. È possibile copiare e utilizzare questo documento per fini di riferimento interno. Non è possibile
modificare questo documento per fini personali o di riferimento.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Microsoft SharePoint Server 2010 Aprile 2011 Prestazioni di SQL Server RBS con SharePoint Server 2010 e la soluzione di archiviazione StorSimple Burzin Patel StorSimple, Inc. Peter Scharlock Microsoft Corporation Revisori tecnici: John Flores (StorSimple, Inc.), Srini Acharya, Steve Howard, Shaun Tinline-Jones, Mike Weiner, Kun Cheng, Prem Mehra, Jimmy May, David Koronthaly, Bill Baer Dicembre 2010. Revisione: aprile 2011 Si applica a: SharePoint Server 2010 e SQL Server 2008 R2 Riepilogo: in anni recenti l’utilizzo della tecnologia Microsoft® SharePoint® ha subito un’espansione imponente. Questa espansione è stata prodotta dall’elevata quantità di documenti, nonché di documenti multimediali di dimensioni maggiori, archiviati dagli utenti in raccolte di SharePoint, che a loro volta hanno generato un aumento dei costi di archiviazione e alcune importanti sfide in termini di prestazioni e gestibilità per gli amministratori di SharePoint. Microsoft ha affrontato questi problemi introducendo supporto tecnico nativo per la caratteristica Archiviazione BLOB remoti (RBS) di SharePoint Server 2010. In questo documento viene descritta la caratteristica RBS in relazione a SharePoint Server 2010, esaminandone l’impatto per le prestazioni sui principali attributi di una farm di SharePoint, quali dimensione del database, dimensioni dei backup dei database, tempi di risposta delle transazioni e tempi di backup e ripristino. © 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 2 Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare SharePoint IT Docs (itspdocs@microsoft.com).
Microsoft SharePoint Server 2010 Aprile 2011
Sommario
Introduzione ......................................................................................................................................................4
Archiviazione BLOB remoti ..................................................................................................................................4
Perché utilizzare RBS ....................................................................................................................................5
Obiettivi dei test ................................................................................................................................................6
Metodologia dei test ...........................................................................................................................................7
Carico di lavoro............................................................................................................................................7
Configurazione del server..............................................................................................................................9
Configurazione hardware ........................................................................................................................9
Configurazione dell’archiviazione ........................................................................................................... 10
Configurazione software ....................................................................................................................... 10
Risultati dei test e osservazioni .......................................................................................................................... 11
1. Effetti di RBS sulla dimensione del database di SQL Server .......................................................................... 11
2. Effetti di RBS sulle dimensioni dei backup dei database ............................................................................... 14
3. Effetti di RBS sui tempi di backup e ripristino ............................................................................................. 16
4. Effetti di RBS sulle prestazioni di ricostruzione degli indici ........................................................................... 18
5. Effetti di RBS sui tempi di risposta delle transazioni di SharePoint ................................................................ 20
6. Effetti di RBS sulle prestazioni della ricerca per indicizzazione ...................................................................... 22
7. Effetti di RBS sulle prestazioni di caricamento dei file .................................................................................. 23
8. Tempo necessario per la migrazione dei dati .............................................................................................. 25
Conclusioni ...................................................................................................................................................... 26
Risorse aggiuntive ............................................................................................................................................ 27
Informazioni su StorSimple ............................................................................................................................... 27
Informazioni su Microsoft .................................................................................................................................. 27
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 3
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).
Microsoft SharePoint Server 2010 Aprile 2011
Introduzione
La popolarità di Microsoft SharePoint Server è cresciuta in misura esponenziale negli ultimi anni. Questa crescita
si è verificata grazie all’adozione di SharePoint Server da parte di più clienti, nonché all’archiviazione da parte
di un numero sempre maggiore di utenti di documenti e set di dati di dimensioni superiori in farm di SharePoint.
Con la recente versione di SharePoint Server 2010, è prevista una crescita ancora maggiore.
SharePoint Server 2010 presenta un’interfaccia utente semplificata in grado di offrire un’esperienza
utente ottimale, che rende SharePoint Server l’archivio ideale per tutti i tipi di dati. Questi aspetti,
insieme all’aumento di contenuti multimediali avanzati, producono l’espansione delle dimensioni del
contenuto della farm di SharePoint, che a sua volta provoca un aumento significativo della capacità di
archiviazione fisica necessaria. Questo aumento di dimensioni pone spesso una sfida agli amministratori di
SharePoint, che devono affrontare il carico di lavoro aggiuntivo correlato alla gestione di più contenuto,
database più grandi e backup sempre maggiori. Per affrontare questo scenario, in SharePoint Server 2010
è stata introdotta una nuova caratteristica, Archiviazione BLOB remoti (RBS), che consente di risolvere i
problemi generati dall’espansione del contenuto di SharePoint.
In questo documento vengono illustrati i vantaggi e le caratteristiche di funzionamento di RBS, quando
questo viene utilizzato insieme a Microsoft SharePoint Server 2010, nonché le caratteristiche correlate alle
prestazioni di una farm di SharePoint configurata per l’esecuzione con la soluzione di archiviazione
StorSimple, come verrà descritto nella prossima sezione. Vantaggi quali la riduzione delle dimensioni del
database, backup e ripristini di database più veloci, migliori tempi di risposta per documenti di dimensioni
maggiori, migliore manutenzione dei database e minore richiesta sull’archivio back-end, verranno trattati
insieme alle coordinate relative alla prestazioni. Tutte le coordinate presentate nel documento sono state
generate come parte dei test delle prestazioni svolti presso i laboratori di StorSimple, Inc. a Santa Clara
insieme ai team di prodotto di Microsoft SQL Server e SharePoint.
Nota: i risultati dei test inclusi in questo white paper sono specifici degli ambienti descritti
nel white paper stesso. I risultati possono variare.
Archiviazione BLOB remoti
BLOB è l’acronimo di Binary Large Object e nel contesto delle applicazioni di SharePoint si riferisce
all’oggetto file archiviato nel database. Archiviazione BLOB remoti (RBS) è un set di API delle raccolte di
Microsoft® SQL Server® integrato come Feature Pack aggiuntivo per Microsoft SQL Server 2008 R2. La
caratteristica RBS consente alle applicazioni di archiviare oggetti BLOB esternamente al database, ad
esempio in una condivisione di file, per ridurre la capacità di archiviazione del database di SQL Server
necessaria. Un archivio RBS è in genere un volume distinto nella stessa rete di SQL Server. SharePoint
Server 2010 utilizza la caratteristica RBS per archiviare esternamente gli oggetti BLOB archiviati nel
database del contenuto. SQL Server e SharePoint Server gestiscono insieme l’integrità dei dati tra i record
del database e l’archivio esterno RBS per ciascun database.
Per la caratteristica RBS di SQL Server è necessario che sia installato un provider in ogni server front-end
Web SharePoint in cui è configurata l’applicazione SharePoint. Il provider include un set di DLL per
l’implementazione di metodi per le API di RBS e per l’esecuzione dell’effettiva operazione di archiviazione
esterna degli oggetti BLOB.
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 4
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).
Microsoft SharePoint Server 2010 Aprile 2011
Per tutti i test svolti e descritti in questo documento, è stata configurata nella farm di SharePoint Server
2010 l’utilità StorSimple di ottimizzazione del database di SharePoint (StorSimple SharePoint Database
Optimizer), che include un provider RBS. La configurazione è stata eseguita utilizzando lo strumento di
gestione della configurazione RBS dell’utilità StorSimple di ottimizzazione del database di SharePoint,
un’estensione del sito Amministrazione centrale, illustrata nella figura (i) di seguito.
Figura (i) - Utilità StorSimple di ottimizzazione del database di SharePoint - Configurazione di RBS
Perché utilizzare RBS
Tutti i dati di SharePoint Server vengono archiviati nel database. Con l’aumentare del contenuto archiviato, la
dimensione del database può crescere molto rapidamente. Questa crescita è imputabile al caricamento di nuovo
contenuto in SharePoint Server, nonché a revisioni di contenuto esistente quando è abilitato il controllo delle
versioni di SharePoint. In questo caso, anche se viene modificato un solo byte di un documento di SharePoint,
nel database viene archiviata una nuova copia dell’intero oggetto BLOB e la vecchia copia viene contrassegnata
come versione precedente. Come molti amministratori di SharePoint hanno già notato, questo comportamento
produce un aumento esponenziale delle dimensioni del contenuto.
Con l’aumentare della dimensione del database, diventa sempre più difficile gestire il sistema e garantire
prestazioni ottimali. Attività altrimenti essenziali come backup e ripristino e deframmentazione del
database diventano sempre più impegnative da eseguire. Questo è uno dei motivi per cui Microsoft
consiglia agli utenti di limitare le dimensioni dei database perché siano gestibili, come descritto in questo
articolo: “Gestione della capacità di SharePoint Server 2010: limiti software statici e configurabili”
(http://technet.microsoft.com/it-it/library/cc262787.aspx#ContentDB). L’adozione di questa procedura
consigliata può imporre a un amministratore di SharePoint la necessità di creare più database, che
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 5
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).
Microsoft SharePoint Server 2010 Aprile 2011
comporta un aumento dei costi in termini di gestione e manutenzione. Un numero maggiore di database
produce più backup da gestire e monitorare, che a loro volta implicano più amministratori di SharePoint.
Se si utilizza RBS, l’applicazione può archiviare grandi quantità di dati non strutturati come video multimediali o
file audio avanzati, sfruttando il meglio delle funzionalità relazionali di SQL Server e la scalabilità di un archivio
BLOB del file system di Windows®. Oltre a questo importante vantaggio, la caratteristica RBS ne offre molti altri
correlati a costi di archiviazione, manutenzione, prestazioni e flessibilità:
Database di dimensioni minori, per un uso ottimale delle costose risorse del server di database come
processori, memoria e dischi
File di backup di database di dimensioni minori
Tempi di backup e ripristino più rapidi
Operazioni di manutenzione del database, come deframmentazione e ricostruzione degli indici, più rapide
Migliori prestazioni complessive, in particolare per l’accesso a oggetti di grandi dimensioni e la loro
archiviazione.
Quando SharePoint Server è configurato per l’utilizzo di RBS, la semantica di transazione delle operazioni
utente viene preservata completamente e non si osserva assolutamente alcuna modifica da un punto di
vista dell’utente finale. L’attività di archiviazione degli oggetti BLOB esternamente al database viene
eseguita automaticamente nel back-end da SharePoint Server insieme al provider RBS. Benché RBS
funzioni correttamente se utilizzato con il clustering di failover di SQL Server, non funziona con il mirroring
di SQL Server quando viene eseguito il mirroring del database del contenuto di SharePoint in un server di
database che si trova in un’altra farm.
Obiettivi dei test
L’obiettivo del testing è stato quello di definire le prestazioni di una farm di SharePoint configurata con RBS
tramite il provider RBS di StorSimple, che fa parte dell’utilità StorSimple di ottimizzazione del database di
SharePoint, e quindi di confrontarle con quelle di una farm di SharePoint senza la caratteristica RBS
abilitata. Si è inoltre voluto misurare gli effetti di RBS sugli elementi seguenti:
Dimensioni dei dati del database e dei file di registro delle transazioni di SQL Server
Dimensioni dei file di backup
Tempo impiegato per il backup e il ripristino del database del contenuto
Tempo impiegato per la ricostruzione degli indici del database del contenuto
Effetti dell’operazione di ricostruzione degli indici sulle prestazioni delle transazioni degli utenti finali
Tempi di risposta delle transazioni di SharePoint
Operazione di ricerca per indicizzazione di SharePoint Server
Prestazioni di caricamento dei file
Coerenza delle prestazioni con l’aumentare delle dimensioni del contenuto
Tempo impiegato per la migrazione di dati da e verso l’archivio RBS
Il comportamento di SharePoint Server 2010 per diverse caratteristiche del carico di lavoro delle
applicazioni o per soglie diverse per le dimensioni degli oggetti BLOB archiviati esternamente non è incluso
nella trattazione di questo documento.
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 6
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).
Microsoft SharePoint Server 2010 Aprile 2011
Metodologia dei test
Come obiettivo, si è voluto condurre i test descritti nella sezione precedente su un carico di lavoro che
rappresentasse scenari quanto più reali possibile. Un altro obiettivo è stato il mantenimento della
configurazione per i test (configurazione del server, impostazioni del database, schema della tabella e così
via) relativamente costante in tutti i test, in modo da poter identificare analogie e differenze tra le
prestazioni delle diverse operazioni.
I test sono stati suddivisi in tre ampie categorie: (1) test di caricamento, (2) test sulla combinazione
completa delle transazioni e (3) test vari.
Test di caricamento di documenti: tramite questo insieme di test sono stati misurati prestazioni ed
effetti di RBS sul caricamento di documenti degli utenti per diverse dimensioni di file medie.
Test sulla combinazione completa di transazioni di SharePoint: tramite questo insieme di test sono
stati misurati gli effetti di RBS sulle prestazioni della farm di SharePoint. I test hanno incluso tutte le
transazioni utente di SharePoint comunemente eseguite, quali selezione, ricerca, caricamento di documenti
e creazione di siti. Il principale criterio di valutazione delle prestazioni utilizzato è stato il tempo medio di
risposta delle pagine Web.
Test vari: questi test hanno incluso operazioni come il backup e il ripristino del database, la migrazione di
oggetti da e verso il database e nell’archivio RBS e la ricerca per indicizzazione di SharePoint Server.
Carico di lavoro
Le diverse domande a cui hanno dovuto rispondere i test hanno comportato l’utilizzo di set di dati di carichi
di lavoro diversi. Per i test sono stati utilizzati due carichi di lavoro: (1) la combinazione di carichi di lavoro
per il caricamento di file e (2) la combinazione completa di transazioni di SharePoint.
La combinazione di carichi di lavoro per il caricamento di file ha incluso due set di file con dimensioni
pesate medie di circa 100 KB, utilizzate per generare il database di 100 GB, e di 500 KB, utilizzate per
generare il database del contenuto di 1 TB. La distribuzione delle dimensioni dei file per il set di dati di 100
KB è illustrata nella figura (ii).
Figura (ii) - Distribuzione delle dimensioni dei file dei carichi di lavoro
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 7
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).
Microsoft SharePoint Server 2010 Aprile 2011
La combinazione di carichi di lavoro per il caricamento di file è stata utilizzata innanzitutto per misurare le
caratteristiche di caricamento dei documenti con e senza RBS.
La combinazione completa di transazioni di SharePoint è stata utilizzata per rappresentare una
combinazione di transazioni di SharePoint tipiche eseguite giornalmente da un utente finale. È stato
utilizzato Microsoft Visual Studio® Team System 2008 Team Suite per generare il carico di lavoro tramite
una versione modificata del toolkit di Microsoft Office SharePoint Server 2007 originale condiviso in
Codeplex. Per ciascun test sono state utilizzate le transazioni seguenti.
Test Descrizione Percentuale
Eseguire un flusso di lavoro di pagine: estrazione, approvazione e
Flusso di lavoro pagine 1%
archiviazione
Creazione di una
Creare una nuova pagina 6%
pagina
Strumento di gestione
Aprire la visualizzazione dello strumento di gestione del sito 1%
del sito
Creazione di un sito di
Creare un nuovo sito con il modello di pubblicazione 1%
pubblicazione
Creazione di un sito Creare una nuova raccolta siti utilizzando il modello di sito del team
1%
del team incluso nella directory dei siti
Home page Accedere alla home page del portale 25%
Pagina grande Accedere a un’ampia gamma di pagine nel portale 10%
Pagina pubblica Sito
Accedere alla pagina pubblica Sito personale 16%
personale
Modifica del profilo del
Modificare il profilo personale 7%
sito personale
Eseguire una query di ricerca e visualizzare i risultati nella pagina
Query di ricerca 15%
Centro ricerche
Caricamento di un
Caricare un documento (in media di 90 KB) 5%
documento
Download di un
Scaricare un documento (in media di 90 KB) 12%
documento
Totale: 100%
Tabella (i) - Combinazione completa di transazioni di SharePoint
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 8
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).
Microsoft SharePoint Server 2010 Aprile 2011
Configurazione del server
La farm di SharePoint è stata configurata con sei server front-end Web, un server applicazioni impostato
per l’esecuzione del crawler di ricerca e un server di database, come illustrato nella figura (iii).
Figura (iii) - Topologia della farm di SharePoint
Il server front-end Web e il server applicazioni sono stati configurati per l’esecuzione in una macchina
virtuale, mentre il server di database è stato eseguito in un server fisico dedicato (non virtualizzato).
Sono stati inoltre utilizzati sei server driver di carico basati su macchine virtuali (non illustrati nella figura)
per generare il
carico di lavoro per la combinazione di transazioni di caricamento dei file e la combinazione completa di
transazioni di SharePoint.
Configurazione hardware
Ruolo del computer Hardware
Front-end Web 2 processori Intel Xeon E5504 a processore doppio da 2 GHz (virtualizzati)
8 GB di RAM
Server applicazioni 2 processori Intel Xeon a processore doppio da 2 GHz (virtualizzati)
8 GB di RAM
Server di database 2 processori Intel Xeon da 2 GHz quad-core (virtualizzati)
16 GB di RAM (12 GB assegnati a SQL Server)
Tabella (ii) - Configurazione hardware
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 9
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Microsoft SharePoint Server 2010 Aprile 2011
Configurazione dell’archiviazione
L’archiviazione utilizzata nel test benchmark è stata configurata nel dispositivo di archiviazione
StorSimple 10101. I database di sistema di SQL Server, i database di SharePoint e l’archivio BLOB sono
stati posizionati in volumi distinti, come illustrato nella tabella (iii) seguente.
Volume Unità
Database di sistema SQL C:\
Dati e file di registro di tempdb H:\
File di dati del database del contenuto P:\
File di registro del database del contenuto Q:\
File di dati del database di ricerca S:\
File di registro del database di ricerca Q:\
Archivio BLOB X:\
Copie di backup O:\
Tabella (ii) - Configurazione dell’archiviazione
Configurazione software
Le versioni e le impostazioni software utilizzate per i diversi server sono indicate nella tabella (iv) seguente.
Software Modifiche aggiuntive
Ruolo del
computer
Server Windows Server® 2008 R2 Sono state applicate tutte le patch più
applicazioni e Enterprise x64 recenti di Windows Server.
front-end Web Microsoft SharePoint Server 2010
RBS.msi è stato installato da SQL
Server 2008 R2 Feature Pack.
Server di Windows Server 2008 R2 Enterprise Sono state applicate tutte le patch più
database x64 recenti di Windows Server.
SQL Server 2008 R2 Enterprise x64
Sono state apportate le modifiche
seguenti alle impostazioni del server di
database:
- ‘Max Server Memory’ = 12 GB
- Sono stati creati 4 file di dati tempdb,
spostati nel rispettivo volume.
Tabella (iv) - Configurazione software
1
StorSimple 1010 è un dispositivo di archiviazione ottimizzato per applicazioni come Microsoft SharePoint e Microsoft
Exchange. Per ulteriori informazioni, visitare il sito Web all’indirizzo http://www.storsimple.com.
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 10
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Microsoft SharePoint Server 2010 Aprile 2011
Risultati dei test e osservazioni
Questa sezione contiene un riepilogo dei risultati dei test svolti per misurare gli effetti dell’utilizzo di RBS
per archiviare esternamente il contenuto degli oggetti BLOB sui diversi attributi di una distribuzione di
SharePoint Server 2010 e rispondere alle domande elencate nella tabella (v) seguente.
Descrizione test
1 Effetti di RBS sulla dimensione del database
2 Effetti di RBS sulle dimensioni dei backup dei database
3 Effetti di RBS sui tempi di backup e ripristino
4 Effetti di RBS sulle prestazioni di ricostruzione degli indici
5 Effetti di RBS sui tempi di risposta delle transazioni di SharePoint
6 Effetti di RBS sull’operazione di ricerca per indicizzazione
7 Effetti di RBS sul caricamento di file per diverse dimensioni di file
8 Tempo impiegato per la migrazione di dati da e verso l’archivio RBS
Tabella (v) - Scenari di test
1. Effetti di RBS sulla dimensione del database
di SQL Server
Come illustrato nella sezione dedicata a RBS, la maggior parte dei dati inclusi nel database di SQL Server
corrisponde a dati BLOB di SharePoint. Nella maggior parte delle distribuzioni di SharePoint, in particolare quelle
in cui SharePoint è utilizzato per la gestione della collaborazione e dei record, i dati BLOB occupano oltre il 95%
della dimensione del database. A seconda della dimensione del database, questo contenuto può essere
facilmente tradotto in centinaia di gigabyte di dati del database. Benché si tratti di una caratteristica propria
della progettazione, pone diversi problemi e costituisce spesso un fattore limitante all’utilizzo di SharePoint
Server, alla scalabilità della soluzione e all’utilizzo di alcune caratteristiche utili come i Cestini.
In questi test, i cui risultati vengono riassunti in questa sezione, sono state misurate le dimensioni di database,
file di dati e file di registro delle transazioni per database del contenuto di SharePoint di 100 GB contenenti
100.000 oggetti e un database del contenuto di SharePoint di 1 TB contenente 2 milioni di oggetti con e senza
la caratteristica RBS. Le dimensioni dei file per ognuno dei database sono indicate nella tabella (vi).
Dimensioni (GB)
Riduzione
Senza RBS Con RBS
Dimensione dei database (100 GB) 217,2 7,0 96,8%
Dimensioni dei file di dati del database (100 GB) 106,9 3,2 97,0%
Dimensioni dei file di registro delle transazioni
dei database (100 GB) 111,6 3,8 96,6%
Dimensioni dei dati RBS archiviati esternamente -- 96,2 --
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 11
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Microsoft SharePoint Server 2010 Aprile 2011
Dimensione del database (1 TB) 2.292 26 98,9%
Dimensioni dei file di dati del database (1 TB) 1.120 6,5 99,4%
Dimensioni dei file di registro delle transazioni
del database (1 TB) 1.173 20 98,3%
Dimensioni dei dati RBS archiviati esternamente -- 1.115 --
Tabella (vi) - Dimensioni di database e file
Figura (iv) - Dimensioni di database e file
Come illustrato nella figura (iv) precedente, senza RBS le dimensioni complessive dei database dopo il
caricamento di contenuto di SharePoint di 100 GB e 1 TB sono passate rispettivamente a 217,2 GB e 2,29
TB. Per il database con 100 GB di contenuto di SharePoint, 106,9 GB corrispondono agli effettivi dati del
database, mentre gli altri 111,6 GB corrispondono al registro delle transazioni del database. Analogamente,
per il database con 1 TB di contenuto di SharePoint, 1,12 TB corrispondono al database e 1,2 TB
corrispondono al registro delle transazioni del database. Per un database con RBS abilitato, la dimensione
del database del contenuto di 100 GB è minore del 96,8%, mentre la dimensione del database del
contenuto di 1 TB è minore del 98,9%. Le dimensioni dei dati e dei file di registro delle transazioni sono
minori in misura corrispondente.
Mentre lo spazio aggiuntivo necessario per l’archiviazione di oggetti BLOB nel database è in genere
evidente e noto, un aspetto negativo meno noto e ancor meno compreso è in genere correlato all’aumento
dei file di registro delle transazioni di SQL Server. Il motivo di tale aumento è che SQL Server è un
database coerente dal punto di vista delle transazioni e offre proprietà ACID. Ciò significa che ogni
transazione avrà sicuramente esito positivo o negativo, senza alcuno stato intermedio. SQL Server
implementa le proprietà ACID tramite la registrazione completa di ogni operazione nel registro delle
transazioni del database utilizzando accesso al disco write-through prima del commit dell’operazione. Le
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 12
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Microsoft SharePoint Server 2010 Aprile 2011
proprietà ACID si applicano a tutti i dati e i tipi di dati di SQL Server, inclusi gli oggetti BLOB. Non esiste
alcun meccanismo per disabilitare o aggirare questo comportamento in alcun modo. Come prevedibile,
quando gli oggetti BLOB di SharePoint vengono archiviati nel database di SQL Server, vengono scritti due
volte, la prima nel registro delle transazioni e la seconda nel file di database, come si può notare dalla
dimensione del database (2,29 TB) utilizzato per l’archiviazione di 1 TB di contenuto utente. Questo file di
registro viene troncato quando si esegue il backup del database e si seleziona l’opzione Tronca log.
Quando si utilizza RBS per archiviare esternamente il contenuto BLOB, i dati BLOB vengono scritti nell’archivio
BLOB prima del commit dell’operazione di SharePoint. Le proprietà ACID dell’operazione vengono pertanto
realizzate indirettamente senza incorrere negli overhead doppi di scrittura del registro della transazioni. La
percentuale di riduzione nei dati e nei file di registro delle transazioni del database dipende dalle dimensioni dei
dati e dalla frequenza con cui si tronca il registro delle transazioni durante un backup.
Il contenuto BLOB spostato esternamente viene archiviato in una condivisione di file centralizzata cui
possono accedere tutti i server applicazioni e front-end Web. Il volume di questa condivisione di file si
trova nel server di database o in un altro server. Nella figura (v) vengono illustrate le proprietà della
condivisione di file utilizzata nei test benchmark.
Figura (v) - Dimensione del volume della condivisione di file RBS
Nota: poiché RBS riduce la dimensione del database tramite lo spostamento dei dati BLOB a un archivio
esterno, è importante tenere presente che non viene ridotto lo spazio su disco complessivo utilizzato dai
dati BLOB. I fornitori di archiviazione possono naturalmente fornire supporto tramite tecnologie proprietarie
quali la deduplicazione, che consente di ridurre lo spazio su disco. Gli oggetti BLOB non vengono
automaticamente eliminati dall’archivio RBS quando il contenuto corrispondente viene eliminato da
SharePoint, ma è necessario un ciclo di Garbage Collection distinto tramite il processo di manutenzione
RBS predefinito per eliminare gli oggetti BLOB orfani.
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 13
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Microsoft SharePoint Server 2010 Aprile 2011
2. Effetti di RBS sulle dimensioni dei backup dei
database
In questi test, i cui risultati vengono riassunti in questa sezione, sono stati misurati gli effetti di RBS sulle
dimensioni dei backup dei database per un database del contenuto di SharePoint di 100 GB costituito da
100.000 oggetti e per un database del contenuto di SharePoint di 1 TB costituito da 2 milioni di oggetti. I test e
l’analisi non hanno incluso l’archivio RBS. Di conseguenza, le tecniche e le durate correlate al backup e al
ripristino dei dati BLOB contenuti nell’archivio RBS sono escluse dalla trattazione di questo white paper.
Per eseguire il backup è stato utilizzato il comando Transact-SQL seguente.
BACKUP DATABASE [WSS_Content] TO DISK = N’O:\WSS_Content’ WITH NOFORMAT, INIT, NAME = N
’WSS_Content-Full Database Backup’, SKIP, NOREWIND, NOUNLOAD;
Sono stati svolti inoltre test per misurare gli effetti della caratteristica di compressione dei backup di SQL
Server2 per determinarne gli effetti sulle dimensioni del backup con e senza RBS. Nella tabella (vii)
seguente viene presentato un riepilogo dei risultati dei test.
Dimensioni (MB)
Riduzione
Senza RBS Con RBS
Dimensioni dei file di dati del database (100 GB) 106,9 3,2 97,0%
Dimensioni del backup di SQL Server (100 GB) 107,0 3,3 96,9%
Dimensioni del backup di SQL Server con
compressione (100 GB) 71,5 0,7 99,1%
Dimensioni dell’archivio BLOB (100 GB) 0 96,2 --
Dimensioni dei file di dati del database (1 TB) 1120 6,5 99,4%
Dimensioni del backup di SQL Server (1 TB) 1.119,0 6,6 99,4%
Dimensioni del backup di SQL Server con
compressione (1 TB) 1.046,0 1,2 99,9%
Dimensioni dell’archivio BLOB (1 TB) 0 1115 --
Tabella (vii) - Dimensioni del database e del backup
2
Per poter comprimere i backup dei database, è necessario utilizzare SQL Server Enterprise. Questa
caratteristica non è disponibile in SQL Server Standard o SQL Server Express.
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 14
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Microsoft SharePoint Server 2010 Aprile 2011
Figura (vi) - Dimensioni del database e del backup
Come si può notare nel grafico e nella tabella precedenti, le dimensioni del backup del database
corrispondenti al contenuto di 100 GB risultano inferiori per il 96,9% (107 GB rispetto a 3,3 GB), mentre le
dimensioni del backup del database per il contenuto di 1 TB risultano inferiori per il 99,4% (1,119 GB
rispetto a 6,6 GB) quando RBS è abilitato. Per il contenuto di 100 GB, le dimensioni degli oggetti BLOB
archiviati esternamente al database sono pari a 96,2 GB, mentre per il database di 1 TB sono pari a 1115 GB.
Quando la caratteristica di compressione dei backup di SQL Server è abilitata nel database, le dimensioni
dei backup si riducono ulteriormente, rispettivamente a 71,5 GB e 1.046 GB senza RBS e a 0,7 GB e 1,2
GB con RBS. Si noti che la compressione dei backup è efficace per la riduzione dello spazio quando non
viene utilizzato RBS, in quanto in SharePoint Server i dati BLOB vengono archiviati all’interno di righe con
gli altri dati (metadati). Se gli oggetti BLOB vengono selezionati per l’archiviazione al di fuori delle righe, la
compressione dei backup non ha alcun effetto, in quanto gli oggetti BLOB archiviati al di fuori delle righe
non vengono compressi. Benché ciò costituisca un vantaggio in questo caso, si verifica al prezzo di un
working set di dimensioni maggiori e di una minore efficienza della cache, che produce a sua volta
prestazioni inferiori.
Poiché gli oggetti BLOB di SharePoint non sono modificabili, ovvero non cambiano mai dopo che vengono
creati, è possibile eseguire il backup del contenuto BLOB in qualsiasi momento dopo il completamento del
backup del database di SQL Server. In questo modo si ottiene la flessibilità necessaria per eseguire un
rapido backup temporizzato e coerente dal punto di vista delle transazioni del database di SQL Server e
quindi un backup del volume dell’archivio BLOB in un secondo momento. Il backup di SQL Server e il
backup dell’archivio contenuto RBS costituiscono un set di backup completo del contenuto di SharePoint. Al
termine, il set di backup può essere utilizzato per ripristinare il database di SharePoint in base al momento
di inizio del backup di SQL Server. Nota: nel pianificare una strategia di backup e ripristino che comporta
l’archiviazione di dati RBS, pianificare i tempi di ripristino di RBS. Fino al ripristino di RBS, i documenti di
SharePoint non saranno disponibili.
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 15
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Microsoft SharePoint Server 2010 Aprile 2011
3. Effetti di RBS sui tempi di backup e ripristino
In questi test, i cui risultati vengono riassunti in questa sezione, sono stati misurati gli effetti di RBS sul
tempo impiegato per il backup e il ripristino di un database. Analogamente alla sezione precedente, è stato
utilizzato un database del contenuto di SharePoint di 100 GB costituito da 100.000 oggetti. È stata svolta
una serie di test per misurare il tempo necessario per il backup e il ripristino dei database con e senza RBS
abilitato. Nella tabella (viii) seguente è incluso il riepilogo dei risultati dei test per il database di 100 GB.
Operazione Senza RBS Con RBS Riduzione
Dimensioni dei file di dati del database 106,9 3,2 97,0%
Tempo necessario per il backup del database 2.490 secondi 38 secondi 98,5%
Tempo necessario per il ripristino del database 1.290 secondi 28 secondi 97,8%
Tempo necessario per il backup del database con 3.160 secondi 37 secondi 98,8%
compressione dei backup abilitata
Tempo necessario per il ripristino del database dal backup 1.330 secondi 28 secondi 97,9%
compresso
Tempo necessario per il backup dell’archivio BLOB (snapshot) -- 14 secondi --
Tempo necessario per il ripristino dell’archivio BLOB (snapshot) -- 28 secondi --
Tempo necessario per il backup dell’archivio BLOB -- 2.578 secondi --
(comando di copia)
Tempo necessario per il ripristino dell’archivio BLOB -- 2.880 secondi --
(comando di copia)
Tabella (viii) - Tempi di backup e ripristino per un database di 100 GB
Figura (vii) - Tempi di backup e ripristino per un set di dati di 100 GB
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 16
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Microsoft SharePoint Server 2010 Aprile 2011 Per i backup e i ripristini del database, il tempo impiegato è direttamente proporzionale alla dimensione del database. Poiché la dimensione del database è risultata significativamente minore con RBS abilitato, il tempo è risultato inferiore di conseguenza, come illustrato nella figura (vii). Con RBS abilitato, la quantità di tempo impiegata per il backup del database è risultata inferiore per il 98,5% (2.490 secondi rispetto a 38 secondi), mentre la quantità di tempo impiegata per il ripristino del database è risultata inferiore per il 97,7% (1.284 secondi rispetto a 28 secondi). Analogamente, la quantità di tempo impiegata per il backup del database tramite la compressione dei database di SQL Server è risultata inferiore per il 98,8%, mentre la quantità di tempo impiegata per il ripristino di un database con backup compresso è risultata inferiore per il 97,9%. Per il backup del database con compressione dei backup è stata necessaria una quantità di tempo maggiore del 27% e un numero significativamente maggiore di risorse del server SQL Server a causa dell’elaborazione aggiuntiva necessaria per la compressione dei dati. I comandi utilizzati per il backup e il ripristino dei database sono i seguenti: BACKUP DATABASE [WSS_Content] TO DISK = N’O:\WSS_Content’ WITH NOFORMAT, INIT, NAME = N ’WSS_Content-Full Database Backup’, SKIP, NOREWIND, NOUNLOAD; BACKUP DATABASE [WSS_Content] TO DISK = N’O:\WSS_Content’ WITH COMPRESSION, NOFORMAT, INIT, NAME = N’WSS_Content-Full Database Backup’, SKIP, NOREWIND, NOUNLOAD; RESTORE DATABASE [WSS_Content] FROM DISK = N’O:\WSS_Content’ WITH FILE = 1, MOVE N’ WSS_Content’ TO N’J:\ContentDB_Data\WSS_Content.mdf’, MOVE N’WSS_Content_log’ TO N’ S:\ContentDB_Log\WSS_Content_log.LDF’, NOUNLOAD, REPLACE; Quando si utilizza RBS, è necessario eseguire il backup dell’archivio RBS separatamente. Questo backup può essere eseguito in modo asincrono e in parallelo con il backup del database, con l’unico requisito di avviare il backup dell’archivio RBS dopo l’avvio del backup del database. Per eseguire il backup dell’ archivio RBS, è possibile utilizzare diversi meccanismi. Nei test trattati in questo documento è stato misurato il tempo impiegato per il backup dell’archivio tramite un meccanismo di snapshot del disco, nonché una semplice copia di directory sequenziale. Per i 100 GB di contenuto, il tempo impiegato per il backup dell’archivio RBS tramite uno snapshot del disco è stato di 14 secondi, mentre quello impiegato con il comando di copia è stato di 2.578 secondi. Nota: quando si utilizza il provider FILESTREAM, in SharePoint 2010 vengono automaticamente eseguiti il backup e il ripristino sia dei dati BLOB sia dei metadati. Quando si ripristina un database con RBS abilitato, è necessario ripristinare anche l’archivio BLOB. La farm di SharePoint viene considerata completamente ripristinata e accessibile solo al termine del ripristino dell’archivio BLOB. Per i 100 GB di contenuto, il tempo impiegato per il ripristino dell’archivio RBS è stato di 28 secondi utilizzando un meccanismo di snapshot del disco e di 2.880 secondi utilizzando il comando di copia. È utile osservare che l’archivio RBS deve essere ripristinato solo nel caso in cui sia danneggiato o sia in uno stato non coerente. © 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 17 Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare SharePoint IT Docs (itspdocs@microsoft.com).
Microsoft SharePoint Server 2010 Aprile 2011
4. Effetti di RBS sulle prestazioni di
ricostruzione degli indici
Una delle caratteristiche di SharePoint Server è la frammentazione frequente ed estesa delle tabelle del
database back-end di SQL Server in cui è archiviato il contenuto BLOB. Questa frammentazione è per molti
versi caratteristica della progettazione ed è imputabile all’architettura dell’applicazione SharePoint e al
modello di accesso del database back-end di SQL Server. Quando il database viene frammentato, le pagine
di database logicamente contigue non appaiono fisicamente contigue nel file di dati. Le pagine dati, inoltre,
vengono raramente utilizzate alla capacità completa, per cui è necessario un numero maggiore di tali
pagine a bassa densità per l’archiviazione dei dati. Entrambi questi fattori provocano dimensioni del
working set maggiori del necessario, che possono causare prestazioni inferiori.
In SharePoint 2010, tuttavia, la frammentazione viene automaticamente ridotta tramite l’esecuzione di tre
regole dell’analizzatore dell’integrità di SharePoint. Tali regole consentono di controllare regolarmente la
frammentazione degli indici e di eseguire la stored procedure proc_DefragmentIndices per deframmentare
automaticamente gli indici. È necessario tenere presente, tuttavia, che questo processo comporta un
elevato utilizzo di risorse e che l’intera farm di SharePoint diventa non disponibile durante il processo di
ricostruzione degli indici. Le tre regole sono:
I database utilizzati da SharePoint contengono indici frammentati
Uno o più database di ricerca per indicizzazione possono contenere indici frammentati
Uno o più database delle proprietà contengono indici frammentati
L’archiviazione esterna degli oggetti BLOB tramite RBS consente di ridurre significativamente questo
problema, in quanto è necessario meno tempo per ricostruire gli indici in un database di dimensioni minori.
Per misurare gli effetti della ricostruzione degli indici, è stata eseguita una serie di test in cui è stata
forzata un’operazione di ricostruzione degli indici per tutte le tabella nel database del contenuto di
SharePoint. Benché questa situazione possa non essere rappresentativa di una distribuzione reale, in cui gli
indici vengono ricostruiti in base alle esigenze, è stato scelto questo approccio per rendere il test deterministico
e ripetibile. Come parte dei test, è stato misurato il tempo impiegato per la ricostruzione di indici per database
del contenuto di 100 GB e 1 TB con e senza RBS abilitato. È stato inoltre misurato l’impatto di un’operazione di
ricostruzione degli indici sulla disponibilità e le prestazioni della farm di SharePoint.
Senza RBS Con RBS Riduzione
Tempi di ricostruzione degli indici per tutte le 120 secondi 4 secondi 96,7%
tabelle (100 GB)
Tempi di ricostruzione degli indici per tutte le 600 secondi 146 secondi 75,7%
tabelle (1 TB)
Tabella (x) - Frammentazione del database
Come indicato nella tabella (x) precedente, la quantità di tempo impiegata per la ricostruzione degli indici è
inferiore del 96,7% (120 secondi rispetto a 4 secondi) per il database di 100 GB e del 75,7% (600 secondi
rispetto a 146 secondi) per il database di 1 TB quando RBS è abilitato. Poiché l’applicazione Web di
SharePoint non è disponibile per la maggior parte del tempo durante la ricostruzione degli indici, la durata
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 18
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Microsoft SharePoint Server 2010 Aprile 2011
ridotta influisce direttamente sulla disponibilità dell’applicazione SharePoint e consente un’esecuzione più
frequente dell’operazione di ricostruzione degli indici, garantendo in tal modo prestazioni più coerenti.
Sono stati eseguiti più test per misurare gli effetti della ricostruzione degli indici su un database di 100 GB
senza RBS. Nella figura (viii) seguente vengono indicati i risultati per uno di tali test, in cui è stato simulato
un carico di lavoro per un caricamento di documenti e in cui è stata eseguita un’operazione di ricostruzione
degli indici durante lo stato stazionario.
Figura (viii) - Effetti dell’operazione di ricostruzione degli indici sulle prestazioni
Come è possibile osservare durante il normale funzionamento (dalle 6.28 alle 6.56), la velocità di
caricamento dei file prevista è in media di 85 file al secondo. Alle 6.56 è stata eseguita un’operazione di
ricostruzione degli indici, durata 120 secondi. Durante questo periodo di tempo la velocità di caricamento
dei file è calata fino quasi a zero, come indicato nel grafico. Questo dato suggerisce che l’insieme di
operazioni utente eseguite durante questo periodo di tempo viene bloccato per un timeout di almeno 120
secondi e produce la visualizzazione di un messaggio di errore all’utente finale.
Considerando che l’operazione di ricostruzione degli indici quando RBS è abilitato nel database dura solo 4
secondi, l’intervallo è talmente minimo che l’impatto non è visibile. La flessione nelle prestazioni è talmente
irrilevante da essere di difficile rappresentazione nel grafico ed è stata pertanto intenzionalmente omessa
dal grafico. Benché il test sia stato eseguito utilizzando un caricamento di file come carico di lavoro,
l’effetto sulla disponibilità della farm di SharePoint è identico su tutti i tipi di transazioni.
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 19
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Microsoft SharePoint Server 2010 Aprile 2011
5. Effetti di RBS sui tempi di risposta delle
transazioni di SharePoint
Come descritto nella sezione precedente, l’abilitazione della caratteristica RBS produce database del
contenuto di SharePoint di dimensioni minori, che a loro volta richiedono un numero inferiore di risorse nel
server di database SQL Server per l’esecuzione di query. Le risorse risparmiate vengono liberate per
elaborare più rapidamente le query esistenti e per gestire più query.
In questi test, i cui risultati vengono riassunti in questa sezione, sono stati misurati gli effetti
dell’abilitazione di RBS sui tempi di risposta delle transazioni. Per i test è stato utilizzato come carico di
lavoro la combinazione completa di transazioni di SharePoint, illustrata nella sezione Metodologia dei test.
Questo carico di lavoro è stato eseguito in 6 driver di carico che hanno simulato un carico utente di 100
utenti che eseguono la transazione di SharePoint in media ogni 15 secondi. Ogni test è stato intensificato
per 5 minuti e quindi eseguito continuamente per una durata di 2 ore. I tempi medi di risposta sono stati
misurati complessivamente per le due ore di prestazioni in stato stazionario del test. Nella tabella (xi)
seguente vengono indicati questi risultati di alto livello.
Criterio di valutazione Senza RBS Con RBS Riduzione
Carico utente massimo 100 100 0,0%
Richieste al secondo 84 84,3 -0,4%
Richieste non riuscite 0 0 0,0%
21
Tempo medio di risposta 28 millisecondi millisecondi 25,0%
Test al secondo 6,4 6,42 -0,3%
160
Tempo medio pagina 210 millisecondi millisecondi 23,8%
Tabella (xi) - Criteri di valutazione per i test sui tempi di risposta delle transazioni
Il tempo medio di risposta in tutte le transazioni è risultato minore del 25% (28 millisecondi rispetto a 21
millisecondi) quando RBS è abilitato nel database del contenuto. Questo dato suggerisce che quando RBS è
abilitato, in media i tempi di risposta delle transazioni di SharePoint per gli utenti finali sono più rapidi del
25% in un’ampia gamma di transazioni. Considerando che la produttività e la soddisfazione degli utenti di
SharePoint dipendono spesso dai tempi di risposta delle transazioni di SharePoint, una riduzione del 25%
produce livelli superiori di produttività e soddisfazione.
Nella tabella (xii) seguente vengono suddivisi ulteriormente i tempi di risposta per ciascuna delle
quattordici transazioni degli utenti finali.
Percentua Durata media della
le transazione (s)
Transazione Riduzione
transazio Senza
ne Con RBS
RBS
Pagina pubblica Sito personale 16,0% 0,14 0,08 42,9%
Home page 25,0% 0,43 0,22 48,8%
Flusso di lavoro pagine 1,1% 109,00 109,00 0,0%
Creazione di una pagina 6,0% 15,72 15.67 0,3%
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 20
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Microsoft SharePoint Server 2010 Aprile 2011
Creazione di un sito di
pubblicazione 1,0% 13,00 12,70 2,3%
Creazione di un sito del team 1,0% 17,90 18,30 -2,2%
Download di un documento 12,2% 4,03 4,03 0,0%
Pagina Modifica profilo per Sito
personale 6,9% 29,84 29,90 -0,2%
Pagina grande 10,1% 0,12 0,09 25,0%
Query di ricerca 14,8% 60,00 60,10 -0,2%
Strumento di gestione del sito 1,0% 0,45 0,31 31,1%
Caricamento di documenti 4,9% 30,20 30,50 -1,0%
Tabella (xii) - Tempi di risposta delle transazioni
Figura (ix) - Tempi di risposta delle transazioni
Come illustrato in precedenza, i tempi medi di risposta per 10 delle 14 transazioni sono uguali o migliori quando
RBS è abilitato, mentre quattro delle transazioni mostrano un miglioramento prossimo al 50%. Per le quattro
transazioni con un rallentamento delle prestazioni, il rallentamento è inferiore al 2,2% e nella maggior parte dei
casi non risulta osservabile da un utente reale. In generale, quando RBS è abilitato, è probabile che si osservi un
miglioramento delle prestazioni per file di grandi dimensioni, in particolare per i sistemi di I/O associati, in quanto
l’I/O viene reindirizzato all’esterno del database di SQL Server. Per file di dimensioni minori può verificarsi un
relativo peggioramento delle prestazioni, in quanto il front-end Web deve emettere due richieste via cavo anziché
una. È tuttavia probabile che l’aumento relativo non sia osservabile anche nel caso di una differenza in percentuale
elevata, perché i tempi di accesso ai file sono trascurabili.
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 21
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Microsoft SharePoint Server 2010 Aprile 2011
6. Effetti di RBS sulle prestazioni della ricerca
per indicizzazione
La ricerca è una componente integrante della maggior parte delle distribuzioni di SharePoint e uno dei
servizi di SharePoint che comporta l’utilizzo più elevato di risorse. Molte distribuzioni aziendali prevedono
una percentuale elevata di utenti che accedono ai dati dal portale di ricerca, anziché accedere direttamente
al sito o al documento. Poiché questo comportamento provoca un ingente utilizzo della ricerca, non
sorprende come per molti clienti la ricerca sia diventata la principale causa di utilizzo delle risorse o
costituisca spesso un collo di bottiglia.
La ricerca di SharePoint è costituita da due componenti, ovvero la ricerca per indicizzazione e la query di
ricerca. Tramite il processo di ricerca per indicizzazione i crawler eseguono la ricerca nel corpo di ricerca e
costruiscono, o aggiornano, l’indice di ricerca. L’indice di ricerca di SharePoint è costituito da due parti,
ovvero un database di ricerca e un file flat dell’indice di ricerca. Le query di ricerca a loro volta utilizzano il
database e l’indice di ricerca per restituire risultati per query di ricerca degli utenti.
In questi test, i cui risultati vengono riassunti in questa sezione, è stato misurato il tempo impiegato per la
ricerca per indicizzazione nel corpo di ricerca tramite un singolo server applicazioni con impostazioni di
ricerca predefinite. Nella tabella (xiii) seguente viene presentato il riepilogo dei risultati per il tempo
impiegato con e senza RBS. I risultati della query di ricerca sono già stati riassunti nella sezione precedente
e pertanto non verranno ripetuti in questa sezione.
Operazione N. di oggetti Senza RBS Con RBS Riduzione
Ricerca per 503.206 150 minuti 146 minuti 2,7%
indicizzazione
completa
Tabella (xiii) - Tempi necessari per la ricerca per indicizzazione
Figura (x) - Riepilogo della ricerca per indicizzazione completa
Come indicato nei risultati precedenti, l’abilitazione di RBS nei database del corpo di ricerca ha un effetto
molto trascurabile sulle prestazioni, migliorandole solo del 2,7%. Questo dato è in linea con le previsioni, in
quanto l’elaborazione eseguita in entrambi i casi è all’incirca identica.
© 2011 Microsoft Corporation. Tutti i diritti riservati. Pagina 22
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs (itspdocs@microsoft.com).Puoi anche leggere
