Fare il backup del vostro sito Plone

Dovete eseguire regolarmente il backup di un sito Plone; la maggioranza delle persone eseguono i backup ogni notte. La vostra applicazione ha necessità di determinare la schedulazione del backup. Se, vengono scritti all’interno del vostro sito, una grande quantità di dati, allora è forse necessario fare backup più di frequente. Nel caso di un piccolo sito, con meno contento, possono essere più appropriati, schedulazioni meno frequenti, come, ad esempio, una volta alla settimana, .

In un sito Plone standard, solamente di un file è necessario fare il backup: il database Zope, data.fs, file ove risiede tutto il contento del sito Plone. Potete localizzare questo file, accedendo al pannello di controllo della Zope Managemet Interface (ZMI), selezionando Gestione Database,

< manca qualcosa, Ugo >

Data.fs var Potete usare i vostri scripts o tools personali, per fare backup, o potete usare un tool di Zope.

Come esempio, della prima opzione, il listato 14-1 mostra, uno script bash Linux, che usiamo per fare il backup di un sito Zope.

Listato 14-1. Script bash per fare il backup

#!/bin/bash
# script to copy, gzip, and then copy Zope databases
# to remote server
# make up a filename
fn=`uuidgen`.fs
# copy it locally, you'll want to change the
# path
cp /var/zope.test/var/Data.fs /tmp/$fn
# gzip the file up
gzip /tmp/$fn
# scp over to my backup server and then remove
# the temporary file
# change the destination file
scp /tmp/$fn.gz backup@backups.agmweb.ca:~/Zope
rm /tmp/$fn.gz

Mentre, per la seconda di queste scelte, uno script Python, chiamato repozo.py, è disponibile nel Zope Object Database (ZODB) per effettuare il backup. Potete trovare questo script on-line presso http://cvs.zope.org/ZODB3/Tools/repozo.py. Funziona piuttosto bene, sia su Windows che su Linux. Questo script può fare moltissime cose, come: effettuare un completo backup, un backup incrementale e ripristinare il database.

Per effettuare il backup del database, con questo script, dovete prima creare una cartella per archiviarlo; negli esempi seguenti, questa cartella è, /home/backups. Comunque, questa ubicazione è facoltativa. Per realizzare un backup completo del database, eseguite lo script seguente:

$ python repozo.py -B -F -v -r /home/backups -f /var/zope.test/var/Data.fs
looking for files b/w last full backup and 2003-11-21-18-33-17...
no files found
doing a full backup
writing full backup: 3601549 bytes to /home/backups/2003-11-21-18-33-17.fs

Per eseguire un backup imcrementale, omettete solamente il flag -F (full). Lo script confronterà il file ZODB corrente con l'ultimo salvato ed eseguirà solamente il backup delle differenze. Se non è avvenuto nessun cambiamento, allora nessun backup verrà eseguito. Ciò che segue, è un esempio di backup effettuato a seguito di modifiche in Plone:

$ python repozo.py -B -v -r /home/backups -f /var/zope.test/var/Data.fs
looking for files b/w last full backup and 2003-11-21-18-39-09...
files needed to recover state as of 2003-11-21-18-39-09:
        /home/backups/2003-11-21-18-33-17.fs
repository state: 3601549 bytes, md5: ab9e46bcdf52641ad6f71db62a9da333
current state   : 3624968 bytes, md5: 73c871bbe2528e152342abea9e25ab27
backed up state : 3601549 bytes, md5: ab9e46bcdf52641ad6f71db62a9da333
doing incremental, starting at: 3601549
writing incremental: 23419 bytes to /home/backups/2003-11-21-18-39-11.deltafs

A questo punto, avete ora un backup completo ed uno incrementale. Lo stesso script può ora effettuare un recupero di questi dati. Per realizzare ciò, eseguite lo scrip con il flag -R (recovery) e con il flag -o, che specifica il file di output, così come:

$ python repozo.py -R -v -r /home/backups -o /var/zope.test/var/Data.fs
looking for files b/w last full backup and 2003-11-21-18-50-21...
files needed to recover state as of 2003-11-21-18-50-21:
 /home/backups/2003-11-21-18-33-17.fs
 /home/backups/2003-11-21-18-39-11.deltafs
Recovering file to /var/zope.test/var/Data.fs
Recovered 3624968 bytes, md5: 73c871bbe2528e152342abea9e25ab27

Eseguite repozo.py con il flag -h, per un lista completa delle opzioni. Questo visualizzerà un insieme completo di istruzioni.

I file di log sono presenti nella directory log della vostra istanza home di default, e, in essa, vi sono due file di log: un file degli accessi ed un file degli eventi. Settate l'ubicazione di questi log, nel file di configurazione che avete incontrato nel capitolo 2. z2.log registra tutte le richieste entranti, ed event.log registra tutti gli errori. Dovrebbero essere fatti regolarmente i backup di questi file, insieme con qualsiasi file di log del server proxy, come quelli che sono prodotti da Apache o da Internet Information Server (IIS).

Dovrete fare regolarmente il backup dei file di codice, dei template e dei prodotti personalizzati che risiedono al di fuori del file ZODB. Anche se sono ubicati in un sistema di controllo dei sorgenti, come Concurrent Versioning System (CVS), eseguire il loro backup, per creare un valido snapshot della vostra installazione, non è male.

Se avete contenuti, altri database, o ulteriori dati, che non risiedono nel file ZODB, questi dovrebbero far parte del piano di backup, in funzione di come vengono spesso modificati. Questo può includere i dati, presenti in database relazionali, e contenuti nel File System. Tutto questo, è creato dallo sviluppatore del sito e non esiste in un sito Plone standard "fuori dalla scatola". Se state aggiornando Zope o Plone, può essere prudente fare un backup di tutti i file coinvolti, incluso Zope e Plone così che, se l'aggiornamento va a vuoto, per qualsiasi motivo, sia possibile fare un recovery completo.

Comprimere lo ZODB

Il file ZODB registra qualsiasi modifica di ogni oggetto del sistema. Ogni volta che un oggetto viene modificato, una copia nuova viene aggiunta alla fine del file ZODB. Questo è il file Data.fs, discusso nella sezione precedente. Se il database ha grandi porzioni di contenuto od ha un gran numero di modifiche, allora ciò può causare una crescita reale del file ZODB.

Un grande file ZODB non è un problema - lavora proprio bene, ed i tempi di avvio sono simili (a meno che l’index non sia stato rimosso). I tempi di compressione diventeranno più lunghi se il database è grande, ed ha senso, di tanto in tanto, rimuovere quelle vecchie copie di oggetti, che non vengono più usate, per rendere più piccolo il database. È fondamentale per tutti ricordarsi che, comprimendo, si sta ripulendo il database esistente ed che si stanno eliminando quelle vecchie copie.

>>> import os
>>> from stat import ST_SIZE
>>> type(os.stat('/tmp/test.txt')[ST_SIZE])
<type 'long'>

andy@thorin:/tmp/Zope-2.7.0-b3$ ./configure
Configuring Zope installation
...
 
This Python interpreter does not have have 'large file support' enabled.

La pulitura del database viene chiamata compressione (packing)

La fase di compressione può essere intensiva, e, quando il processo è in esecuzione in un thread separato, anche se si ripercuote sulla velocità del sito, sarete ancora capaci di rispondere alle richieste. Per comprimere il sito e mantenere alto il rendimento di Plone, vedete, successivamente in questo capitolo, la sezione "Usare ZEO". Per eseguire una compressione, accedete al pannello di controllo di ZMI, selezionate Gestione Database, e cliccate main

Figura 14-1. Comprimere un database

Digitate il numero dei giorni per i quali volete mantenere gli oggetti, e cliccate Pack. Per esempio, settando il numero di giorni a zero (di default) rimuoverete tutte le revisioni degli oggetti. Di nuovo, non cancellate l'oggetto stesso, solo quelle vecchie copie. Un setting, molto comune, è di porlo a sette, per rimuovere le revisioni più vecchie di una settimana. Facendo un appropriato setting con il vostro orario di backup, potete assicurarvi di tenere una copia di ogni oggetto. Il pack richiederà un po' di tempo e di potenza, in funzione della dimensione del vostro file ZODB. Plone lavorerà ancora, benché più lentamente, così che poteste desiderare di utilizzare ZEO per farlo.

Aggiornare Plone

Plone è continuamente aggiornato e migliorato; nuove versioni vengono rilasciate piuttosto regolarmente. Prima di effettuare l’aggiornamento ad una nuova versione, tuttavia, controllate che ne abbiate davvero bisogno. Spesso, le distribuzioni hanno cambiamenti minori o cambiamenti che possono non essere attinenti. Ogni distribuzione ha un lista di modifiche, accessibile dallo pagina del download. Conviene sempre vedere la lista, per essere sicuri che l'aggiornamento ne valga la pena.

Dopo avere effettuato il backup, scaricate l'aggiornamento. Probabilmente il modo più facile per effettuare un aggiornamento consiste nel ripetere gli stessi passi compiuti durante l'installazione. Per esempio, se avete installato, usando l'installer di Windows, scaricate il nuovo installer ed eseguite una nuova installazione. Se fate l'installazione dai sorgenti o da un pacchetto Debian, ripetete questi passi. I passi di aggiornamento sono:

1. Scaricate l'aggiornamento attinente.
2. Fermate Plone.
3. Fate il backup (come descritto precedentemente).
4. Installate l'aggiornamento.
5. Avviate Plone.

A questo punto, raccomandiamo di fatto di avviare Plone in modalità debug. Su Windows, potete farlo selezionando Start - Plone - Plone Debug. Su Linux potete farlo usando lo script runzope all’interno della directory bin della vostra istanza home, come così:

bin/runzope -X "debug-mode=on"

Eseguendo questa modalità di debug, vedrete direttamente qualsiasi errori che è accaduto durante l'aggiornamento alla nuova versione. Se siete contenti di ciò, potete ora procedere con il passo successivo, la migrazione.

Per ciascun sito Plone che avete, accedete alla ZMI ed accedete al tool portal_migration nel vostro sito Plone. Ha, in vicinanza, un punto esclamativo rosso brillante, ad indicare che il sito non è

<manca qualcosa - Ugo>

Il processo di migrazione cercherà di fare, per voi, queste modifiche. Finché eseguite questa migrazione è possibile che il vostro sito Plone possa essere rotto. Questo può richiedere del tempo, in funzione di ciò che sia necessario fare durante la migrazione. Per effettuare una migrazione, eseguite questi passi:

1. Dal portal_migration, cliccate la tab Migrate.
2. Cliccate il bottone upgrade. Questo può richiedere tempo, specialmente su grandi siti o se sia necessario un grande aggiornamento.
3. Il risultato della migrazione, un messaggio piuttosto lungo, verrà visualizzato sullo schermo. Se il messaggio finale è "End of upgrade path, migration has finished", allora la migrazione ha avuto successo. Qualsiasi messaggio d'errore sarà evidenziati in rosso.

Ripetete questo processo per ogni sito Plone all'interno della vostra istanza di Zope. Se allora siete contenti, con la migrazione del sito, arrestate Plone, in esecuzione in modalità debug. Riavviate Plone nella solita vostra modalità, e continuate ad utillizzarlo come prima.

Eseguire un benchmarcking di un sito Plone

Prima di provare ad ottimizzare un sito, compito fondamentale è trovare un valore numerico per il suo rendimento. Gli utenti inviano spesso dei feedback come "è troppo lento" o "prende troppo tempo per caricare." Questi commenti sono pressocchè inutili ad un sviluppatore; avete bisogno di quantificare la velocità così che possiate conoscere come esso sia ora veloce e di quale velocità abbiate bisogno di raggiungere. Solamente dopo, potete iniziare ad ottimizzare.

Per trovare un test di efficienza, potete utilizzare un tool chiamato ab, o Apache Bench. Questo è un tool che viene rilasciato con il server Apache. Se avete Apache 1.3 o successivo, installato su Linux, ab è incluso. Su Windows è incluso con la distribuzione Apache 2. Eseguire ab è semplice - giusto passare lo Uniform Resource Locator (URL) che desiderate testare, cosi come:

ab http://localhost/

Il tool ab produrrà, in output, informazioni, prima sul sito esaminato, così come:

Benchmarking localhost (be patient).....done
Server Software:        Zope/(unreleased
Server Hostname:        localhost
Server Port:            80
 
Document Path:          /
Document Length:        20594 bytes

Quindi produrrà, in output, statistiche globali, come così:

Concurrency Level:      1
Time taken for tests:   0.771151 seconds
Complete requests:      1
Failed requests:        0
Write errors:           0
Total transferred:      20933 bytes
HTML transferred:       20594 bytes
Requests per second:    1.30 [#/sec] (mean)
Time per request:       771.151 [ms] (mean)
Time per request:       771.151 [ms] (mean, across all concurrent requests)
Transfer rate:          25.94 [Kbytes/sec] received

Questo vi informa di quanto tempo prende la richiesta, il numero di errori, ed il tempo preso per trovare una richiesta che probabilmente è il chiave statistico. Il valore più utile di riferimento è di solito Requests for second. Richiesta al secondo, che in questo esempio è 1.30 [#/ secondo]. Il tool ab fornisce alcune ulteriori statistiche che danno informazioni su quanto tempo utilizza per connettersi, per trattare, e per trovare un risultato per ogni richiesta. Per esempio:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   770  770   0.0    770     770
Waiting:      766  766   0.0    766     766
Total:        770  770   0.0    770     770

Questo ultimo pezzo di informazioni è utile ed include il tempo utilizzato per trovare un collegamento. Siccome il server è sullo stesso computer come il client, questo è piuttosto breve. Questa prova dimostra che ci sono voluti 1.30 secondi per completare una richiesta. In realtà questo chiaramente non ha testato affatto molto il server. Quando testate, vorrete probabilmente verificare il server con molte richieste concomitanti per simulare,un poco di più, in modo reale. Potete farlo specificando il numero di richieste e la concomittanza usando le opzioni -c (threads concomittanti) e -n (numero di richieste). Per esempio:

ab -n 20 -c 4 http://localhost/

Questo, invia un totale di 20 richieste su 4 threads concomittanti. Il risultato finale è di 1.78 secondi, una richiesta lievemente diversa. Per ulteriori informazioni su tutte le opzioni disponibile, per favore vedate il manuale di Apache Bench presso http://httpd.apache.org/docs/programs/ab.html.

Un vantaggio di usare ab è che non si stanno assemblando in realtà pagine sul client; loro vengono solo scaricate e poi gettate via. Se avete una pagina che ha molte scripts o caratterizzata da grandi immagini, il tempo richiesto al un client per assemblarla non verrà incluso. Un esempio classico di ciò è che nel vecchio browser Netscape, un gran numero di tabelle, potevano rallentare o cashare Netscape. Questo non sarebbe chiaramente evidenziato usando ab che vi fornicse un numero, maggiormente indipendente, su cui lavorare.

Bugie, maledette bugie, e numeri di benchmark

A questo punto, possiamo preoccuparci di questi numeri. Sembrano evidenziare un sito molto lento. In questo esempio, la nostra macchina è un laptop Toshiba con un microprocessore Celeron 1.8 gigahertz (GHz), 256 megabyte (MB) di Random Access Memory (RAM), Red Hat Linux 9.0, ed una versione beta di Plone 2. Inoltre, Plone sta funzionando in modalità debug contemporaneamente con KDE, OpenOffice.org, Istant Message, e diversi altri tools di sviluppo, incluso l'attuale tool di benchmarking. Questo vuol dire che Plone non sia in alcun modo ottimizzato o sia eseguito in un ambiente ideale. Un simile test su un server, più veloce, produce come risultato circa 20 richieste al secondo.

Il punto fondamentale è che creare un numero oggettivo, per il rendimento del sito, vi permette di misurare il successo delle vostre ottimizzazioni. Gli sviluppatori possono effettuare modifiche e quindi possono esaminarlo di nuovo comparando i numeri "prima" e "dopo". Se è possibile, dovreste eseguire prove di rendimento su una macchina simile al server di produzione per trovare numeri sensati. Per questo capitolo non è importante che un sito possa produrre X richiede al secondo; è importante, invece, che una modifica sia capace di produrre un aumento significativo del rendimento.

Inoltre, ricordate che i numeri, intorno alla velocità di alcune parti del vostro sito, non siano molto significativi in isolamento. Dovete prendere in considerazione come spesso venga visitata la pagina, le aspettative degli utenti a questo punto, e i requisiti realistici. Micromisurare solo uno parte di un sito può essere utile per localizzare in profondità un certo problema, ma può non rendere molto più veloce il vostro sito. Come in molte cose, si ha bisogno di un approccio ragionato alle ottimmizzazioni.

Modalità di produzione contro modalità di debug.

Uno dei maggiori responsabili della velocità di Plone è: eseguire il sito in modalità debug. Quando viene eseguito in modalità debug, ogni template, script, ed oggetto nel tool*portal_skin* viene confrontato con il File System per verificare che sia recente. Questo controllo succede con <manca qualcosa – Ugo >

Per scoprire se il vostro sito stia funzionando in modalità debug, nella ZMI accedete all’oggetto portal_migration del vostro sito Plone. In fondo alla pagina vi sarà un lista di informazioni, incluso lo status Debug Mode. Per cambiarlo, modificate il file di configurazione, come descritto nel capitolo 2.

Altre ragioni per un rendimento lento

Un server può funzionare lentamente per ragioni esterne a Plone. Se sta eseguendo una fase di ottimizzazione, dovreste dare sempre prima un sguardo a queste considerazioni, in quando forniscono rapidi miglioramenti di velocità a poco costo.

Ammontare di memoria

A Zope piace usare molta memoria per gli oggetti caricati dal file ZODB. Fornire ad un server Zope ulteriore memoria è probabilmente, di tutte le caratteristiche fondamentali, la migliore cosa che si possa fare.

Per scoprire cosa viene eseguito sotto un server Linux, usate il comando top. In Windows, il Task Manager (accessibile premendo Ctrl+Alt+Del) vi darà simili statistiche. L'ammontare raccomandato di memoria dipende dalla dimensione e dal carico del traffico del vostro server Plone, ma un quantità di 512MB è un buon punto di partenza. Se potete permettersi più memoria, questo è raccomandato.

Potete fare alcune modifiche ai parametri di memoria di Plone aumentando il numero di target di oggetti in cache. Di default, Plone carica 400 oggetti in cache. Per un sito, si può aumentare questo a 5,000, come mostrato in figura 14-2. Sebbene questo aumento di uso della memoria, questo inoltre <manca qualcosa – Ugo>

Figura 14-2. Cambiando i parametri di cache nel pannello di controllo

Inoltre, meno sono i threads usati da Zope, potenzialmente meno utilizzo della memoria occorrerà. Anche se Zope sia multithreaded, la maggior parte del tempo verrà utilizzata da un solo thread Zope. Ridurre il numero di threads a tre fornisce un server con maggior memoria-efficiente. Invece di tentare di eseguire un gran numero di threads, è condìsigliato eseguire client ZEO per servire più richieste. La sezione "Zope Oggetti Enterprise" tratta questo, con maggior dettaglio.

            Connection Times (ms)
            min  mean[+/-sd] median   max
Connect:       90  133  40.2    125     211
Processing:   511 1103 400.2   1113    1846
Waiting:      202  310 110.3    293     565
Total:        601 1236 411.2   1211    2043

Profiler di Plone

Visto che si può quantificare il tempo richiesto per produrre delle pagine, si può ora tentare di ottimizzare. Il primo problema rimane trovare, comunque, dove ottimizzare.

Per favore notate che se abilita tutti tre questi tools che tracciano profili, noterete che il vostro sito Plone inizia realmente a rallentare (di una grandezza significativa). Ognuno di questi profilers esigono un tributo sul rendimento per il numero di collegamenti che debbono installare. Dovreste disinstallarli sempre od arrestarli dopo che li avete usati, per assicurarvi che il vostro sito stia funzionando al massimo dell’efficienza. Inoltre, se abilite tutti tre questi profilers, iniziate ad elaborare il profilo dai profilers (e questo avviene quando si inizia a trovare confusione). Raccomandiamo di iniziare da Call Prifiler. Quindi, eseguite a turno ciascuno degli altri profilers, arrestando il profiler precedente, finché avete raccolto abbastanza informazioni.

Call profiler

Questo prodotto Zope fornisce una richiesta, come trovare una front page ed un report degli oggetti che sono stati usati e di quanto tempo viene richiesto da ognuno. Potete trovare Call Prifiler presso http://zope.org/Members/richard/CallProfiler. Nonostante i commenti sulla pagina di download, il prodotto non è integrato in Zope 2.6. Installate il prodotto nel modo standard, e poi riavviate il vostro Zope.

Per abilitare Call Profiler, andate nel pannello di controllo ZMI e scegliete Call Profiler. Il prodotto funziona installando collegamenti ad un oggetto così che quando si accede ad esso, l'ammontare di tempo speso per restituirlo possa essere misurato. Ricordate che Call Profiler verrà attivato solamente sugli oggetti che scegliete di esaminare, come mostrato in figura 14-3. Per un'configurazione standard di Plone, avrete bisogno di esaminare Filesystem Script (Python) e Filesystem Page Template. Call Profiler non ricorda questi settaggi fra riavvii di Zope, il che significa che, un semplice riavvio, disattiverà i collegamenti e che lascerà pronto per il deploy.

Figura 14-3. Call Profiler con gli agganci al File System selezionati

Una volta che gli oggetti da esaminare sono stati selezionati, accedete all'URL che volete esaminare. Il modo più facile di accedere all'URL da esaminare è eseguire il tool ab menzionato precedentemente; funzionerà più che bene, comunque, usando un browser Web. In questo caso, se sta eseguendo il profilo della pagina iniziale su localhost, eseguite quindi il seguente:

ab -n 20 -c 4 http://localhost/

Questo provocherà 20 richieste da fare a Plone. Una volta completate, potete visionare il tempo richiesto. Ritornando all'interfaccia di Call Profiler, vedrete tre tab, in alto al tool Call Profiler: Results, Results by URL ed Aggregates. Visto che sono state eseguite richieste multiple, selezionate il tab Aggregates che è più facile da capire. Nella lista delle pagine chiamate vedrete l'URL esaminato. Cliccate quel link per vedere i risultati di questo URL. Dovreste ora vedere qualche cosa come in figura 14-4.

Figura 14-4. I risultati del profiler

In questo esempio, vedrete gli elementi che Call Profiler è capace di rilevare. Sfortunatamente, i risultati possono essere un pò complicati da decifrare. Per primo osservate che i risultati si sommano più del 100 per cento. In questo caso, document_view richiede il 71.1 per cento del tempo di processo. Questo è, comunque, forviante perché valuta, sotto questa figura relativa a document_view, non all’intera pagina. In questo esempio, per l’intera pagina, qualsiasi cosa, prima di browserDefault, richiede il 19.9 per cento della richiesta. Poi passa a document_view, e vedete le percentuali per questa parte. Quindi in questo caso, l’andare da toLocalizedTime a getPreviousMonth richiede il 23.3 percento del tempo richiesto per rendere document_view.

Eseguire il profiler del modello di pagina

Page Template Profiler lavora solamente con il sistema Zope Page Templates. In un modo simile a Call Profiler, restituisce, quanto tempo è stato impiegato per rappresentare ciascuna chiamata in un modello di pagina. Cosi, nell'esempio precedente, vedete che, la maggior parte del tempo, viene speso in un modello di pagina (document_view), potete trovarlo istruttivo vedere come il tempo viene impiegato in quel modello.

Potete trovare Page Template Profiler presso http://zope.org/Members/guido_w/PTProfiler. Installate il prodotto, e poi riavviate Zope. Per disistallare il Page Template Profiler, dovrete rimuoverlo dalla vostra directory Products quando avete finito di eseguire il profiler.

Una volta installato, andate alla radice di Zope, nella ZMI, e selezionate PT Profiler Viewer, in Add della casella a discesa. Completate il modulo di creazione, dando un unico valore ad Id (digitate PTProfiler, per esempio), e quindi cliccate Add. Ora ripetete la chiamata alla pagina che volete misurare eseguendo il tool ab od accedendo alla pagina in un browser. Accedete giusto all'oggetto Page Template Profiler, e vedrete un risultato per la richiesta giusto eseguit a. Cliccate per trovare maggiori dettagli, come mostrato in figura 14-5.

Figura 14-5. I risultati di Page Template Profiler

In questo caso, potete vedere che, sul nostro sito, calendarBox stia utilizzando 0.7321 secondi di chiamata per ogni volta che viene chiamato. Visto che l’intera pagina sta utilizzando 1.9 secondi, si può presumere che sia questo un campo che potremmo ottimizzare.

Python Profiler

Il Python Profiler offre molte informazioni, a basso livello, sui tempi e viene normalmente usato per effettuare debugging più complesso sul codice fondamentale. Fornisce un prospetto particolareggiato dell'ammontare di tempo speso in vari campi dal codice Python. Questo non è, normalmente, qualche cosa che viene utilizzato per effettuare il profiler di un sito; per completezza, comunque, lo descriveremo in questa sezione.

Per attivare Profiler Python, avete bisogno di aggiungere una variabile al file di configurazione. Nel file zope.conf nella vostra directory ect, abilitate il comando publisher-profile-file. Per fare questo, definite un file sul quale scrivere. Su Windows questo potrebbe essere c:zope.output; su Linux è /tmp/zope.output. Aggiungete la seguente linea su Linux:

publisher-profile-file /tmp/zope.output

Poi riavviate Plone, ma verrà eseguito molto lentamente. Se state eseguendo un gran numero di richieste e volete esaminare i risultati, allora il file specificato nella variabile di ambiente conterrà l’output dei dati. Come negli esempi precedenti, chiamate la pagina che viene elaborata usando il tool ab od un browser Web. Accedete quindi al pannello di controllo attraverso la ZMI, selezionate Info Debug, e quindi selezionate la tab Profiling; otterrete l’output del Python Profiler, come mostrato in figura 14-6.

Figura 14-6. Risultati del Python Profiler

Come potete vedere in figura 14-6 l’output mostra i dettagli cruenti di ciò che richiede più tempo. Abbiamo dovuto usarlo raramente.

Semplici trucchi di ottimizzazione

Dopo avere completamente osservato molto Plone, la squadra di sviluppo è arrivata ad individuare i seguenti trucchi di ottimizzazione.

<tal:block
 tal:repeat="result here/portal_catalog">
   <a href=""
      tal:attributes="href here/portal_url/getPortalUrl">Home</a>
   ...
</tal:block>

Ma è più veloce usare un *tal:define*, come:

<tal:block
 tal:repeat="result here/portal_catalog"
 tal:define="url here/portal_url/getPortalUrl>
    <a href=""
       tal:attributes="href url">Home</a>
       ...
</tal:block>

Caching dei contenuti

Così ora che avete trovato le parti più lente della vostra applicazione, vi rivolgerete al principale tool per aumentare il rendimento: caching. Caching <manca qualcosa - Ugo >

Quando si parla di far caching, stiamo discuttendo approssimativamente di due cose che possono essere cached: il contenuto e lo skin. Il contenuto è costituito dai dati digitati dall'utente in tipi Contents. Lo skin si riferisce a qualsiasi cosa presente in portal_skin e può essere: template, scripts, immagini, o file. Questi due tipi sono differentemente cached.

Ci piace pensare al caching in termini di ammontare di controlli che avremo sul meccanismo di caching. In altre parole, più vicino al client sarà effettuato il caching, più veloce sarà la risposta ma anche meno controlli avremo su quella cache. Questo infatti include la possibilità che può non esservi affatto cache. La figura 14-7 illustra caching fra un client ed un server.

Figura 14-7. Cache fra un client ed un server

La cache del browser dell'utente è il posto più veloce per effettuare cache, ma non avete idea se l’utente abbia davvero abilitato, nel proprio browser, la cache. Successivamente viene la cache intermedia del server proxy; ricordate, questo potrebbe essere il vostro server proxy (quello sul quale dovete avere controllo) o un proxy di un Internet Service Provider (ISP). Vi sono finalmente, le opzioni di caching del server.

Nelle seguenti sezioni, discuteremo dei seguenti meccanismi di caching:

• Caching degli elementi di skin usando Accelerated HTTP Cache Manager
• Caching del codice usando RAM Cache Manager
• Caching dei contenuti, aggiunti dagli utenti, attraverso Caching Policy Manager

Discuteremo quindi di come usare Apache e Squid, due server esterni, comunemente usati, che offrono un host intero di opzioni di configurazione ad alto rendimento.

Caching Skin

Hypertext Transfer Protocoll (HTTP) permette di settare le intestazioni HTTP per il caching. Quando una risposta ritorna con queste intestazioni, è responsabilità dei proxy, fra il client ed il server, di mettere in cache l'oggetto secondo queste intestazioni. In figura 14-7, potrebbe essere qualsiasi cache dal server cache in giù. Questo proxy può essere un server Web, che controllate sul server, come Apache o un proxy che viene controllato dal ISP. Come discuteremo, questo realizza un potente tool quando unito con Apache o con Squid.

Questi caching possono includere anche il browser, se settato per usare caching (di default per Internet Explorer). Comunque, se un browser esegue un aggiornamento su una pagina, il browser spedisce l’intestazione Pragma: no cache che forza i proxy a ricaricare anche la loro copia.

Il caching viene applicato, in questa modalità, all’intera risposta, così che possa essere rischioso se provate ad applicarlo ad una pagina intera. Questo viene usato più comunemente con immagini, fogli di stile, JavaScript, o pagine che non subiscono cambiamenti in grande quantità. Immagini usate ripetutamente nelle vostre pagine per realizzare belli elementi, come angoli rotondi o immagini di background, sono ideali per questo.

Di default, Plone crea un Accelerated HTTP Cache Manager, chiamato HTTPCache, nella radice del vostro sito Plone. Per accedere a questo oggetto, attraverso la ZMI, utilizzerete le opzioni di gestione per la cache. Ciò che segue sono tutte accettabili di default e non avete bisogno di cambiarle inizialmente:

• Title
• Interval
• Cache anonimous connections only
• Notify URLs (via PURGE)

Per vedere come Accelerated HTTP Cache Manager lavori, ciò che segue è un esempio basato su un oggetto di prova, un'immagine chiamata test.gif. Per vedere che le intestazioni siano restituite, avete bisogno di esaminare le intestazioni che sono ritornate. Per fare questo potete usare un semplice script Python chiamato header.py. Potete trovare questo script nell’Appendice B. Su Linux il comando wget esegue inoltre la stessa cosa se passate - S, sebbene scaricate ancora il file. Per esempio:

wget -S http://www.agmweb.ca

Primo, ciò che segue, sono le intestazioni ritornate prima per test.gif

[andy@basil scripts]$ ./header.py http://localhost:8080/test.gif GET
Accept-Ranges: bytes
Connection: close
Content-Length: 2541
Content-Type: image/gif
Date: Wed, 03 Sep 2003 23:55:38 GMT
Etag:
Last-Modified: Wed, 03 Sep 2003 23:54:27 GMT
Server: Zope/(unreleased version, python 2.2.2, linux2) ZServer/1.1

Dopo avere aggiunto l'immagine alla cache, riverificherete le intestazioni HTTP, usando di nuovo lo script. Troverete che vi sono due intestazioni nuove. Per esempio:

[andy@basil scripts]$ ./header.py http://localhost:8080/test.gif GET
...
Cache-Control: max-age=3600
Expires: Thu, 04 Sep 2003 00:56:03 GMT on 2.2.2, linux2) Zserver/1.1

NOTA: Sfortunatamente, Zope 2 non e conforme alla Request for Comments (RFC), riguardante le richieste HEAD. Invece di spedire il set completo di intestazioni, quando una richiesta HEAD viene spedita, i valori dal cache manager sono persi. Quando testate, dovete sempre spedire la richiesta GET.

Per ulteriori informazioni sulle intestazioni HTTP e su come fanno riferimento al caching, vedete la RFC 2616 presso http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

La Accelerated HTTP Cache Manager caches un'intera risposta, che funziona bene con items statici. Comunque, la pagina normale di Plone consiste di elementi personalizzati, come il calendario, la barra di navigazione personale, e così via. In questa situazione, avete bisogno di essere capace di abilitare la cache solo su una parte della pagina, e qui è dove RAM Cache Manager diventa utile.

La RAM Cache Manager cache l’output di un oggetto in RAM così che alla prossima richiesta di questo script, venga prelevato dalla cache. Ripetute richieste di questo oggetto produrranno l’output prelevato dalla cache finché la cache non espiri. La forza di questo manager è che sta in realtà evitando complicati ricalcoli od ogni volta grande calcoli; invece, sta conservando il risultato e lo sta riutilizzando. Questo Cache Manager non cache immagini o file. Non bloccherà gli utenti che tentano di configurare la cache per fare ciò, ma non ha effetto su questi oggetti.

Di default, Plone crea un RAM Manager chiamato RAMCache nella radice del vostro sito Plone. Per accedere a questo oggetto attraverso la ZMI aprite le opzioni di gestione per la cache. Ciò che segue è tutto accettabile di default, e non avete bisogno di cambiarlo inizialmente:

• Title: Questo è il titolo del manager di cache ed è opzionale.
• REQUEST variables: Queste sono le variabili che formano la condizione per la cache. Questa è un opzione potente che permette alla cache di essere basata sulle variabili fornite dell’utente. Per esempio, se un item, per essere cached, richiede che dovrebbe essere differentemente cached per ogni utente, od in lingue diverse, potete digitare le variabili di REQUEST che gradireste qui cache.
• Threshold entries: Questo è il numero massimo di entrate che possono essere conservate nella cache. Se la cache sta richiedendo troppa RAM, abbassate questo valore.
• Maximum age of a cache entry: Questo è l'ammontare di tempo (in secondi) che questo oggetto rimarrà in cache.
• Cleanup interval: Questo è come spesso la cache viene pulita.

Poiché le richieste per l'oggetto di fatto giungono a Zope, questo non fa nulla per ridurre il traffico di rete; esso solo richiede a Zope di rendere il risultato più velocemente. Selezionando la tab Statistics, nella ZMI, riporterà precisamente la statistica di quanti hits sono stati restituiti dalla cache e di quanti sono stati passati sopra l'oggetto. Se troppi hits sono passati sull'oggetto, potete prendere in considerazione di modificare la configurazione della cache avendo meno variabili REQUEST od aumentando il tempo usato nella cache.

Assegnare cache

Per aggiungere un oggetto che sia nel File System alla cache, semplicemente specificare il nome della cache nel file .metadata per quel oggetto. (nel capitolo 7 abbi