Kapil Thangavelu - http://www.flickr.com/photos/spliter/53811168/

Plone non è di base un "pubblicatore" di contenuti, bensì un complesso CMS.. e fa qualcosa di più del servire pagine statiche sulla base di una rapida "traslazione" dell'URL su una cartella di filesystem o su un record di tabella relazionale.

Per questo, molti di coloro che lo usano direttamente anche come pubblicatore dei contenuti prodotti spesso si lamentano della lentezza con cui Plone svolge questo suo compito.

Vari aspetti contribuiscono a produrre una tale lentezza: dall'inadeguata messa in produzione del sistema, all'inevitabile mole di calcoli richiesta da ogni singola risorsa acceduta dagli utenti (tanto per dirne una, ogni singolo oggetto utilizzato da Plone in fase di pubblicazione scatena un controllo di sicurezza, granulare e potente, ma anche da mettere nel computo dei calcoli operati!)

Chiaramente queste considerazioni non mirano a farci rassegnare a una "lentezza" intrinseca che va accettata e stop..

Nei casi in cui sia possibile separare il sistema di pubblicazione dei contenuti da quello di gestione vera e propria, oggi possiamo prendere in considerazione una valida proposta che arriva da Kapil Thangavelu: Content Mirror.

Detto più in soldoni di come fa Kapil, si tratta di un replicatore di contenuti: in sostanza Content Mirror si preoccupa di replicare i nostri contenuti Plone su un DB relazionale, in modo sincrono. In questo modo il DB è a disposizione diretta di qualsiasi applicazione esterna a Plone abbia bisogno di usare quei dati.. presumibilmente per pubblicarli.

Certamente entrerà presto in qualcuno dei nostri progetti! Grazie Kapil!!

Come si dice, Content Mirror rappresenta l'estremo rimedio al male estremo.. Tuttavia in molti casi non potremo fare a meno di Plone, e qui i calcoli non si possono evitare.. ma si possono ottimizzare!

Uno dei fulcri fondamentali del framework Plone è il portal_catalog, l'altro Archetypes.

Entrambi sono da tempo nel mirino degli sviluppatori in quanto, sebbene validissimi strumenti di lavoro, hanno alcune "pecche" su cui si può lavorare per migliorare le prestazioni complessive.

Nel caso di Archetypes, è notorio che il numero di reindicizzazioni a catalogo lanciate durante le fasi di modifica di un oggetto per vari motivi sono spesso in numero maggiore dell'unica finale necessaria. Per poter migliorare tale situazione senza dover ricostruire Archetypes da zero (impresa titanica, e inutile.. dato che le tecnologie Z3 lo stanno naturalmente rendendo obsoleto) genialmente si è pensato di rendere asincrona la fase di reindicizzazione, in modo da poter catturare le richieste sul bordo delle transazioni di modifica, e filtrando in questo modo quelle ridondanti.

Se siete interessati a questi meccanismi collective.indexing è il vostro prodotto!

In seconda battuta, qualcuno si è ultimamente dedicato a cercare di capire se le strategie adottate dal catalogo durante le query fossero il meglio che si possa fare.. scoprendo che non lo sono.

Tutti i dettagli nell'articolo Catalog query plan di Helge Tesdal.

Ah! e dato che oggi è l'ultimo giorno prima delle ferie.. buone ferie a tutti quelli che le faranno! :D