Ottimizzazione di Office SharePoint Server per ambienti WAN

Contenuto dell'articolo:

• Progettazione di topologie per la rete WAN

• Ottimizzazione del processo di ricerca per indicizzazione del contenuto

• Acceleratori WAN e altri strumenti di terze parti

• Progettazione di pagine per download più rapidi

• Ottimizzazione della memorizzazione nella cache per ambienti WAN

In questo articolo vengono evidenziati metodi specifici tramite cui è possibile ottimizzare la soluzione di Microsoft Office SharePoint Server 2007 per ottenere prestazioni migliori in ambienti WAN.

Progettazione di topologie per la rete WAN

È possibile configurare in modo flessibile ruoli del server in una farm di Microsoft Office SharePoint Server 2007 per ottimizzare la soluzione in presenza di requisiti specifici relativi alle prestazioni o alla disponibilità. In un ambiente WAN è importante acquisire familiarità con diverse caratteristiche tecniche dei ruoli del server. Oltre a consentire la pianificazione dei requisiti generali relativi a prestazioni e disponibilità, la comprensione di tali caratteristiche può semplificare l'ottimizzazione della topologia della server farm per ambienti WAN.

Ottimizzazione della topologia per la ricerca per indicizzazione del contenuto

Per impostazione predefinita, Microsoft Office SharePoint Server 2007 utilizza tutti i server Web per la ricerca per indicizzazione del contenuto in una server farm. Quando la server farm è configurata per l'utilizzo di tutti i server Web per la ricerca per indicizzazione, il server di indicizzazione invia richieste a ogni server Web nella farm.

La ricerca per indicizzazione del contenuto nella farm causa un carico elevato nei server Web, che provoca in genere variazioni di tensione e sovratensioni nel traffico di rete, ed è gravosa a livello di CPU e di memoria. La ricerca per indicizzazione del contenuto nella farm può causare un traffico maggiore nella rete rispetto a quello provocato dalle richieste degli utenti. Questo traffico di rete può influire negativamente sulle prestazioni di tutti i server Web nella server farm e pertanto aumentare i tempi di risposta alle richieste di contenuto degli utenti dai siti di SharePoint.

Negli ambienti WAN è consigliabile configurare un server Web dedicato per la ricerca per indicizzazione del contenuto, in particolare se la ricerca per indicizzazione viene eseguita in una server farm che contiene più di 500 gigabyte (GB) di contenuto o nella rete WAN. Per garantire che la ricerca per indicizzazione del contenuto non influisca sulle richieste degli utenti, rimuovere il server Web dedicato dalla rotazione per il bilanciamento del carico di rete. Questa soluzione è particolarmente importante in ambienti globali in cui gli orari non di punta di una farm regionale, ovvero gli orari più probabili per la pianificazione dei processi di ricerca per indicizzazione, coincidono con gli orari di punta della farm centrale.

Configurazione di un server Web dedicato per la ricerca per indicizzazione di contenuto locale

Per ottenere prestazioni ottimali durante la ricerca per indicizzazione di contenuto locale nella farm, configurare il server di indicizzazione come server Web dedicato per la ricerca per indicizzazione se tale server di indicizzazione dispone di capacità di memoria sufficiente per entrambi i ruoli.

Nella figura seguente viene illustrata una farm ottimizzata con un server Web dedicato per l'indicizzazione del contenuto.

Utilizzando lo stesso server come server di indicizzazione e server Web dedicato, si elimina la necessità che il server di indicizzazione invii richieste a un server diverso durante la ricerca per indicizzazione del contenuto. In questo modo, è possibile aumentare le prestazioni della ricerca per indicizzazione e ridurre il traffico complessivo nella rete. Se questo metodo non è disponibile, è possibile utilizzare un server diverso nella server farm.

È possibile configurare l'indicizzatore per l'utilizzo di un server Web dedicato tramite una delle operazioni seguenti:

• Configurare il servizio di ricerca di Office SharePoint Server in Amministrazione centrale SharePoint.

• Modificare direttamente il file Hosts.

Per ulteriori informazioni, vedere le risorse seguenti:

• Configurare un server Web front-end dedicato per la ricerca per indicizzazione (Office SharePoint Server 2007).

• Configurare un server Web front-end dedicato per la ricerca per indicizzazione utilizzando l'interfaccia utente (Office SharePoint Server 2007)

• Configurare un server Web front-end dedicato per la ricerca per indicizzazione modificando il file host (Office SharePoint Server 2007)

Configurazione di un server Web dedicato per la ricerca per indicizzazione in farm remote

Per ottenere prestazioni ottimali per le farm regionali durante la ricerca per indicizzazione di contenuto incluso in una farm regionale, configurare il server di indicizzazione nella farm centrale per l'utilizzo di un server Web dedicato nella farm regionale.

Nella figura seguente vengono illustrate due farm regionali, ognuna ottimizzata con un server Web dedicato per l'indicizzazione del contenuto.

• Nella farm regionale 1 un server è dedicato al ruolo del server Web. La farm centrale e la farm regionale 1 utilizzano entrambe questo server Web dedicato per la ricerca per indicizzazione del contenuto.

• La farm regionale 2 è configurata analogamente alla farm centrale con il ruolo del server Web distribuito anche nel server di indicizzazione.

Si noti che il server di indicizzazione nella farm centrale non utilizza il ruolo del server Web nella farm centrale per la ricerca per indicizzazione del contenuto in una farm remota, ma contatta direttamente i server Web nelle farm remote.

Se nel caso illustrato nella figura precedente le farm regionali eseguono la ricerca per indicizzazione del contenuto contemporaneamente alla farm centrale, le prestazioni risulteranno migliori con la configurazione della farm regionale 1 per i motivi seguenti:

• Le prestazioni della ricerca per indicizzazione locale nella farm regionale 1 sono migliori perché il server Web dedicato è in un server distinto. Di conseguenza, la farm centrale non influisce sulle prestazioni del server di indicizzazione.

• I tempi di ricerca per indicizzazione nella rete WAN sono migliori. La ricerca per indicizzazione richiede una quantità di tempo minore perché il server Web dedicato nella farm regionale risponde in modo più efficiente di quanto non farebbe se si trovasse in un server condiviso con il server di indicizzazione.

• Il processo di ricerca per indicizzazione della farm centrale risulta migliore in quanto il server di indicizzazione nella farm centrale comunica con un server Web dedicato.

Se si implementa la configurazione della topologia illustrata tramite la farm regionale 2, è possibile ottimizzare le prestazioni pianificando processi di ricerca per indicizzazione nelle due farm, in modo che non si sovrappongano.

Per utilizzare un server Web dedicato in una farm remota per la ricerca per indicizzazione del contenuto, è necessario modificare direttamente il file Hosts. Assicurarsi di modificare il file Hosts nella farm in cui viene eseguita la ricerca per indicizzazione del contenuto e non nella farm remota.

In una soluzione globale in cui una farm centrale esegue la ricerca per indicizzazione in farm regionali, modificare il file Hosts in modo che includa una voce per ogni applicazione Web in ogni farm regionale in cui si desidera eseguire la ricerca per indicizzazione. Tale voce nel file Hosts deve includere l'indirizzo IP del server Web dedicato, seguito dal nome dell'applicazione Web, come negli esempi seguenti:

• 10.10.10.4 SitiTeam

• 10.10.10.4 SitiPersonali

• 10.10.10.4 Marketing

• 10.10.10.4 Vendite

Per ulteriori informazioni, vedere Configurare un server Web front-end dedicato per la ricerca per indicizzazione modificando il file host (Office SharePoint Server 2007).

Ottimizzazione per le prestazioni delle query

Le prestazioni delle query per gli utenti rappresentano una considerazione essenziale durante la distribuzione di Microsoft Office SharePoint Server 2007 in un ambiente WAN. Quando un utente esegue una query, la query viene inviata a un server Web, che comunica con il server di query per creare un elenco di risultati e quindi comunica con il computer che esegue Microsoft SQL Server per estendere l'elenco di risultati con un testo di riepilogo, gli URL e la limitazione per motivi di protezione.

In base alla comunicazione tra server necessaria per restituire i risultati delle query, è possibile configurare la topologia per ottimizzare le prestazioni delle query. Operazioni di ottimizzazione ridotte all'interno della server farm possono aumentare le prestazioni complessive percepite tra computer client e server nella rete WAN.

L'ottimizzazione più importante consiste nell'utilizzare un server Web dedicato per la ricerca per indicizzazione del contenuto, come illustrato nella sezione precedente. In questo modo, i server Web saranno disponibili per le richieste degli utenti e non saranno soggetti a overload da parte dei processi di indicizzazione.

Sono quindi disponibili alcune opzioni per la distribuzione del ruolo query, ognuna delle quali offre un tipo diverso di ottimizzazione. Ogni opzione crea un equilibrio diverso tra gestione ottimale delle richieste di query e riduzione dei viaggi di rete nella rete locale tra server della farm. Nella tabella seguente è incluso un riepilogo di tali opzioni di configurazione e vengono indicati gli svantaggi correlati a ogni opzione.

Configurazione	Svantaggi
Distribuire il ruolo query in tutti i server Web.	È possibile ospitare il ruolo query nei server Web per ridurre le comunicazioni round trip tra server nella farm. Di conseguenza, vengono ottimizzate le prestazioni delle query. Poiché due ruoli del server sono ospitati negli stessi server, tuttavia, le prestazioni complessive dei server Web possono subire effetti negativi se tali server vengono utilizzati in modo gravoso. Di conseguenza, assicurarsi di distribuire un numero sufficiente di server Web per elaborare le richieste degli utenti durante gli orari di punta. Benché questa configurazione consenta di ottimizzare le prestazioni delle query per gli utenti, comporta uno svantaggio per il back-end della farm. Il server di indicizzazione propaga il catalogo dell'indice in ogni server di query in una farm. Se il ruolo query viene distribuito in più server Web, per questa operazione sono necessarie risorse dei server maggiori durante la propagazione dell'indice.
Dedicare uno o più server al ruolo query.	Dedicando uno o più server per ospitare il ruolo query, è possibile ottimizzare tali server in modo che utilizzino tutte le risorse disponibili per eseguire il ruolo in modo efficiente. Questa configurazione, inoltre, comporta in genere la distribuzione di un numero minore di server di query. Per questa configurazione, tuttavia, è necessario un numero maggiore di comunicazioni round trip tra server nella farm per gestire le richieste di query dai server Web e per aggiornare gli indici di contenuto durante la propagazione degli indici.
Distribuire i ruoli query e indice nello stesso server.	È possibile distribuire il ruolo query e il ruolo indice nello stesso server. In questo modo, è possibile ottimizzare la comunicazione della farm, in quanto la propagazione dell'indice non è più necessaria. Questa configurazione, tuttavia, limita a un unico server il numero di server in grado di ospitare il ruolo query. Ciò è dovuto al fatto che quando il ruolo query viene distribuito in un server di indicizzazione, il server di indicizzazione non è più in grado di propagare gli indici di contenuto in altri server nella farm.

Oltre all'ottimizzazione di una singola farm per le prestazioni delle query, sono disponibili diverse opzioni per l'ottimizzazione di scenari con più farm:

• In uno scenario con servizi condivisi tra farm in cui una farm padre fornisce il servizio di ricerca per una farm figlio, la distribuzione di un server di query dedicato nella farm padre consente a quest'ultima di gestire le query di ricerca dalle farm figlio senza influire sulle prestazioni di altre opzioni utente nella farm padre. In uno scenario con servizi condivisi tra farm il server Web nella farm figlio contatta direttamente il server di query e il server database nella farm padre anziché comunicare tramite il server Web nella farm padre. Si noti che uno scenario con servizi condivisi tra farm in cui una farm padre fornisce servizi a una farm figlio non è supportato in una rete WAN. Le organizzazioni di grandi dimensioni, tuttavia, possono includere un sito centrale con una farm padre che fornisce servizi e una farm figlio che fornisce siti e contenuto. In tale scenario è possibile configurare la farm padre per l'esecuzione della ricerca per indicizzazione del contenuto in farm regionali in un ambiente geograficamente distribuito con più farm senza influire sulle prestazioni della farm figlio che fornisce siti e contenuto agli utenti nel sito centrale.

• In un ambiente geograficamente distribuito con più farm in cui una farm centrale esegue la ricerca per indicizzazione del contenuto in farm regionali è possibile ottimizzare sia la ricerca per indicizzazione del contenuto sia le prestazioni delle query configurando i server nei modi seguenti:

  • Distribuire il ruolo del server Web nel server di indicizzazione in tutte le farm. Rimuovere tale server dalla rotazione per il bilanciamento del carico di rete e configurare il processo di ricerca per indicizzazione della farm padre in modo che utilizzi questo server Web dedicato per la ricerca per indicizzazione del contenuto.

  • Distribuire il server di query in tutti i server Web con carico bilanciato in ogni farm.

Separazione geografica dei server della farm

Per la comunicazione tra server in una server farm, sono necessarie connessioni di rete affidabili per gestire in modo adeguato le richieste degli utenti ed evitare colli di bottiglia delle prestazioni. Il requisito di rete standard prevede che tutti i server all'interno di una server farm si trovino nello stesso data center all'interno della stessa rete LAN. La separazione dei server della farm tra collegamenti WAN non è supportata.

Oltre a queste linee guida, sussistono alcuni requisiti specifici che consentono l'ubicazione di uno o più server Web in una posizione geografica diversa rispetto agli altri server della farm. In questo scenario i server Web si trovano in un data center diverso, ma sono connessi alla stessa rete LAN del computer che esegue SQL Server.

Nota

Le linee guida seguenti rappresentano i requisiti relativi alle configurazioni supportate per uno scenario di distribuzione non descritto in precedenza.

Le linee guida per questo scenario sono preliminari e soggette a modifica in seguito a testing aggiuntivo e offrono un insieme di indicazioni che è possibile utilizzare per il testing e la distribuzione fino a quando non saranno disponibili linee guida testate ufficiali. Utilizzare tali linee guida come base per il testing nell'ambiente e per determinare la soglia personale di qualità e prestazioni.

Questo scenario offre supporto ragionevole dal punto di vista commerciale. Se ulteriori fasi di testing o risultati nell'ambiente indicano che lo scenario comporta problemi significativi, è necessario spostare i server Web in una posizione più vicina al server database se questa soluzione consente di risolvere i problemi.

Questo scenario di distribuzione soddisfa i requisiti preliminari relativi alle configurazioni supportate se si verificano le condizioni seguenti:

• Il collegamento di rete tra un server Web e il server database ha una latenza inferiore a 1 millisecondo (ms). Per ottenere questa latenza, il server Web è idealmente ubicato a non più di 16 chilometri dal server database. Con configurazioni di rete ottimali, è possibile ottenere, benché raramente, una latenza inferiore a 1 millisecondo a distanze pari fino a 160 chilometri. Se la distanza è compresa tra 16 e 160 chilometri, consultare i provider di rete e hardware per verificare se siano in grado di garantire un livello di servizio con latenza inferiore a 1 millisecondo. Le configurazioni in cui i server della farm sono separati da distanze maggiori di 160 chilometri non sono supportate. Nel misurare la latenza tra due data center che ospitano server della stessa farm, utilizzare lo strumento Ping per identificare la latenza da un server Web nel data center remoto al server database nel data center primario. Dividere per due i risultati del round trip.

• È disponibile larghezza di banda sufficiente nel collegamento per gestire il traffico tra il server Web e altri server nella farm.

• Tutti i ruoli del server che contribuiscono ai servizi condivisi si trovano nello stesso data center del server database. Sono inclusi i ruoli indice, query ed Excel Services.

• Tutti i server nella farm si trovano nello stesso segmento di rete. Non vi è alcun passaggio nei router in corrispondenza del livello dati e, letteralmente, il livello fisico connette i server. I router e gli interruttori aumentano la latenza anche se la connessione di rete è molto veloce.

• Se il tipo di carico gestito dal server Web è un sottoinsieme di richieste di esplorazione degli utenti, Microsoft Office SharePoint Server 2007 sarà prevedibilmente in grado di tollerare una certa latenza tra il server Web e il server database. D'altro canto, è probabile che le pagine contenenti web part, ricerche per indicizzazione o comandi Stsadm numerosi o personalizzati vengano gestite in modo meno efficiente.

• I server all'interno della server farm non utilizzano fusi orari diversi, in quanto devono essere tutti sincronizzati in base allo stesso fuso orario.

Ottimizzazione del processo di ricerca per indicizzazione del contenuto

Le modalità di pianificazione e configurazione dei processi di ricerca per indicizzazione possono influire sulle prestazioni e l'affidabilità. Per migliorare la ricerca per indicizzazione nella rete WAN, è possibile ottimizzare i processi seguenti:

• Coordinamento della ricerca per indicizzazione per origini di contenuto.

• Configurazione delle frequenze di ricerca per indicizzazione e coordinamento di ricerche per indicizzazione complete e incrementali.

• Configurazione delle impostazioni di ricerca per indicizzazione.

Coordinamento della ricerca per indicizzazione per origini di contenuto

In ambienti globali in cui una farm centrale esegue la ricerca per indicizzazione di contenuto in farm regionali tramite collegamenti WAN è importante pianificare le origini di contenuto, in quanto rappresentano le unità di contenuto che è possibile pianificare e gestire.

Aggiungere un'origine di contenuto per la ricerca quando è necessario eseguire le operazioni seguenti:

• Eseguire la ricerca per indicizzazione di diversi tipi di archivi.

• Eseguire la ricerca per indicizzazione di alcuni archivi con una pianificazione diversa rispetto ad altri.

• Limitare o aumentare la quantità di contenuto sottoposto a ricerca per indicizzazione.

A ciascuno di questi casi è possibile applicare l'ottimizzazione della ricerca per indicizzazione del contenuto nella rete LAN. Come requisito minimo, è necessario creare un'origine di contenuto diversa per ogni farm regionale. In questo modo, è possibile pianificare la ricerca per indicizzazione in ogni farm regionale in base agli orari di punta locali e alla pianificazione della manutenzione della farm.

È inoltre necessario creare diverse origini di contenuto per una singola farm regionale in base ai criteri seguenti:

• Creare origini di contenuto distinte per il contenuto di cui si desidera eseguire ricerche per indicizzazione con maggiore frequenza, ad esempio il contenuto per la collaborazione, e con minore frequenza, ad esempio il contenuto pubblicato.

• Creare un'origine di contenuto distinta per il contenuto pubblicato in base a una pianificazione regolare. Se, ad esempio, il contenuto di un insieme di siti specifico viene aggiornato solo ogni venerdì, è possibile creare un'origine di contenuto distinta per sincronizzare le pianificazioni della ricerca per indicizzazione con gli aggiornamenti del contenuto.

• Creare origini di contenuto in base alla quantità di contenuto di cui è possibile eseguire la ricerca per indicizzazione in un collegamento WAN durante gli orari di punta della farm regionale. Se, ad esempio, l'obiettivo consiste nell'eseguire la ricerca per indicizzazione in un archivio di grandi dimensioni una volta alla settimana, è possibile dividere l'archivio in blocchi di contenuto, da cinque a sette, in modo da poter eseguire la ricerca per indicizzazione nelle ore notturne e quindi scaglionare i processi di ricerca per indicizzazione nel corso di ogni settimana.

• Creare un'origine di contenuto distinta per il contenuto esterno ai siti di Microsoft Office SharePoint Server 2007. In Microsoft Office SharePoint Server 2007 e Microsoft Windows SharePoint Services 3.0 gli oggetti modificati vengono registrati nel registro delle modifiche, inclusi gli aggiornamenti agli elenchi di controllo di accesso. Il registro delle modifiche consente di eseguire la ricerca per indicizzazione incrementale solo del contenuto che ha subito modifiche, riducendo notevolmente la quantità di tempo necessaria per una nuova ricerca per indicizzazione di un'origine di contenuto. Non è possibile eseguire la ricerca per indicizzazione incrementale di contenuto archiviato in origini esterne. Di conseguenza, il processo di ricerca per indicizzazione di tali origini di contenuto deve essere gestito separatamente. Per ulteriori informazioni, vedere Registro delle modifiche (informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=106007&clcid=0x410) (informazioni in lingua inglese) .

Per ulteriori informazioni sulla pianificazione della ricerca per indicizzazione e delle origini di contenuto, vedere Pianificare la ricerca per indicizzazione di contenuto (Office SharePoint Server).

Configurazione delle frequenze di ricerca per indicizzazione e coordinamento di ricerche per indicizzazione complete e incrementali.

Come illustrato nella sezione precedente, un motivo importante per cui creare origini di contenuto distinte consiste nella possibilità di eseguire la ricerca per indicizzazione del contenuto in pianificazioni diverse. Questo aspetto si rivela particolarmente importante in ambienti in cui viene eseguita la ricerca per indicizzazione di contenuto in collegamenti WAN con latenze elevate. Quando si pianificano processi di ricerca per indicizzazione per farm regionali, tenere presenti i fattori seguenti:

• Tempi di inattività pianificati e periodi di utilizzo di punta nella farm regionale.

• Frequenza di modifica o aggiornamento del contenuto.

• Disponibilità della larghezza di banda e latenza del collegamento WAN, considerando anche gli altri processi che utilizzano il collegamento WAN.

Per ogni origine di contenuto in Microsoft Office SharePoint Server 2007 e Microsoft Windows SharePoint Services 3.0 è possibile specificare un determinato momento per l'esecuzione di ricerche per indicizzazione complete e uno diverso per le ricerche per indicizzazione incrementali. Si noti che è necessario eseguire una ricerca per indicizzazione completa per un'origine di contenuto specifica prima di poter eseguire una ricerca per indicizzazione incrementale. Se si sceglie una ricerca per indicizzazione incrementale di contenuto non ancora sottoposto a questo tipo di ricerca, il sistema eseguirà una ricerca per indicizzazione completa.

Nel determinare le pianificazioni della ricerca incrementale per un ambiente WAN, tenere presenti le procedure consigliate seguenti:

• Scaglionare le pianificazioni delle ricerche per indicizzazione in modo da distribuire nel tempo l'utilizzo dei collegamenti WAN, perché questi non risultino saturi.

• Pianificare ricerche per indicizzazione complete solo se necessario. È consigliabile eseguire ricerche per indicizzazione complete con minore frequenza rispetto alle ricerche per indicizzazione incrementali.

• Pianificare ricerche per indicizzazione incrementali per ogni origine di contenuto nei periodi in cui i server che ospitano il contenuto sono disponibili e quando la richiesta delle risorse del server è limitata.

• Alcune modifiche amministrative in Microsoft Office SharePoint Server 2007 e Microsoft Windows SharePoint Services 3.0, ad esempio l'applicazione di un Service Pack o il ripristino di un database, attivano automaticamente una ricerca per indicizzazione completa durante la successiva ricerca per indicizzazione pianificata normalmente. Pianificare le modifiche amministrative per cui è necessaria una ricerca per indicizzazione completa in modo che vengano eseguite poco prima della pianificazione di tali ricerche. È consigliabile, ad esempio, pianificare la creazione della regola di ricerca per indicizzazione prima della successiva ricerca per indicizzazione pianificata, in modo che non sia necessaria un'ulteriore ricerca per indicizzazione completa. Per ulteriori informazioni sulle modifiche amministrative per cui è necessaria una ricerca per indicizzazione completa, vedere la sezione relativa ai motivi per cui eseguire una ricerca per indicizzazione completa in Pianificare la ricerca per indicizzazione di contenuto (Office SharePoint Server).

Importante

Dopo avere applicato l'Aggiornamento dell'infrastruttura per Microsoft Office Servers, gli aggiornamenti successivi e il ripristino dei database non attiveranno automaticamente una ricerca per indicizzazione completa. Per questo motivo, quando si applicano aggiornamenti successivi o si ripristina un database, la ricerca per indicizzazione continua in base alla normale pianificazione definita dalle regole di ricerca per indicizzazione. Per ulteriori informazioni, vedere Pianificare la ricerca per indicizzazione di contenuto (Office SharePoint Server).

Oltre a queste procedure consigliate valide per la ricerca per indicizzazione di contenuto in singoli siti regionali, verificare che la pianificazione complessiva della ricerca per indicizzazione di una farm centrale non provochi un sovraccarico nel server di indicizzazione. Basare le ricerche per indicizzazione simultanee sulla capacità di cui dispone il server di indicizzazione per eseguirle. Le prestazioni del server di indicizzazione e dei server che ospitano il contenuto determinano il limite di sovrapposizione possibile delle ricerche per indicizzazione. Una strategia per la pianificazione delle ricerche per indicizzazione può essere sviluppata nel tempo, man mano che si acquisisce familiarità con le normali durate delle ricerche per indicizzazione per ogni origine di contenuto.

Per ulteriori informazioni sulla pianificazione della ricerca per indicizzazione e delle origini di contenuto, vedere Pianificare la ricerca per indicizzazione di contenuto (Office SharePoint Server).

Configurazione delle impostazioni di ricerca per indicizzazione

È possibile ottimizzare diverse impostazioni di ricerca per indicizzazione specifiche in determinati ambienti WAN per aumentare l'affidabilità dei processi di ricerca per indicizzazione. Sono disponibili le impostazioni seguenti:

• Impostazioni di timeout per la ricerca

• Regole di impatto del crawler

Impostazioni di timeout per la ricerca

Gli amministratori della farm possono specificare il tempo di attesa desiderato per il server durante la connessione ad altri servizi e il tempo di attesa del server prima di riconoscere una richiesta di contenuto. Se si aggiungono origini di contenuto sottoposte a ricerca per indicizzazione tramite collegamenti WAN, aumentare le impostazioni di timeout come misura preventiva in base alla latenza complessiva del collegamento. È possibile modificare le impostazioni di timeout in qualsiasi momento in base alle effettive prestazioni della ricerca per indicizzazione del contenuto in un collegamento WAN.

Per specificare le impostazioni di timeout per il servizio di ricerca di Office SharePoint Server, eseguire la procedura seguente.

Specificare le impostazioni di timeout

1. Nella scheda Gestione applicazioni di Amministrazione centrale fare clic su Gestisci servizio di ricerca nella sezione Ricerca.

2. Nella sezione Impostazioni di ricerca a livello di farm della pagina Gestisci servizio di ricerca fare clic su Impostazioni di ricerca a livello di farm.

3. Nella pagina Gestisci impostazioni di ricerca a livello di farm eseguire le operazioni seguenti nella sezione Impostazioni di timeout:

   • Nella casella Durata connessione (in secondi) digitare il numero di secondi desiderati per l'attesa del server durante la connessione ad altri servizi.

   • Nella casella Tempo di riconoscimento della richiesta (in secondi) digitare il numero di secondi di attesa da parte del server prima che un altro servizio riconosca una richiesta di connessione al servizio.

4. Fare clic su OK.

Regole di impatto del crawler

Le regole di impatto del crawler consentono di determinare il numero di documenti necessari e sottoposti a ricerca per indicizzazione simultaneamente. Le regole di impatto del crawler consentono inoltre agli amministratori di gestire l'impatto dei processi di ricerca per indicizzazione sui collegamenti WAN.

Per ogni regola di impatto del crawler è possibile specificare un singolo URL oppure è possibile utilizzare caratteri jolly nel percorso URL per includere un blocco di URL a cui applicare la regola. È quindi possibile specificare il numero di richieste simultanee di pagine inviate all'URL specifico oppure scegliere di inviare richieste solo a un documento per volta e attendere un determinato numero di secondi tra le richieste.

Durante la distribuzione iniziale, impostare le regole di impatto del crawler per l'utilizzo dei collegamenti WAN in modo quanto più efficiente possibile, ma continuando a garantire la ricerca per indicizzazione di una quantità di contenuto sufficiente e con la frequenza appropriata per assicurare un livello di aggiornamento adeguato del contenuto. In seguito, durante la fase operativa, sarà possibile modificare le regole di impatto del crawler in base alle esperienze e ai dati inclusi nei registri di ricerca per indicizzazione.

Per aggiungere una regola di impatto del crawler, eseguire la procedura seguente.

Aggiungere una regola di impatto del crawler

1. Nella scheda Gestione applicazioni di Amministrazione centrale fare clic su Gestisci servizio di ricerca nella sezione Ricerca.

2. Nella sezione Impostazioni di ricerca a livello di farm della pagina Gestisci servizio di ricerca fare clic su Regole impatto crawler.

3. Nella pagina Regole impatto crawler fare clic su Aggiungi regola.

4. Nella pagina Aggiungi regola impatto crawler digitare il nome del sito che verrà associato alla regola di impatto del crawler nella casella Sito della sezione Sito.

   Nota

   Quando si digita l'URL, è necessario escludere il protocollo. Escludere, ad esempio, http:// o file://.

5. Nella sezione Frequenza richieste selezionare una delle opzioni seguenti:

   • Richiedi il numero massimo di documenti specificato per una singola operazione senza attesa tra richieste successive. Se si sceglie questa opzione, utilizzare l'elenco Richieste contemporanee per specificare il numero di documenti che si desidera venga richiesto dal crawler per una singola operazione durante la ricerca per indicizzazione dell'URL. È possibile specificare il numero massimo di richieste che il servizio di ricerca di Office SharePoint Server può effettuare in una singola operazione durante la ricerca per indicizzazione dell'URL.

   • Richiedi un documento alla volta e attendi il periodo di tempo specificato tra le richieste. È possibile specificare un ritardo (in secondi) tra le richieste durante la ricerca per indicizzazione dell'URL. Quando questa opzione è selezionata, il servizio di ricerca di Office SharePoint Server effettua una richiesta per sito alla volta e quindi attende il periodo di tempo specificato prima di effettuare la richiesta successiva. Nella casella Tempo di attesa (in secondi) digitare il tempo di attesa in secondi tra le richieste. Il tempo minimo di attesa tra le richieste è 1 secondo, mentre il tempo massimo è 999 secondi.

6. Fare clic su OK.

Per ulteriori informazioni sulle regole di impatto del crawler, vedere gli articoli seguenti:

• Gestire l'impatto del crawler (Office SharePoint Server 2007).

• Sezione relativa alle regole di impatto del crawler in Stimare i requisiti di capacità e prestazioni per gli ambienti di ricerca.

Acceleratori WAN e altri strumenti di terze parti

In questa sezione vengono descritte le opzioni per l'ottimizzazione di ambienti WAN con soluzioni di terze parti nelle categorie seguenti:

• Acceleratori WAN

• Dispositivi cache e di ripartizione del carico di lavoro

• Soluzioni client

• Replica dei dati, sincronizzazione multimaster e gestione della configurazione

• Gestibilità e report in presenza di più farm

• Replica a livello di byte o basata su hardware

Poiché ogni ambiente è diverso, non è possibile consigliare soluzioni partner specifiche. Le soluzioni partner, inoltre, gestiscono le opportunità in modi diversi. Di conseguenza, ogni soluzione ha i propri punti di forza, che differiscono da quelli di altre soluzioni. È importante valutare ciascuna soluzione in base alle esigenze specifiche dell'ambiente e ai punti di forza relativi della soluzione partner.

Molti partner offrono soluzioni per migliorare o ottimizzare le soluzioni Microsoft Office SharePoint Server 2007. Per un elenco aggiornato dei partner, vedere Directory delle soluzioni di Microsoft Office System (https://go.microsoft.com/fwlink/?linkid=108591&clcid=0x410).

Acceleratori WAN

Le soluzioni di accelerazione WAN sono disponibili da molto tempo. Algoritmi di percorso più brevi e strumenti di compressione dei pacchetti vengono offerti già da diverse decine di anni. Le innovazioni più importanti degli ultimi anni sono relative all'ottimizzazione dello stack TCP/IP e di Server Message Block (SMB).

La maggior parte degli acceleratori WAN opera in coppia, con un dispositivo installato nel data center accanto ai server che eseguono Prodotti e tecnologie SharePoint e un altro dispositivo nella succursale. I due dispositivi ottimizzano il traffico WAN utilizzando memorizzazione nella cache, compressione, differenze e metodi proprietari per ottimizzare i pacchetti inviati tra i due dispositivi. Sia che si tratti di dispositivi inline o di semplici apparecchiature di rete con aggiornamenti per la cache, l'approccio è simile. Soluzioni partner diverse sono incentrate sull'ottimizzazione di diversi livelli all'interno dello stack di rete.

Nello scegliere un acceleratore di rete, è importante valutare due criteri importanti:

• Requisiti di protezione dell'organizzazione. Requisiti come quelli relativi a IPSec o HTTPS influenzeranno la scelta.

• Applicazioni utilizzate nell'organizzazione. Se si desidera un dispositivo che offra ottimizzazione anche per Microsoft Exchange Server e il traffico delle condivisioni di file, anche questo aspetto influenzerà la scelta.

Tra alcuni esempi di soluzioni sono inclusi Cisco, Citrix, Packeteer, Riverbed e F5.

Dispositivi cache e di ripartizione del carico di lavoro

Mentre le tecniche di memorizzazione nella cache disponibili in SharePoint possono ridurre il traffico back-end non necessario, i partner che offrono ripartizione del carico di lavoro e dispositivi cache possono consentire di colmare la distanza, anche nelle connessioni WAN, tra il client e i server.

Se il sito di SharePoint viene ospitato in Internet e l'obiettivo consiste nell'ottimizzare il traffico di rete e ridurre la quantità di richieste ricevute dai server, la ripartizione del carico di lavoro e i dispositivi cache possono avere un ruolo importante. Un'ampia gamma di partner si è impegnata nel progettare soluzioni per l'ottimizzazione del processo di hosting di contenuto esposto a Internet. Le strategie impiegate in quest'area includono la memorizzazione nella cache e tecniche proprietarie correlate, compressione con ripartizione del carico di lavoro e svariati algoritmi, riscaldamento e recupero preliminare e diverse tecniche per carrelli acquisti. Alcuni partner sono specializzati nella trasmissione protetta ed efficiente di contenuto a tipi specifici di client, ad esempio chioschi multimediali pubblici, computer in Internet café di tutto il mondo o altri dispositivi dalle funzionalità ridotte con collegamenti poco funzionali.

Nel settore di Internet, inoltre, alcuni partner forniscono tecniche di memorizzazione nella cache e di routing di ottimizzazione di rete per ridurre i pacchetti rimossi. Alcune soluzioni, ad esempio, consentono di ottimizzare il traffico di rete in modo che vengano inviati al server solo i delta all'interno di richieste client. Questi tipi di soluzioni riducono il traffico WAN e possono accelerare la restituzione di pagine in cui il numero di comunicazioni round trip tra il client e il server o tra altri dispositivi intermedi è ridotto.

Analogamente a Microsoft ISA, alcune soluzioni offrono autenticazione delegata o con ripartizione del carico di lavoro come gateway per l'accesso alle informazioni. Tali soluzioni aggiungono un ulteriore livello di protezione. Per soddisfare più requisiti, scegliere prodotti o soluzioni che offrano un firewall, bilanciamento del carico, nonché caratteristiche avanzate per ripartizione del carico di lavoro e memorizzazione nella cache. In futuro è previsto un maggiore potenziamento di questi tipi di caratteristiche.

Tra alcuni esempi di soluzioni sono inclusi Cisco, F5, Inktomi, Microsoft ISA Server e Microsoft Internet Application Gateway.

Soluzioni client

Alcuni partner si dedicano maggiormente all'ottimizzazione dell'esperienza client anziché all'infrastruttura server e di rete. Tecniche quali il recupero preliminare, la sincronizzazione in background, la compressione, il blocco di annunci e i filtri di immagini possono incrementare notevolmente le prestazioni per il recupero di contenuto in Internet, in particolare se il testo, e non le immagini, rappresenta l'obiettivo principale.

Sono disponibili diverse applicazioni client che consentono agli utenti di eseguire la sincronizzazione automatica con siti di SharePoint. In seguito alla sincronizzazione iniziale del client con un sito, l'applicazione client memorizza automaticamente nella cache il contenuto del sito nel computer client in background o quando il client è in linea. Quando, ad esempio, un utente fa clic su un documento, il documento à già disponibile in locale e i collegamenti WAN non influiscono sull'esperienza dell'utente. Analogamente, quando un utente aggiunge o aggiorna un documento, l'applicazione client esegue la sincronizzazione delle modifiche con il sito in linea. Tali applicazioni client gestiscono in genere qualsiasi conflitto generato e consentono agli utenti di decidere il modo in cui risolverlo.

Alcuni client sono in grado di gestire questa esperienza meglio di altri. Alcuni offrono supporto solo per file, altre applicazioni offrono supporto sia per elenchi che per file. Non sarà in genere possibile trovare siti Wiki non in linea, ma saranno disponibili lettori RSS per utilizzare la maggior parte degli elenchi in locale o non in linea. Microsoft Office Outlook 2007 è un esempio di client che consente di utilizzare blog o elenchi di SharePoint utilizzando RSS con un lettore RSS, nonché di eseguire la sincronizzazione con raccolte documenti. Anche Microsoft Office Groove 2007 offre una valida esperienza non in linea e include caratteristiche di collaborazione e compressione di file in una rete WAN. Per ulteriori informazioni sulle soluzioni client Microsoft, vedere Estensione delle soluzioni globali di Office SharePoint Server con Office Outlook 2007 e Office Groove.

I partner che si occupano di questo settore hanno concentrato il proprio impegno nell'ottimizzazione dell'esperienza utente in cui i collegamenti WAN influiscono sulle prestazioni o i client sono spesso non in linea. La memorizzazione nella cache (copie locali), la compressione e lo spostamento della sincronizzazione in background creano l'impressione che il client si trovi in una stessa rete LAN con il server. Se si sceglie di offrire applicazioni client agli utenti, assicurarsi di garantire formazione adeguata, in modo che gli utenti siano in grado di operare con la massima efficienza.

Partner: Colligo. Microsoft: Microsoft Office Outlook 2007 e Microsoft Office Groove 2007

Replica dei dati, sincronizzazione multimaster e gestione della configurazione

Sia a causa di collegamenti WAN lenti tra due uffici, sia per motivi di ripristino di emergenza con l'esigenza di utilizzo della modalità multimaster, la replica è spesso necessaria nei piani di distribuzione. SQL Server 2005 offre caratteristiche di log shipping e mirroring del database per il ripristino di emergenza o il failover del sito. Nei casi in cui sono necessarie due server farm distinte che forniscano entrambe accesso in lettura/scrittura, tuttavia, vi sono partner in grado di offrire soluzioni a questo scopo.

Alcune soluzioni partner includono una cache del server simile a un acceleratore WAN. Tali soluzioni continuano a distribuire contenuto dalla cache in un sito remoto in caso di errore di un collegamento WAN. Altri partner sono specializzati nella sincronizzazione dei dati quando i siti vengono connessi dopo periodi prolungati di disconnessione. Una nave che arriva in porto dopo una lunga navigazione, ad esempio, potrà sincronizzarsi con un sito centrale.

Alcuni partner estendono l'interfaccia di Prodotti e tecnologie SharePoint per configurare la replica per coppie di applicazioni Web, raccolte siti o elenchi.

Nota

Le caratteristiche di pubblicazione di Microsoft Office SharePoint Server 2007 non sono state ancora testate in ambienti WAN dal team di prodotto. Tali caratteristiche possono rivelarsi utili per pubblicare contenuto da una farm centrale in ambienti di sola lettura. Senza i risultati dei test, tuttavia, Microsoft non può fornire linee guida specifiche per questo scenario.

Le soluzioni partner includono: Syntergy, tecnologie WinApp, Casahl e Infonic.

Gestibilità e report in presenza di più farm

Nelle distribuzioni globali che includono più server farm la gestione delle impostazioni tra le farm e i siti può costituire una sfida impegnativa. Numerosi partner offrono strumenti progettati per semplificare la gestione delle impostazioni di configurazione e delle autorizzazioni e per consentire diritti utente efficaci ed elementi di contenuto come pagine master e tipi di contenuto. Se si sceglie di distribuire più server farm nell'ambiente, prendere in considerazione strumenti che semplifichino la gestione di più farm e di volumi elevati di siti.

Alcuni partner sono particolarmente impegnati nel semplificare la configurazione delle impostazioni tra farm e più ambienti. Lo strumento di configurazione intersito di SharePoint (informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=108592&clcid=0x410) (informazioni in lingua inglese) è un esempio di strumento progettato da Microsoft per configurare il controllo, la scadenza, le pagine master e i tipi di contenuto per la coerenza tra applicazioni Web.

Le soluzioni partner includono: Quest Software, echoTechnologies, IDevFactory, AvePoint, CorasWorks, Barracuda Tools, CommVault e Symantec.

Replica a livello di byte o basata su hardware

I partner che offrono soluzioni di replica basata su hardware o a livello di byte semplificano notevolmente il failover e la sincronizzazione di ambienti tra data center. Se si implementa un disco condiviso, ad esempio una rete di archiviazione, il disco condiviso può costituire un punto di errore. I fornitori di soluzioni hardware utilizzano diversi metodi per offrire canali, fiber e dischi ridondanti, nonché svariate configurazioni di array. Soluzioni diverse forniscono livelli diversi di tolleranza di errore.

Se si desidera eliminare l'hardware come possibile origine di errore, prendere in considerazione Microsoft Cluster Services (MSCS), che offre tolleranza di errore basata su hardware. Le soluzioni di failover basate su software come log shipping SQL e mirroring SQL offrono tolleranza di errore hardware, ma il failover non è automatico se utilizzato con Prodotti e tecnologie SharePoint.

In alcuni casi l'implementazione di una soluzione che offre replica a un livello inferiore nello stack può essere utile per soddisfare esigenze aziendali specifiche. La replica a livello di byte, che crea un clone o un mirror dell'ambiente primario, può creare anche un ambiente secondario in cui eseguire il failover. La replica a livello di byte continua può offrire un metodo per il failover automatico o manuale.

Una precauzione importante nel valutare questi tipi di soluzioni di replica consiste nel comprendere come i nomi dei server, i nomi delle applicazioni Web e gli account siano specificati a livello di codice nel database di configurazione. Di conseguenza, qualsiasi servizio replicato in un server diverso con un altro nome non funzionerà. Se il nome del server resta lo stesso nell'ambiente replicato come ambiente primario, questi tipi di soluzioni possono rivelarsi utili. Indipendentemente dalla soluzione, se uno strumento offre caratteristiche di replica escluse dall'ambito noto dell'applicazione, deve essere testato per garantirne il funzionamento in un ambiente di failover.

Le soluzioni partner includono: Neverfail e Double-take.

Le soluzioni integrate nell'hardware, ad esempio le soluzioni di replica basata su rete di archiviazione, includono: HP, EMC Centera e Hitachi Data Systems.

Progettazione di pagine per download più rapidi

In un ambiente con capacità di rete limitata è consigliabile semplificare le pagine, ridurne al minimo le dimensioni e accelerarne i tempi di risposta quanto più possibile. A tale scopo, sono disponibili diverse tecniche, la maggior parte delle quali non sono specifiche di Prodotti e tecnologie SharePoint. I metodi generali possono essere utilizzati in qualsiasi sito Web e non vengono trattati in dettaglio in questa sezione. La sezione, invece, è incentrata sulla comprensione delle caratteristiche disponibili in Prodotti e tecnologie SharePoint, degli elementi inclusi nella pagina e dei modi in cui è possibile rendere più rapida la visita iniziale a un sito di SharePoint.

Elementi della pagina

Una pagina di un sito di SharePoint è costituita da diversi elementi unici, come illustrato nella figura seguente.

Quando si esegue il rendering della pagina, vengono riunite la pagina master, la pagina di layout e il contenuto della pagina. Il contenuto della pagina include i valori per ognuno dei campi pagina, ma anche diversi altri elementi, ad esempio il tema, i fogli di stile, le immagini e lo spostamento. Nella tabella seguente viene illustrato un esempio dei file e dei flussi presenti in una singola pagina di un sito di SharePoint. L'esempio rappresenta l'acquisizione di tutte le richieste HTTP eseguite durante una visita iniziale all'home page predefinita di un sito portale di collaborazione.

URL	Dimensioni (byte)
https://server/_layouts/images/topnavhover.gif	96
https://server/Pagine/Default.aspx	1656
https://server/Pagine/Default.aspx	1539
https://server/Pagine/Default.aspx	66084
https://server/_layouts/1040/styles/controls.css?rev=EhwiQKSLiI%2F4dGDs6DyUdQ%3D%3D	1448
https://server/_layouts/1040/styles/HtmlEditorCustomStyles.css?rev=8SKxtNx33FmoDhbbfB27UA%3D%3D	642
https://server/_layouts/1040/styles/HtmlEditorTableFormats.css?rev=guYGdUBUxQit03E2jhSdvA%3D%3D	1317
https://server/_layouts/1040/styles/core.css?rev=5msmprmeONfN6lJ3wtbAlA%3D%3D	13596
https://server/_layouts/1040/init.js?rev=VhAxGc3rkK79RM90tibDzw%3D%3D	15732
https://server/_layouts/1040/core.js?rev=F8pbQQxa4zefcW%2BW9E5g8w%3D%3D	54367
https://server/_layouts/portal.js?rev=INhSs9mWTnUTqdwwIXYMaQ%3D%3D	954
https://server/_layouts/1040/ie55up.js?rev=Ni7%2Fj2ZV%2FzCvd09XYSSWvA%3D%3D	20508
https://server/_layouts/1040/search.js?rev=yqBjpvg%2Foi3KG5XVf%2FStmA%3D%3D	5092
https://server/_layouts/1040/EditingMenu.js?rev=eh0f0CwzvHQ7Ii0JvdsIjQ%3D%3D	2735
https://server/WebResource.axd?d=__WrA1TRLicJgwGEmYKqSA2&t=633214754549731034	5383
https://server/WebResource.axd?d=h_u9v0Coj_eDqsvEkDrdtw2&t=633214754549731034	8258
https://server/_layouts/images/blank.gif	43
https://server/_layouts/images/helpicon.gif	1025
https://server/_layouts/images/Menu1.gif	68
https://server/_layouts/images/titlegraphic.gif	1299
https://server/_layouts/images/gosearch.gif	19933
https://server/WebResource.axd?d=puevA5kEAx44yxozBd-hspPZ9eA51Rh9u95VwVGLFCc1&t=633214754549731034	224
https://server/WebResource.axd?d=wyTuS1folQ6wX2Tc_7NOOaeElHHqL6rtdeAeRRUR36s1&t=633214754549731034	218
https://server/_layouts/images/whitearrow.gif	68
https://server/_layouts/images/recycbin.gif	1004
https://server/PublishingImages/newsarticleimage.jpg	10710
https://server/_layouts/images/icongo01.gif	1171
https://server/_layouts/images/menudark.gif	68
https://server/_layouts/images/topnavhover.gif	96

Si noti quanto segue:

• È stato necessario un totale di 29 richieste per scaricare la pagina.

• Le dimensioni totali della pagina sono pari a 235 kilobyte (KB).

• Questi elementi sono relativi al caricamento iniziale della pagina. Quasi tutti gli elementi nella richiesta sono associati a una direttiva relativa alla memorizzazione nella cache che indica al browser di non caricarli più per un anno. Il secondo caricamento della pagina e quelli successivi produrranno solo tre richieste. Poiché due di queste richieste fanno parte della negoziazione NTLM eseguita, viene effettivamente scaricato solo un elemento, ovvero il codice HTML per la pagina.

• È stato utilizzato il livello di compressione di IIS predefinito 0, che corrisponde alla quantità minima di compressione possibile. Ulteriore compressione produrrebbe dimensioni di download ancora inferiori.

• Tra i diversi tipi di file caricati sono inclusi i seguenti:

  • 4 richieste di risorse con estensione axd

  • 4 richieste di risorse con estensione css

  • 12 richieste di risorse immagine

  • 6 richieste di risorse con estensione js (molte delle quali duplicate)

  • 3 richieste di risorse pagina per default.aspx (due delle quali fanno parte della negoziazione NTLM)

La maggior parte di questi tipi di file è piuttosto ovvia, con la possibile eccezione del tipo di risorsa con estensione axd. Una risorsa con estensione axd fa parte di una nuova caratteristica disponibile in ASP.NET versione 2.0. Uno sviluppatore può aggiungere una risorsa, ad esempio un file di script o un foglio di stile, a un controllo. Nel controllo lo sviluppatore utilizza la classe ClientScript per includere un metodo denominato GetWebResourceUrl. Quando viene eseguito il rendering del controllo in fase di esecuzione, questo genera dinamicamente un URL per la risorsa. Poiché la risorsa stessa viene compilata nell'assembly dei controlli, questa metodologia consente di trasmettere la risorsa al di fuori dell'assembly e fino al client come se si trattasse di un file distinto memorizzato nel server Web.

Identificando le richieste di risorse utilizzate dalla pagina, è possibile comprendere con maggiore facilità i casi in cui è possibile applicare le operazioni di ottimizzazione e le relative modalità. È possibile valutare questo tipo di informazioni utilizzando un'ampia gamma di tecniche e strumenti diversi. Ai fini di questo articolo, è stato utilizzato uno strumento freeware denominato Fiddler (informazioni in lingua inglese). Fiddler può essere eseguito in una workstation client e tiene traccia di tutte le richieste HTTP di una pagina inviate. I risultati vengono quindi visualizzati in una griglia, come illustrato nella figura seguente.

Quando si modifica il sito per ottimizzarlo, è possibile testarlo con Fiddler. Per ottenere un'idea il più precisa possibile degli elementi richiesti, degli elementi memorizzati nella cache e delle dimensioni di ciascun elemento, eseguire le operazioni seguenti:

1. Eliminare tutti i file temporanei del browser.

2. Avviare Fiddler.

3. Richiedere la pagina.

   Nota

   Verificare di avere richiesto la pagina facendo clic su un collegamento. Se si fa clic solo sul pulsante Aggiorna, il sistema richiederà di nuovo l'elemento automaticamente e non rifletterà con precisione le modifiche di ottimizzazione apportate.

Ottimizzazione dei download delle pagine

Dopo avere compreso la composizione della pagina, è possibile utilizzare metodi diversi per ottimizzare l'esperienza di download per la pagina. L'obiettivo consiste in genere nel ridurre al minimo il numero di round trip tra i computer client e i server e nel ridurre la quantità di dati trasmessi in rete. Le linee guida disponibili in questo articolo includono alcune indicazioni che è possibile applicare in modo esteso a molte implementazioni diverse di Prodotti e tecnologie SharePoint.

Nell'esaminare tali indicazioni e qualsiasi altra ottimizzazione personalizzata sviluppata personalmente, vi è un'importante distinzione da ricordare. Le tecniche di ottimizzazione delle pagine sono suddivise in due categorie: richiesta di pagine iniziale e richiesta di pagine successiva. Le ottimizzazioni per la richiesta di pagine iniziale sono quelle implementate quando la pagina viene richiesta per la prima volta, ma che non influiscono necessariamente sulle richieste di pagine successive. Le ottimizzazioni delle richieste di pagine successive sono quelle che migliorano l'esperienza utente per la prima o l'ennesima volta che un utente richiede la pagina, L'aspetto principale è costituito dal fatto che è necessario garantire l'equilibrio tra la perdita di funzionalità e i vantaggi ottenuti. Se il vantaggio viene ottenuto solo la prima volta che un utente visita un sito, l'ottimizzazione potrebbe essere insufficiente rispetto alla perdita di funzionalità.

Cache BLOB

La cache BLOB viene trattata in modo più approfondito più avanti in questo articolo. In breve, può essere utilizzata per applicare direttive della cache a elementi in una pagina archiviati in Prodotti e tecnologie SharePoint. Se tali direttive della cache vengono incluse, il browser non tenta di scaricare nuovamente gli elementi fino alla scadenza dell'elemento memorizzato nella cache. Come illustrato nell'esempio di home page precedente, a quasi tutti gli elementi inclusi nella home page predefinita per il modello di sito Portale di collaborazione è associata una direttiva della cache, motivo per cui tali elementi non vengono richiesti nelle visite successive alla pagina. Per maggiori dettagli sull'impostazione e la configurazione della cache BLOB, vedere Ottimizzazione della memorizzazione nella cache per ambienti WAN più avanti in questo articolo.

Compressione di IIS

La compressione di IIS viene trattata in modo più approfondito nella sezione Ottimizzazione della memorizzazione nella cache per ambienti WAN di questo articolo. Come notato in precedenza, tuttavia, l'impostazione predefinita consiste nell'utilizzare il livello di compressione 0. È consigliabile provare i diversi livelli di impostazione della compressione fino a trovare quello che consente di ottimizzare la compressione riducendo al minimo l'impatto sulle CPU per i server Web. Virtualmente in tutti i casi, è possibile utilizzare un livello di compressione maggiore di 0. È tuttavia importante ricordare che il livello di compressione si applica solo ai file dinamici, ad esempio ai file con estensione axd e aspx.

Hardware a 64 bit

Le scelte relative all'hardware nella farm possono influire anche sulla latenza delle richieste. Ai sistemi a 32 bit è applicato un limite di memoria di 2 gigabyte (GB) di RAM per applicazione. Benché sia possibile estendere il supporto delle applicazioni a 3 GB di RAM, Prodotti e tecnologie SharePoint non supporta l'utilizzo del parametro /3GB. Le situazioni di memoria insufficiente possono influire negativamente sulla latenza delle richieste nei modi seguenti:

• Se la quantità di memoria diventa vincolata, può provocare il riciclo del pool di applicazioni di SharePoint, forzando anche il riciclo del dominio applicazione ASP.NET, che, a sua volta, può causare un ritardo prolungato nella risposta alle richieste degli utenti.

• Gli errori di memoria insufficiente possono provocare l'interruzione della gestione del contenuto da parte della cache BLOB.

Utilizzando hardware a 64 bit, è possibile garantire l'allocazione e l'utilizzo di RAM sufficiente per impedire tali errori.

Impostazioni dei Web garden

Anche le impostazioni relative ai Web garden possono provocare un funzionamento non coerente della cache BLOB. Poiché solo un processo può acquisire il blocco necessario per gestire la cache, un utilizzo corretto della cache dipende dal thread che gestisce una richiesta. Se un Web garden che non include il blocco della cache BLOB gestisce una richiesta, al contenuto che invia in risposta non saranno associate direttive di memorizzazione nella cache. Di conseguenza, aumentano il numero di richieste e la quantità di dati inviati in rete. Se, pertanto, si desidera utilizzare la cache BLOB, è consigliabile non utilizzare i Web garden.

Ridurre al minimo gli elementi protetti nella pagina

Quando un utente esegue l'autenticazione a Prodotti e tecnologie SharePoint, si verificano due situazioni. Il sistema convalida innanzitutto le credenziali per determinare l'identità dell'utente. Il provider di ruoli enumera quindi l'elenco di gruppi di SharePoint cui appartiene l'utente. Ogni volta che viene richiesta una pagina, il provider di ruoli viene chiamato di nuovo per enumerare tutti i gruppi cui appartiene l'utente.

Questa chiamata per l'appartenenza ai gruppi, tuttavia, può essere eseguita più volte in una singola pagina. Per la pagina del modello di sito Portale di collaborazione predefinito, ad esempio, sono necessarie due chiamate al provider di ruoli quando si accede alla home page, una per la pagina stessa e una per l'immagine nella pagina. Ogni immagine archiviata in una raccolta SharePoint e inclusa nella pagina forzerà una chiamata aggiuntiva al provider di ruoli per la verifica delle autorizzazioni, anche se tutte le immagini sono archiviate nella stessa raccolta immagini. Questa verifica viene eseguita sia se le immagini vengono aggiunte come campi nella pagina, ovvero come parte del contenuto della pagina, sia se vengono aggiunte alla pagina master per il sito.

Un sito sviluppato per un ambiente con larghezza di banda limitata o latenza elevata deve essere progettato in modo da ridurre al minimo il numero di immagini utilizzate nella pagina. Molti siti utilizzano diverse immagini come parte della pagina master per creare effetti visivi diversi. Poiché la latenza aumenta con l'aumentare del numero di controlli di protezione, nel progettare siti per tali ambienti, utilizzare il minor numero di immagini possibile.

Riduzione del numero e delle dimensioni delle immagini

Come descritto nella sezione precedente, è consigliabile ridurre al minimo il numero di immagini nel sito. Per semplificare questa operazione, è possibile incorporare più immagini in un singolo file e quindi fare riferimento a singole immagini nella pagina. In questo modo, non solo le dimensioni di download dei file diminuiranno, ma un numero inferiore di file produrrà anche un minor traffico di rete. La creazione di pagine tramite questa tecnica è più complessa, ma nei casi in cui il numero di round trip e le dimensioni dei file rappresentano un fattore importante può rivelarsi una soluzione utile per migliorare le prestazioni. Nella figura seguente viene illustrato un esempio di singola immagine contenente più immagini.

Nella figura seguente viene illustrato il modo in cui l'immagine viene quindi modificata per essere visualizzata come più singole immagini in una tabella.

La modifica delle immagini è stata eseguita interamente tramite classi foglio di stile. Sono state utilizzate due classi primarie negli elementi div e img in ogni cella di tabella. Tali classi sono le seguenti:

.cluster {

   height:50px;

   position:relative;

   width:50px;

}

.cluster img {

   position:absolute;

}

Ogni immagine è associata a una classe in base all'identificatore (ID) per l'immagine. Lo stile ritaglia l'immagine e definisce uno scostamento dall'immagine iniziale nel cluster. Tali classi vengono indicate di seguito:

#person {

   border:none;

   clip:rect(0, 49, 49, 0);

}

#keys {

   clip:rect(0, 99, 49, 50);

   left:-50px;

}

#people {

   clip: rect(0, 149, 49, 100);

   left:-100px;

}

#lock {

   clip:rect(0, 199, 49, 150);

   left:-150px;

}

#phone {

   clip:rect(0,249, 49, 200);

   left:-200px;

}

#question {

   clip:rect(0, 299, 49, 250);

   left:-250px;

}

Il codice HTML per la tabella include i tag div e img con i valori di ID e i nomi di classe appropriati, come illustrato di seguito:

<table border="1">

   <tr>

      <td><div class="cluster"><img id="person" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="keys" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="people" src="Icons50x50.gif" width="300" height="50"/></div></td>

   </tr>

   <tr>

      <td><div class="cluster"><img id="lock" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="phone" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="question" src="Icons50x50.gif" width="300" height="50"/></div></td>

   </tr>

</table>

Più proprietà e prodotti Web Microsoft utilizzano questa tecnica, inclusi Microsoft Passport Network e Microsoft Office Outlook Web Access (OWA). Il team MSN ha condotto alcuni test sulle prestazioni per analizzare l'impatto delle modifiche e ha rilevato un miglioramento compreso tra il 50% e il 75% nei tempi di caricamento per la prima pagina.

Se le pagine vengono create in Microsoft Office SharePoint Designer 2007, vi è un importante aspetto da tenere presente. Quando si crea una nuova pagina in Microsoft Office SharePoint Designer 2007, alla pagina viene automaticamente aggiunto il codice di schema XHTML seguente:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

It then adds this namespace to the HTML element:

<html xmlns="http://www.w3.org/1999/xhtml">

Se si utilizza questo schema, le immagini non saranno allineate correttamente. Affinché le immagini vengano visualizzate nel modo desiderato, è necessario rimuovere l'attributo xmlns dal tag HTML.

Posticipare il download di core.js

Il file di script client principale incluso in Microsoft Office SharePoint Server 2007 è denominato core.js. Si tratta del file di script con le dimensioni maggiori, ovvero circa 257 KB senza compressione e circa 54 KB con compressione. In alcuni casi, è possibile posticipare il download di core.js. In tali casi, il rendering della pagina viene eseguito più rapidamente, in quanto il download del file core.js non viene avviato fino all'apertura della pagina nel browser. In questo modo, l'utente può visualizzare la pagina e iniziare a leggerne il contenuto più velocemente. Questa tecnica è particolarmente utile in uno scenario Internet con utenti anonimi. Al contrario, è necessario che per gli utenti autenticati il file core.js venga scaricato in fase di caricamento della pagina per utilizzare funzionalità o elementi dell'interfaccia utente come il menu Azioni sito.

Per implementare questa tecnica, è possibile eseguire la procedura seguente.

1. Creare una pagina di layout personalizzata che non utilizzi il file core.js. Questa pagina di layout verrà utilizzata con la home page in modo che i visitatori iniziali del sito non dovranno attendere il download immediato di core.js. Poiché deve essere compatibile con la home page esistente, la nuova pagina di layout deve essere associata allo stesso tipo di contenuto della pagina di layout attualmente in uso.

   Nota

   Per impostazione predefinita, in un sito Portale di collaborazione è specificato il tipo di contenuto Pagina di benvenuto.

2. Aggiungere il tag seguente alla pagina: <SharePointWebControls:ScriptLink runat="server"/>, che indica al sistema di non utilizzare il file core.js a meno che non vi si faccia riferimento.

3. Creare un controllo personalizzato per verificare la presenza di utenti autenticati. Il controllo sarà estremamente semplice e contiene essenzialmente il codice seguente (visualizzato in C#):

   if (HttpContext.Current.Request.IsAuthenticated)   
       Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);
   

4. In ogni server Web inserire il controllo nella cache di assembly globale (GAC) e quindi aggiungere una voce SafeControl per il controllo nel file Web.config per l'applicazione Web in cui verrà utilizzato.

5. Aggiungere il controllo personalizzato alla pagina di layout personalizzata creata nel passaggio 1.

6. Aggiungere un IFRAME alla pagina di layout, facendo riferimento a una pagina che include il contenuto seguente:

   <body>
   <SharePoint:ScriptLink name="core.js" runat="server" />
   <script language="javascript">
    DisableRefreshOnFocus();
   </script>
   </body>
   

7. Archiviare la pagina di layout personalizzata e pubblicarla.

8. Basare la home page del sito sulla nuova pagina di layout.

Dopo avere eseguito i passaggi precedenti, testare la home page del sito per verificarne il funzionamento. Un utente anonimo che accede per la prima volta non potrà visualizzare alcun riferimento al file core.js nell'origine della pagina, che dovrà essere incluso nella cache del browser.

Prima di utilizzare questa tecnica, inoltre, tenere presenti le considerazioni seguenti:

• La pagina master del sito e la pagina master di sistema devono essere diverse. In caso contrario, tutte le pagine in _layouts non funzioneranno correttamente.

• Verificare che la pagina master non contenga alcun controllo per il cui funzionamento sia necessario il file core.js in fase di caricamento.

• Verificare che la pagina master non includa alcun controllo ScriptLink che carica o fa riferimento a core.js.

Per maggiori dettagli e per ottenere il codice di esempio, vedere Blog del team di Gestione contenuto aziendale Microsoft (informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=106008&clcid=0x410) (informazioni in lingua inglese) .

Ottimizzazione delle pagine elenco

Il team dei servizi Microsoft ha operato con impegno per quantificare e migliorare le prestazioni dei tempi di rendering delle pagine elenco. Una pagina elenco è la pagina AllItems.aspx utilizzata da ogni elenco e raccolta per consentire l'esplorazione del contenuto. I tempi di rendering di tale pagina possono variare notevolmente in base al numero di colonne visibili nella visualizzazione e al relativo formato. Le opzioni di visualizzazione e l'abilitazione delle icone presenza, ad esempio, possono influire significativamente sui tempi di rendering. Il rendering del raggruppamento di elementi compressi richiede più tempo di quello del raggruppamento di elementi espansi ed entrambi risultano più lenti del caso in cui non viene applicato alcun raggruppamento.

Queste sfumature costituiscono il motivo per cui è importante considerare con attenzione la modalità di creazione delle visualizzazioni nelle pagine elenco, in particolare in collegamenti di rete non troppo veloci. Quando si utilizzano elenchi che contengono una quantità elevata di dati, è importante progettare con attenzione tutte le visualizzazioni, in particolare quella predefinita. In generale, è possibile accelerare i tempi di rendering delle pagine elenco tramite i metodi seguenti:

• Visualizzando un numero minore di colonne.

• Escludendo qualsiasi colonna che contiene informazioni sulla presenza.

• Utilizzando un collegamento (ma nessun menu di modifica) per visualizzare i dettagli degli elementi.

Nella tabella seguente vengono descritte le personalizzazioni che consentono di ridurre il tempo necessario per il rendering di una visualizzazione.

Elemento	Descrizione
Tipo di visualizzazione	Creare una visualizzazione come visualizzazione Foglio dati anziché come visualizzazione standard.
Visualizzazione: Limite elementi	È probabile che qualsiasi quantità maggiore di 1.000 rallenti il rendering. In una connessione lenta è importante provare diverse soluzioni per individuare il corretto equilibrio tra la quantità di dati visualizzati contemporaneamente e il numero di round trip necessari per visualizzare tutti i dati. Maggiore è il numero di righe visualizzate contemporaneamente, minore sarà il numero di round trip, ma maggiori saranno le dimensioni delle pagine.
Visualizzazione: Filtro	Utilizzare [Oggi] e [Utente] per filtrare gli elementi in base ad aggiornamento o assegnazione. Utilizzare i campi Stato per visualizzare solo gli elementi attivi in visualizzazioni predefinite.
Visualizzazione: Colonne	Utilizzare il minor numero di colonne necessarie. Creare una visualizzazione predefinita con un numero ridotto di colonne che consenta un'esplorazione di livello elevato in seguito alla quale gli utenti possano visualizzare i dettagli.

Nella tabella seguente vengono descritte le personalizzazioni che provocano un aumento del tempo necessario per il rendering di una visualizzazione. Ogni colonna aggiuntiva comporta un aumento dei tempi di rendering di una quantità minima, fino a mezzo secondo per colonna in una connessione di rete veloce per un elenco di 1.000 voci. Come indicato nella tabella, alcune colonne richiedono tempi maggiori.

Elemento	Descrizione
Raggruppa per	Il raggruppamento aggiunge codice HTML e JScript, rallentando il rendering per elenchi di grandi dimensioni. La configurazione di tutti i gruppi come compressi per impostazione predefinita comporta un ulteriore aumento effettivo dei tempi di rendering, a causa di operazioni aggiuntive nel modello a oggetti del browser.
Colonna - Titolo collegato all'elemento con menu Modifica	L'opzione "(collegato all'elemento con menu Modifica)" è quella che richiede più tempo. L'opzione analoga "(collegato all'elemento)" non provoca un aumento significativo dei tempi di rendering.
Colonna - Ricerca utente con presenza	L'aggiunta di un campo di ricerca utente con presenza comporta l'aggiunta di codice HTML per ogni collegamento da aprire nel menu Presenza e l'utilizzo di larghezza di banda per determinare la disponibilità di presenza.

Nella tabella seguente vengono descritte le personalizzazioni che comportano un impatto relativamente ridotto sui tempi di rendering di una visualizzazione.

Elemento	Descrizione
Ordinamento, Totali	L'applicazione di più ordinamenti e totali comporta un notevole aumento dei tempi di rendering, ma ognuno di tali elementi richiede in genere meno di un secondo per un elenco di 1.000 voci.

Ottimizzazione della memorizzazione nella cache per ambienti WAN

In Microsoft Office SharePoint Server 2007 sono disponibili numerose opzioni di memorizzazione nella cache diverse. Alcune sono destinate a migliorare la velocità effettiva nella pipeline di rendering, dalla ricezione di una richiesta nel server fino alla trasmissione di una risposta al computer client. Benché si tratti di un aspetto importante delle prestazioni complessive del sito, questa sezione è incentrata invece sulla memorizzazione della cache in relazione agli aspetti seguenti:

• Ruolo della configurazione del server per la memorizzazione nella cache.

• Controllo della dimensione degli elementi trasmessi in rete dal server al client.

Cache BLOB

La cache BLOB è un meccanismo disponibile solo con le caratteristiche di pubblicazione di Microsoft Office SharePoint Server 2007 e costituisce pertanto un candidato ideale per siti portale aziendali basati sul modello di sito Portale di collaborazione e per siti esposti a Internet basati sul modello di sito Portale di pubblicazione. La cache BLOB consente di configurare le direttive di memorizzazione nella cache associate agli elementi gestiti da elenchi di siti di pubblicazione, ad esempio Raccolta pagine e Immagini raccolta siti. Quando il browser nel computer client individua una direttiva di memorizzazione nella cache, rileva che l'elemento recuperato può essere salvato in locale e non deve essere richiesto di nuovo fino alla scadenza della direttiva. In un ambiente geograficamente distribuito si tratta di un elemento critico, in quanto riduce il numero di elementi richiesti e inviati in rete.

Quando la cache BLOB in Microsoft Office SharePoint Server 2007 viene attivata, si verificano due conseguenze. Innanzitutto, ogni volta che viene richiesto un elemento memorizzabile nella cache, Microsoft Office SharePoint Server 2007 esegue una ricerca nel disco rigido del server Web che ha ricevuto la richiesta per individuare un'eventuale copia disponibile in locale. In tal caso, il file viene trasmesso direttamente dal disco locale all'utente. Se l'elemento non è ancora disponibile nel disco locale, ne viene eseguita una copia dal database di SQL Server in cui è archiviato e quindi l'elemento viene inviato all'utente che ha effettuato la richiesta. Da questo punto in avanti, tutte le richieste dell'elemento possono essere gestite direttamente dal server Web fino a quando il valore relativo alla possibilità di memorizzare l'elemento nella cache non ne indica la scadenza. Questo comportamento consente prestazioni migliori nella server farm grazie alla riduzione del contenuto presente nel server database.

La seconda conseguenza consiste nell'aggiunta di un'intestazione relativa alla memorizzazione nella cache all'elemento quando questo viene inviato al client. Questa intestazione indica al browser il tempo per cui l'elemento verrà memorizzato nella cache. Se, ad esempio, a un'immagine è associato un valore di tre giorni, il browser utilizza la copia dell'immagine presente nella cache locale se l'immagine viene nuovamente richiesta entro tre giorni anziché richiederla nuovamente dal server.

Per testare il sito in modo da individuare gli elementi memorizzati nella cache e la relativa modalità di memorizzazione nella cache, è possibile utilizzare Fiddler (informazioni in lingua inglese) (http://www.fiddlertool.com) (informazioni in lingua inglese) . La cattura di schermata seguente contiene una schermata di Fiddler in un sito di SharePoint semplice utilizzato per la pubblicazione. Il sito è stato creato utilizzando il modello di sito Portale di collaborazione predefinito. Alla pagina è stato aggiunto ulteriore contenuto di testo e diverse immagini sono state aggiunte alla pagina master.

Nell'applicazione Fiddler sono incluse numerose informazioni importanti.

• La colonna # a sinistra indica che è stato inviato un totale di 44 richieste HTTP dal browser al server per il rendering della pagina.

• La colonna Result indica il codice HTTP restituito dalla richiesta per l'elemento. Il valore 200 indica che l'elemento è stato recuperato correttamente.

• La colonna URL indica l'elemento specifico richiesto.

• La colonna Body indica la dimensione di ogni elemento.

• La colonna Caching indica la direttiva di memorizzazione nella cache associata a ogni elemento. I dati nella colonna Caching indicano che a diversi elementi è associata una direttiva di memorizzazione nella cache, ovvero gli elementi includono un attributo max-age maggiore di 0. Le direttive di memorizzazione nella cache sono espresse in secondi. Di conseguenza, per la pagina illustrata diversi elementi sono configurati per essere memorizzati nella cache per 365 giorni (60 secondi in un minuto, 60 minuti in un'ora, 24 ore in un giorno = 60x60x24 = 86.400x365 = 31.536.000).

Si noti che gli elementi associati a una direttiva della cache si trovano tutti nella directory _layouts. Il motivo per cui gli elementi sono associati a questa impostazione della cache è dovuto alla modalità di configurazione in IIS della directory virtuale _layouts/images. Quando si crea una nuova applicazione Web, in Microsoft Office SharePoint Server 2007 vengono automaticamente create diverse directory virtuali mappate a cartelle nei dischi fisici del server Web. Quando viene creata la directory virtuale _layouts/images, viene aggiunta una direttiva di memorizzazione nella cache applicata all'intera directory. La cattura di schermata seguente indica la configurazione della directory nello snap-in Gestione IIS.

Poiché agli elementi è associata una direttiva di memorizzazione nella cache diversa da zero, alla successiva richiesta della pagina il browser utilizzerà la copia dell'elemento dalla cache del browser locale anziché richiederla nuovamente dal server. Nella cattura di schermata seguente viene illustrato uno snapshot di Fiddler quando la pagina viene richiesta una seconda volta.

Come indicato dai dati di Fiddler, il numero di elementi richiesti è diminuito significativamente, da 44 a 11. Un importante elemento da notare è che il numero di richieste inviate può variare a seconda della modalità utilizzata per richiedere la pagina. Se si utilizza il pulsante Aggiorna nel browser, è probabile che tutti gli elementi vengano richiesti di nuovo, sia che una versione locale memorizzata nella cache sia o meno disponibile. Al contrario, se la pagina viene richiesta accedendovi tramite un collegamento, verranno richiesti solo gli elementi non memorizzati nella cache.

Un altro elemento importante indicato dai dati di Fiddler è che il browser invia al server una richiesta di altre immagini nella pagina master che sono già disponibili nella cache locale, come indicato dal codice di risposta 304. Ciò significa che il browser ha inviato una richiesta condizionale di un elemento. La risposta 304 indica che la versione nel server non è stata modificata rispetto alla versione presente nel client e che pertanto non deve essere scaricata di nuovo. Anche se il file non viene scaricato in rete, ha comunque generato un round trip al server per determinare che la copia locale è aggiornata. Poiché in un ambiente geograficamente distribuito i round trip del server sono costosi, l'obiettivo principale consiste nel ridurli quanto più possibile. Se una direttiva di memorizzazione nella cache viene aggiunta a ognuno degli elementi rimanenti, diversi dalla pagina, che viene sempre restituita dal server, è possibile realizzare questo obiettivo. La cache BLOB è la caratteristica responsabile dell'aggiunta di questa direttiva di memorizzazione nella cache.

Per configurare la cache BLOB, utilizzare il file Web.config per l'applicazione Web in cui verrà utilizzata la cache. Aprire il file Web.config in un editor di testo, ad esempio il Blocco note, e individuare la voce BlobCache. Per impostazione predefinita, la voce sarà come la seguente:

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js)$ " maxSize="10" enabled="false"/>

Gli attributi utilizzati nell'elemento BlobCache hanno i significati seguenti:

• location **   **Percorso nel disco rigido del server Web in cui verranno archiviati gli elementi memorizzati nella cache.

• path   Espressione regex dei tipi di file da memorizzare nella cache.

• maxSize    Dimensione in GB utilizzabile dalla cache.

• enabled **   **Impostato su true per abilitare la cache BLOB.

L'attributo aggiuntivo seguente, non incluso per impostazione predefinita, è necessario per impostare un valore di scadenza per la memorizzazione nella cache di singoli elementi:

• max-age Periodo di tempo in secondi per cui gli elementi devono essere memorizzati nella cache del computer client.

Se l'attributo max-age viene impostato su un valore diverso da zero, gli elementi da memorizzare nella cache saranno associati a un valore di scadenza della cache, in modo che il browser non debba più scaricarli né verificarne la disponibilità della versione più recente. Si supponga, ad esempio, di voler abilitare la memorizzazione nella cache e allocare fino a 100 MB nel server Web per archiviare gli elementi, in modo che gli elementi scadano una volta al giorno e che, oltre ai tipi predefiniti, vengano memorizzati nella cache anche i file con estensione htc. Per soddisfare tali requisiti, specificare gli attributi BlobCache seguenti:

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js|htc)$ " maxSize="100" max-age="86400" enabled="true"/>

Si noti che questa modifica al file Web.config deve essere apportata in ogni server Web nella farm. Nella maggior parte dei casi, la cache BLOB sarà immediatamente operativa, ma è più sicuro utilizzare il comando iisreset per l'implementazione delle modifiche. Nella cattura di schermata seguente vengono illustrati i dati di Fiddler per la stessa richiesta di pagina illustrata in precedenza, ma con la cache BLOB abilitata in base a quanto descritto.

Si noti che tutti gli elementi inclusi nella raccolta /SiteCollectionImages sono associati al codice di stato HTTP 200, a indicarne il corretto download. Agli elementi è inoltre associata una direttiva di memorizzazione nella cache che specifica che non scadranno per un giorno (8.400 secondi). Se la pagina viene richiesta di nuovo, Fiddler indica che nessuna delle immagini viene nuovamente richiesta. Il numero totale di richieste di gestione della pagina è pertanto diminuito da 44 a 3 e due di queste richieste fanno parte della negoziazione dell'autenticazione NTLM eseguita tra il server Web e l'applicazione client. Nella figura seguente vengono illustrati i dati di Fiddler quando la pagina viene richiesta di nuovo.

Quando si utilizza la cache BLOB, tenere presenti le considerazioni seguenti:

• La cache BLOB richiede impegno aggiuntivo per la configurazione in quanto è necessario aggiornare il file Web.config in ogni server Web. I vantaggi ottenuti, tuttavia, giustificano ampiamente tale impegno.

• Analizzare il contenuto del sito e determinare se sono presenti altri tipi di file da gestire tramite la cache. Un esempio è costituito dai file con estensione htc. Poiché viene utilizzato nella maggior parte dei siti di pubblicazione, è consigliabile aggiungere questo tipo di file all'elenco dei tipi di file da memorizzare nella cache.

• È possibile utilizzare la cache BLOB solo per gli elementi archiviati in raccolte SharePoint e non per memorizzare contenuto proveniente da altre origini.

• Per impostazione predefinita, alcuni elenchi non possono essere utilizzati da utenti anonimi. Se vi sono utenti anonimi che accedono al sito, è necessario configurare manualmente le autorizzazioni per gli elenchi seguenti in modo da consentire la memorizzazione nella cache degli elementi in essi contenuti:

  • Raccolta pagine master

  • Raccolta stili

Vi sono altre due opzioni di configurazione da tenere presenti quando si utilizza la cache BLOB. La prima riguarda la cancellazione della cache BLOB. Se la cache deve essere cancellata per un sito specifico, accedere alla raccolta siti e fare clic su Azioni sito, su Impostazioni sito e quindi su Modifica tutte le impostazioni di sito. Nell'elenco di attività Amministrazione raccolta siti fare clic sul collegamento Cache oggetti raccolta siti. Nella sezione Reimpostazione cache basata su disco selezionare la casella Imponi reimpostazione cache basata su disco del server e quindi fare clic su OK.

Se si prevede di utilizzare Web garden in una farm di SharePoint, è inoltre necessario ricordare che questo metodo produrrà un funzionamento della cache BLOB apparentemente incoerente. Quando si configurano più Web garden in una server farm, può verificarsi un problema, in quanto solo uno di essi sarà in grado di acquisire il blocco necessario per gestire la cache BLOB. Di conseguenza, può sembrare che la cache BLOB funzioni in modo intermittente. Al contrario, l'utilizzo corretto della cache BLOB dipende dal thread che gestisce una richiesta.

Compressione di IIS

Diversamente dalle versioni precedenti di Prodotti e tecnologie SharePoint, la compressione di IIS viene attivata automaticamente durante l'installazione di Prodotti e tecnologie SharePoint. Dopo che un sito viene visitato da alcuni utenti, è possibile verificare il funzionamento della compressione visualizzando la directory %WINDIR%\IIS Temporary Compressed Files in un server Web. Tale directory dovrà contenere più file, a indicare che sono stati richiesti file statici e che IIS ne ha compresso una copia archiviandola nell'unità locale. Quando uno di tali file viene richiesto di nuovo, sia dallo stesso utente che da un altro, la versione compressa del file viene gestita direttamente da questa cartella. È possibile comprimere anche i file dinamici, ma questi vengono compressi sempre al momento e le copie non vengono mantenute nel server Web locale.

La compressione può comportare risparmi significativi in termini di larghezza di banda. Il file core.js, ad esempio, è incluso in ogni pagina di SharePoint. Se non è compresso è di 257 KB, mentre, in seguito alla compressione, è solo di 54 KB senza aggiungere altre operazioni di ottimizzazione alla compressione di IIS. Il file core.js deve essere memorizzato nella cache dopo che l'utente visita il sito per la prima volta. In questo esempio viene illustrato il contributo significativo della compressione in scenari con larghezza di banda ridotta.

Durante l'installazione di Prodotti e tecnologie SharePoint, il programma di installazione configura IIS per la compressione dei tipi di file statici con estensione htm, html e txt e dei tipi di file dinamici con estensione asp ed exe. Analizzando i tipi di file utilizzati in modo esteso nell'implementazione, può risultare utile comprimere altri tipi di file. Può essere utile, ad esempio, comprimere anche i tipi di file statici con estensione css e js, nonché i tipi di file dinamici con estensione axd e aspx.

Per aggiungere un tipo di file statico o dinamico all'elenco dei tipi da comprimere, utilizzare il file adsutil.vbs, disponibile, per impostazione predefinita, nella cartella %SystemDrive%\Inetpub\AdminScripts in ogni server Web. Negli esempi seguenti viene illustrata l'aggiunta dei file con estensione css e js nell'elenco dei tipi di file statici compressi in Microsoft Windows Server 2003:

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcFileExtensions "htm" "html" "txt" "css" "js"

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcFileExtensions "htm" "html" "txt" "css" "js"

Nell'esempio seguente viene illustrata l'aggiunta dei file con estensione aspx e axd nell'elenco dei tipi di file dinamici:

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "exe" "axd" "aspx"

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "exe" "axd" "aspx"

Quando si modificano i tipi di file da comprimere, assicurarsi di includere solo i file adatti per la compressione. I file con estensione jpg, ad esempio, non sono adatti per la compressione, in quanto tale formato di file è già intrinsecamente compresso. I tipi di file di Microsoft Office System 2007, ad esempio i file con estensione docx, xlsx e pptx, non rappresentano una scelta ideale per la compressione, in quanto non vengono gestiti direttamente dal server, ma vengono indirizzati tramite filtri ISAPI diversi utilizzati per gestire la ricca esperienza utente integrata per il contenuto di Microsoft Office. In Microsoft Office System 2007, inoltre, questi tipi di file sono già intrinsecamente compressi.

Oltre a determinare i tipi di file da comprimere, è possibile controllare il livello di compressione utilizzato per i tipi di file dinamici. La quantità di compressione utilizzata viene misurata su una scala da 0 a 10. Maggiore è il livello di compressione, minori saranno le dimensioni dei file. Lo svantaggio, tuttavia, è costituito dal fatto che livelli di compressione elevati comportano anche un maggiore utilizzo della CPU e che, pertanto, si produce un maggiore utilizzo della CPU creando file di dimensioni minori. Quando la compressione di IIS è abilitata, viene utilizzata per l'utilizzo del livello di compressione 0. In generale, il livello di compressione ideale con Prodotti e tecnologie SharePoint è il livello 9. Per modificare il livello di compressione, utilizzare il file di script adsutil.vbs descritto in precedenza in questo articolo. Nell'esempio seguente viene illustrata l'impostazione del livello di compressione 9.

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel "9"

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel "9"

  Nota

  Questa impostazione non modifica la compressione dei file statici.

Per ulteriori informazioni, vedere Utilizzo della compressione HTTP (IIS 6.0) (informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=108705&clcid=0x410) (informazioni in lingua inglese) .

Combinazione della cache BLOB con la compressione di IIS

L'abilitazione della cache BLOB consente di ridurre significativamente il numero di round trip del server e dei file inviati in rete quando gli utenti esplorano un sito di SharePoint. Utilizzando la compressione insieme alla cache BLOB, è possibile ridurre anche la quantità di traffico per i file inviati ai client. La combinazione di queste due caratteristiche può ridurre notevolmente la quantità di traffico di rete e il contenuto di risorse di rete e del server.

Scaricare il manuale

Questo argomento è incluso nel manuale seguente, che può essere scaricato per una lettura e una stampa più agevoli:

• Pianificazione e architettura di Office SharePoint Server 2007, parte 2 (informazioni in lingua inglese)

Per un elenco completo dei manuali disponibili che è possibile scaricare per Office SharePoint Server 2007, vedere Downloadable content for Office SharePoint Server 2007 (informazioni in lingua inglese).

Vedere anche

Concetti

Ottimizzazione di web part personalizzate per la rete WAN
Estensione delle soluzioni globali di Office SharePoint Server con Office Outlook 2007 e Office Groove
Soluzioni globali per Office SharePoint Server supportate