Monthly Archives: November 2009

3 soluzioni per la profilazione delle prestazioni dei siti web

Oltre agli usuali strumenti di profilazione di un sito web lato desktop (e mi riferisco ovviamente  a Firebug, YSlow! e Google Page Speed), può tornare utile l’utilizzo di uno strumento esterno che guardi e provi il sito un po’ come lo potrebbe vedere un nostro utente e magari torni anche qualche numero, se non proprio qualche consiglio. Questi tre strumenti (siti web) che vi presento servono proprio a questo. L’elenco non è in un particolare ordine.

  • Web Site Optimization il servizio nasce correlato all’omonimo libro. Una volta eseguito il test, verranno mostrati i tempi di caricamento di ogni elemento della pagina richiesta e anche una lista di consigli da applicare per migliorare le prestazioni. Sicuramente non è il sito più bello graficamente.
  • FPT di Pingdom Tools una volta effettuato il test, verrà visualizzato il waterfall di tutte le richieste, con i tempi relativi ad ognuna di esse. Una volta ottenuta la lista, questa può essere ordinata o filtrata a piacere. In fondo alla pagina c’è un specchietto che riassume le statistiche ed è inoltre possibile visualizzare di nuovo i risultati di questo test (senza lanciarlo di nuovo) salvandosi il permanent link che viene proposto in fondo alla tabella dei risultati
  • Web Page Test è sicuramente il test più aggressivo e più completo. Permette di specificare quante volte eseguire il test, e nei risultati verranno visualizzati i valori medi. Sebbene i risultati siano presentati in modo graficamente discutibile, sono presenti gli waterfall delle richieste, una checklist da seguire per una eventuale ottimizzazione, e un grafico a torta che rappresenta la suddivisione del traffico dal sito provato in base al tipo di contenuto. Come per Pingdom è altresì possibile salvarsi l’URL del test per successive visualizzazioni senza doverlo eseguire di nuovo

Snippet – show/hide oneliner

Capita milioni di volte di aver, su una pagina web, il classico trigger “Visualizza XXX” che, una volta visualizzato XXX diventa “Nascondi XXX”. Secondo me il più piccolo codice che effettua questa operazione con jQuery è il seguente:

// Usa un <a> come trigger
$("#tgl-XXX").click(function() {
 $(this).html($('#lst-XXX').toggle().is(':visible') ? 'Hide XXX list' : 'Show/Edit XXX list');
 return false;
});

No?

Nota: non è possibile in questo modo usare il parametro “fast/slow” della toggle.


Sempre più Google

Ma avete tenuto il conto di tutto quello che Google ha buttato fuori nell’ultimo mese o due? Io ci ho provato, ecco l’elenco:

  • Google Wave; quello che praticamente dovrebbe essere una rivoluzione ma anche no. Quello che «non ho capito a che serve» ma anche «ci ho già fatto un bot». Dopo una primissima fase stitica dove avere un invito era cool, adesso comincia già ad essere di tendenza non esserci. Staremo a vedere.
  • Il linguaggio Go; nasce come uno dei task del famoso 20% del tempo degli ingegneri google. Dicono rimpiazzerà Python in Google perché quest’ultimo è poco scalabile. Per adesso l’unica cosa che dico è che l’installer è poco professionale. Staremo a vedere
  • Con 5$ miseri dollari all’anno adesso puoi aggiungere 20GB alla tua casella di posta GMail o Picasa (no, hard disk virtuali, per adesso)
  • Google Caffeine; dovrebbe essere il nuovo framework dietro il motore di ricerca di Google (avete presente? Quella cosa che Google fa fin dall’inizio). Adesso pare sia pronto. Pronti a piangere sulla caduta del vostro PR?
  • Closure; tutto il codice JavaScript (in forma di libreria con tanto di widget) e tutti gli strumenti per il deploy (come il compiler) che per anni (7, dicono) hanno fornito l’interfaccia dei prodotti più famosi di Google, come Gmail e GDocs adesso sono stati rilasciati con una licenza libera (qui ci sono i motivi per i quali eviterò di provare la libreria)
  • Google Latitude; hanno aggiunto un paio di cosine interessanti, come le notifiche e la cronologia. Io non lo uso, non so esattamente cosa sia. Non mi pare abbia “rivoluzionato” niente.
  • Google Maps Navigation; ha fatto crollare il titolo di Garmin e TomTom di un secco 35%; applicazione gratis su Android e nuove API su Google Maps
  • Google Voice ha aggiunto il supporto ai numeri esistenti.
  • Dai commenti: avevo dimenticao Google Dashboard

Mi sono dimenticato qualcosa?


Per chi scade la sessione

Questa cosa continuo a scordarmela, battendoci il testone ogni nuova applicazione che faccio. Ora me la scrivo qui e non me la dimentico più (sì, certo).

Il problema in due parole: fai login sulla tua applicazione in PHP e dopo 20 minuti di inattività di trovi di nuovo buttato fuori e devi rifare login. Che noia! Voglio fare in modo che la mia sessione di lavoro duri molto ma molto di più. Ma come? A questo proposito occorre sapere un paio di cosette…

Affinché la propria applicazione si “ricordi” il login, sappiamo bene che si utilizza quasi sempre il concetto di SESSIONE. Fin qui niente di nuovo (faccio giusto per mettere sul banchetto tutti i pezzetti). La gestione delle sessioni in PHP – generalmente – utilizza un cookie, il quale serve per conoscere la corrispondenza tra la richiesta HTTP (dove viaggia il cookie) e la sessione (salvata sul server). Il contenuto del cookie di sessione potrebbe essere, per esempio, il nome del file con i dati che devono rimanere semipermanenti (salvataggio dello stato dell’applicazione).

La prima cosa da modificare, se si vuole che la sessione duri un tempo da noi scelto, è dunque la durata della validità di questo cookie. Per default questo cookie scade alla chiusura del browser (evento che si chiama, giusto per fare confusione, “end of session“). Usando le apposite funzioni PHP session_set_cookie_params() e session_name() si cambia la durata del cookie a nostro piacimento e magari anche il nome, giusto per non avere sempre il solito PHPSESSID.

Riproviamo e dopo un po’ che lavoriamo, magari su più progetti, ci accorgiamo che… il cookie scade effettivamente tra 10 giorni, ma la sessione continua (ci sembra!) a buttarci fuori troppo spesso!

L’inghippo sta in un altro parametro della sessione: gc_maxlifetime (maledetto!). Questo valore indica al php ogni quanto far scadere le sessioni non più utilizzate. Il concetto è: in un’applicazione molto trafficata, viene creato un file di sessione per ogni nuovo utente (google compreso, se non si fa attenzione). Se qualcuno, ogni tanto, non si prendesse la briga di fare pulizia di questi file che magari nessuno usa più da mesi, beh, immaginate cosa potrebbe succedere (e i gli utilizzatori di Ruby On Rails credo sappiano di cosa sto parlando…).

Il PHP ha un suo sistema “interno” di pulizia. Il prefisso “gc” di quella variabile di configurazione infatti sta proprio per garbage collector. Ogni volta che si richiede l’accesso ad una sessione, il PHP verifica se qualche file non è magari troppo vecchio e dunque da cancellare. Ma “troppo vecchio” quanto? Beh, statisticamente vecchio quanto indica appunto il gc_maxlifetime (l’algoritmo è un pochino più complesso, ma è sufficiente capire il concetto). Il lifetime di default è proprio 1440 secondi, i famosi 20 minuti. Se non accediamo per 20 minuti (circa) alla nostra sessione ci sono buone probabilità che il PHP decida di cancellare il nostro file. E noi ci troveremo di nuovo sloggati.

Prima abbiamo dunque sistema il nostro cookie; adesso usiamo la ini_set() per portare a 86400 e rotti il nostro session.gc_maxlifetime.

Ci rimettiamo al lavoro felici quando un bel giorno ci accorgiamo che… siamo stati buttati fuori! ARGH! Perché!?

Il problema è che l’impostazione fatta tramite la ini_set() all’interno di uno script vale SOLO per quello script (e tutti quelli da esso inclusi, ovviamente). Non vale per TUTTI gli script di tutte le altre applicazioni che risiedono su quella macchina, applicazioni che condividono tutte la stessa directory delle sessioni. È dunque sufficiente che uno di questi script venga eseguito una volta, e la sua session_start() deciderà che il file di sessione dell’altra applicazione (ma lui che ne sa?) è scaduto e deve essere cancellato.

A questo punto ci sono un paio  di opzioni (tre o quattro, in verità):

  • imposto il mio gc_maxlifetime a livello globale (php.ini) così che valga per tutte le applicazioni
  • modifico il session.save_path di ogni applicazione che gira sullo stesso server in modo che ognuna gestisca solo i SUOI file di sessione e così possa decidere indipendentemente anche il proprio gc_lifetime
  • modifico l’handler delle sessioni, spostandole magari in un database (session_set_save_handler()) o mi scrivo il mio sistema di garbage collector delle stesse (script in cron, per esempio…)

I contenuti di questo sito sono distribuiti con una licenza Creative Commons 2.5 eccetto dove diversamente specificato.

Tema WordPress Punto5 sviluppato da Claudio Cicali; icone del set famfamfam silk e komodomedia.

© 2005-2010
Claudio Cicali