Ci vediamo lì!

Le situazioni che portano a dover affrontare questo problema sono essenzialmente due:

1) una certa applicazione inizia a generare più traffico di quello che l’infrastruttura attuale riesce a sostenere: è quindi necessario scalare orizzontalmente per distribuire le richieste e frazionare il rischio

2) stiamo lavorando ad un’applicazione che già a priori sappiamo genererà parecchio traffico da richiedere un sistema bilanciato anche per assicurarne la disponibilità

Nel primo caso l’applicazione andrà adattata, nel secondo sarà più semplice partire già seguendo la strada giusta.

Il problema da risolvere, per applicazioni e/o infrastrutture non progettate per lo scopo, è il seguente. In un sistema bilanciato richieste successive degli utenti vengono distribuite da un bilanciatore sui vari nodi componenti il cluster frontend (server web) dell’infrastruttura. Dato che PHP di default salva i dati della sessione sul disco della singola macchina che ha elaborato la richiesta (singolo server web) è facilmente intuibile che alla richiesta successiva, che presumibilmente verrà indirizzata ad un altro server web, i dati della sessione non saranno più disponibili per l’applicazione essendo così la causa potenziale di non pochi problemi.

Per ovviare al problema le strade percorribili sono diverse.

NFS: soluzione sconsigliata, citata solo per completezza e ragioni storiche. Ricorrendo all’utilizzo in un network file system possiamo fare in modo che tutti i server web utilizzino questo spazio condiviso per leggere e scrivere in un unico punti i dati delle sessioni degli utenti. In questo modo senza alcuna modifica all’applicazione abbiamo centralizzato i dati permettendo a tutti i web server di vedere le sessioni create dagli altri. Purtroppo però i contro sono rappresentati da performance poco raccomandabili e problemi di data corruption che si possono incontrare specialmente quando le scritture iniziano ad essere elevate.

COOKIE: ricorrere all’utilizzo di cookie criptati permette di far viaggiare i dati della sessione assieme alle richieste effettuate dall’utente. I dati sono salvati lato client, quindi non c’è bisogno di uno storage centralizzato. E’ una soluzione facile da realizzare e che può incontrare solo problemi legati alla dimensione dei dati da memorizzare. Il prezzo da pagare è quello di un leggero incremento della banda utilizzata per lo scambio di queste informazioni aggiuntive.

DATABASE: utilizzare un database permette di centralizzare le sessioni e renderle facilmente disponibili ai vari webserver oltre che facilitarne la persistenza. In contesti con traffico non eccessivo può essere una buona soluzione per l’utilizzo di uno strumento “semplice” come un database. All’aumentare del traffico però il rapporto tra letture e scritture inizia a creare qualche problema dato che non è possibile ottimizzare il servizio per  l’una o l’altra operazione, inoltre senza il passaggio ad un sistema master-slave o master-master con N slave (creando ulteriore complessità nell’architettura generale) il database rappresenta il single point of failure per questo tipo di approccio. Inoltre può trasformarsi in un collo di bottiglia non indifferente.

MEMCACHED: utilizzare la memoria per leggere e scrivere dati permette di avere prestazioni che filesystem e database relazionali non possono nemmeno sognare. Memcached essendo poi clusterizzabile rappresenta una soluzione molto interessante specie in quei casi dove l’eventuale perdita dei dati (corruzione memoria) non è un evento tragico. Infatti avendo a che fare con la memoria i problemi possono derivare dalla corruzione della stessa, che porta alla perdita di tutti i dati presenti in quel momento perchè non vi è un sistema di persistenza. Inoltre la memoria è ciclica percui se la quantità di memoria allocata a Memcached non è correttamente proporzionata i dati più “vecchi” vengono eliminati per lasciare spazio a quelli “nuovi”.

REDIS (CLUSTER): come visto per Memcached sappiamo che la memoria rappresenta uno strumento ottimale in termini di performance. Redis permette inoltre di evitare i problemi di persistenza perchè ad intervalli regolari salva i dati anche su disco. Dalla versione 2.4 (al momento in sviluppo) sarà disponibile anche la versione cluster che quindi permetterà di allestire infrastrutture al pari di quelle realizzate con Memcached.

STICKY SU BALANCER HW (LAYER 7): una soluzione che non richiede modifiche all’applicazione ed all’infrastuttura è a disposizione nel caso in cui si utilizzi un balancer hardware che gestisce le sessioni in modo persistente. In questo modo l’utente verrebbe indirizzato durante la sua sessione di navigazione sempre verso lo stesso webserver. Il vantaggio è che l’applicazione non andrebbe modificata, le gestione delle sessioni è tutta a monte demandata al bilanciatore di carico. Il rovescio della medaglia? Il costo: balancer di questo tipo comportano spese ben superiori rispetto a balancer non persistenti che si possono realizzare anche con un semplice server predisposto per smistare il traffico.

Domande? Curiosità? I commenti sono aperti.

YQL & PHP

Lasciatemi esordire così: che figata pazzesca! Se non avete mai sentito parlare di YQL vi consiglio caldamente di dargli un’occhiata, anche due. Giocate un po’ con la console e restate impressionati dalle 745 “tables” che vengono messe a disposizione gratuitamente. YQL permette di consumare o, volendo, esporre dati utilizzando una sintassi simile all’SQL senza doversi preoccupare di capire come le api di un dato servizio funzionino. Un unico modo per parlare con tutti i maggiori servizi web e creare così altre applicazioni/mashup o semplicemente utilizzare dei dati ignorando completamente ciò che realmente c’è sotto. Va provato per capirne la portata, ho visto gente perdere quasi il senno dopo il talk

Dependency Injection in PHP

Che il concetto di DI sia di una facilità e chiarezza disarmante era ormai chiaro. Molti sicuramente applicano giornalmente la DI anche senza saperlo, farlo con consapevolezza forse sarebbe ancora meglio. Non così semplice il concetto e l’applicazione dei DIC (dependency injection containers), nonostante Fabien habbia mostrato di essere capace di farlo con 40 righe di codice. Ma se la DI è una buona pratica da seguire i DIC vanno presi un po’ più con le molle e non si deve per forza cercare di applicarli ovunque visto che ci sono situazioni in cui è giusto vengano utilizzati mentre in altre occasioni sarebbe sbagliato.

Testare l’ignoto

Michele Orselli e Filippo De Santis, del team di Ideato, parlano di strumenti dedicati al testing funzionale ed unitaro per realizzare un ambiente di test per le proprie necessità. Nello specifico l’esperienza da cui hanno ricavato le informazioni è scaturita dalla necessità di testare eZPublish ricorrendo all’utilizzo di strumenti come Selenium IDE / RC e PHPUnit.

Come sempre conoscere esperienze reali di utilizzo di tecniche di testing, in ambienti eterogenei, è molto interessante. Confrontarsi porta a migliorarsi. Un problema sentito particolarmente, e che più di qualcuno ha evidenziato, è stato forse quello relativo al livello di complessità degli esempi affrontati: introduzione o percorso avanzato? Qualcuno già skillato sull’argomento spera sempre di spingersi oltre ai limiti attuali mentre chi è agli inizi o addirittura non ha mai affrontato l’argomento si augura che qualcuno lo prenda per mano e lo conduca in questo fantastico mondo.

Che sia il caso di trovare nuove forme di analisi per stabilire il livello di un talk coinvolgendo a priori i possibili spettatori? Credo ne scriverò in futuro.

Caching in PHP: get better perfomance for your web applications

Enrico Zimuel di Zend presenta un interessante carellata sugli attuali strumenti di caching presenti nel panorama PHP attraverso uno studio sulle performance che ha condotto personalmente negli ultimi mesi e che dovrebbe vedere la luce tra non molto. Visto l’alto numero di interventi da parte dei presenti non si è riusciti ad analizzare tutti i dati ricavati dallo studio, tuttavia ci si è accorti che APC, XCache e Zend Cache primeggiano su tutti quando si ha a che fare con un’infrastruttura a singola macchina; da valutare separatamente il caso di cluster in cui memcached dovrebbe ripagare ciò che perde in prestazioni grazie al fatto di poter gestire in modo centralizzato i dati per i vari nodi del cluster.

A brevissimo mi troverò ad utilizzare uno di questi prodotti per risolvere un po’ il problema inverso: contatori ad alta concorrenza. Quindi qualcosa che avrebbe bisogno di fare qualche migliaio di scritture al minuto sul db che chiaramente non è uno scenario auspicabile. Scrivere in memoria e ad intervalli recuperare il dato per aggiornare il database è la soluzione ideale. Vi farò sapere.

Building configurable applications for the web – Tom Melendez

Primo talk della giornata dedicato ad un argomento che spesso viene trascurato: configurabilità delle applicazioni. Configurabilità per renderle indipendenti dall’infrastruttura su cui vengono eseguite e per potersi adattare in modo semplice a situazioni poco piacevoli. Se per il primo argomento può venire subito in mente qualche esempio di dati inseriti in modo poco ortodosso (hardcoded), il secondo può sfuggire. Si tratta di poter trarre vantaggio da una serie di accorgimenti per una degradazione pianificata di un servizio: l’esempio portato è stato quello di Yahoo! News nelle cui pagine sono state identificate diverse aree (articolo, letture suggerite, banner…) assegnando loro dei valori in base all’importanza che assumono per il business dell’applicazione. All’occorrenza (picchi di traffico, eventi non pianificati) si dovrebbe poter escludere tale porzione dalla pagina in modo da ridurre l’utilizzo delle risorse necessarie alla pubblicazione della pagina stessa. Quante volte avete “ridotto” la home page di un sito a causa dell’alto traffico? A me è successo, poterlo fare in modo semplice e veloce può rendere le cose molto più semplici…

Indexing the MySQL Index: Guide to Performance Enhancement – Sonali Minocha, Vineet Agrawal

Quando si lavora su piccoli progetti o in piccole aziende non è sempre possibile avere a disposizione un DBA che si occupa di tutte le problematiche relative ai database utilizzati dalle applicazioni su cui si lavora. Molte volte quindi è lo sviluppatore ad avere molto a che fare con il database, anche quando si accusano problemi di performance della base di dati su cui si fa affidamento. Il talk sull’utilizzo corretto degli index è stato molto interessante per me visto che mi ha introdotto ad alcune problematiche che personalmente ignoravo andando più in profondità e presentando strumenti di controllo che se non altro possono darci la possibilità di analizzare e capire quali sono i colli di bottiglia e come risolvere i problemi che ne derivano.

The future of web technologies – Patrick Lauke

Keynote in sala plenaria a cura di Patrick Lauke (Opera) che parla di HTML5 presentando un po’ di novità che già da tempo si vedono nei vari articoli presenti in rete. HTML5 è ciò che aspettiamo tutti noi sviluppatori, per me bastano già le novità relative ai video e per voi? Ciò che più ci si chiede è quanto tempo ci vorrà prima che tutti i player là fuori diano supporto ad HTML5?

Panel su Cloud computing

A causa di o grazie alla cancellazione di un talk per cause di forza maggiore è stato organizzato un panel sul cloud computing, argomento ben presente a questa edizione dell’IPC. E’ stato possibile sentire qualche esperienza diretta dei presenti relativamente all’utilizzo ed alle aspettative riposte nel cloud computing, tuttavia come obiettato da qualcuno pareva più una marketta che qualcosa di tecnico visto che i presenti erano per la maggior parte sviluppatori interessati a tecnicismi piuttosto che a nomi…

Validating XML – Avoiding the pain – Arne Blankerts, Tobias Schlitt

Qualche prova live durante il talk per l’utilizzo di DTD, XML Schema e RelaxNG per la validazione degli XML non solo parlando di risultati. Qualcosa che non incontro spesso e che può tornare utile nell’ottica di distribuzione dati tramite XML. Qualche problema con l’IDE che non ha permesso di vedere tutti gli esempi, peccato.

Symfony Components: What’s in for you? – Fabien Potencier

Interessante panoramica sui components di symfony da parte di Fabien Potencier, ogni esempio supportato da del codice esemplificativo. Stranamente poche persone a seguire il talk ma nello stesso tempo negli altri canali erano attivi relatori molto interessanti specialmente in lingua tedesca…

Si chiude la giornata al centro congressi con un buffet / aperitivo con “free beer” e possibilità di networking. Vista la scarsa partecipazione abbiamo poi deciso di uscire a cena con Fabien Potencier come ospite d’onore: due italiani (io e Francesco Fullone), un norvegese (Morten Amundsen) e un francese (Fabien Potencier)…no non è una barzelletta!

Web Application Architecture – Stefan Priebsch
Si apre subito a tutta velocità con il talk sull’architettura delle applicazioni web. Ci si vuole concentrare sull’importanta che tali decisioni hanno nella fase di progettazione di un’applicazione e sull’impatto che hanno sul prodotto stesso. Il paragone è con l’architettura strutturale di chiese, campanili, ponti…insomma entità di un certo calibro. La differenza sostanziale è che nel software è piuttosto “semplice” sostituire intere porzioni di architettura (avendo scritto tutti i test del caso) senza far crollare tutto come potrebbe capitare sostituento le fondamenta della
torre di Pisa…

NetBeans IDE – The choice for PHP development – Petr Pisl
Novità relative alla versione 6.8 di NetBeans che da qualche tempo utilizzo in versione beta del nightly builds. Il rilascio è fissato per il 10 dicembre. Tra tutte le novità il supporto per symfony è ciò che principalmente mi interessa visto che sono passato da Zend Studio For Eclipse (utilizzato brevemente) a NetBeans principalmente per il framework francese. Lanciare i comandi dell’ide invece che dalla shell, interrogare direttamente i database senza utilizzare un altro client, avere pieno supporto a PHP5.3…insomma tutto ciò di cui si può avere bisogno ad un prezzo contenuto in termini di ram e cpu. Mi devo informare se è possibile ottenere l’integrazione per il code coverage con Lime come già presente per PHPUnit.

PHP in the Cloud – Ralph Schindler
Keynote a cura di Schindler (Zend Technologies) che argomenta su alcuni temi che di sicuro riguarderanno il futuro dell’ecosistema che gravita attorno a PHP: NoSQL, Cloud…alcuni argomenti prenderanno piede prima di altri, che magari non riusciranno a fare breccia tra gli sviluppatori e le aziende. Personalmente vedo il cloud già come il presente, per il NoSQL credo ci si debba perdere qualche tempo e toccare con mano…

Building real-time Applications with XMPP – Travis Swicegood
Questo forse il talk da cui ci si aspettava di più per sporcarsi le mani con un po’ di codice senza restare tanto sul teorico. La presentazione è sembrata proprio un’introduzione all’argomento, cosa che ad una conferenza del genere si dovrebbe dare per scontata. Non tanto perchè tutti devono sapere tutto ma perchè in grado di documentarsi da soli sulle basi…

Towards the Cloud: Event-driven Architectures in PHP – Benjamin Eberlei
Disaccoppiare i componenti delle applicazioni per riuscire a scalare meglio ed avere più flessibilità nell’utilizzo di nuove risorse come il cloud. Per fare questo viene presentata una tecnica di progettazione architetturale che si basa sugli eventi per scatenare le azioni da eseguire (in symfony event dispatcher vi dice qualcosa vero?) piuttosto che ricorrere a soluzioni come i cron che sono single threaded, possono ritardare fino ad un minuto l’esecuzione di qualcosa (ricordo che con i cron il minuti è la misura più piccola), in alcuni casi piuttosto difficile in termini di scalabilità. Spunto interessante per un progetto su cui sto lavorando proprio in questo periodo nel quale effettivamente qualche evento potrebbe proprio rimpiazzare dei cron jobs…da valutare attentamente.

Nell’insieme una giornata positiva. A domani per la seconda puntata!

An introduction to MapReduce – David Zülke

Eravamo decisamente in pochi, una decina occhio e croce. Argomento che inizialmente pare lontano: gestire grandi quantità di dati per ricavare informazioni aggregate. E quando si parla di grandi quantità si portano esempi come Facebook, Yahoo! et simili con ordini di grandezza di PB.

Non è il mio caso potreste pensare, un po’ come ho fatto io inizialmente, salvo ricredermi quando ho messo a fuoco l’argomento sotto un altro punto di vista come per esempio l’analisi dei log del webserver per un grosso sito.

Personalmente ho avuto modo di mettere in pratica qualcosa che ignoravo: eseguire delle operazioni in due fasi distinte di mapping e poi di reduce per ottenere dati specifici partendo da una grande quantità di dati che presi in maniera grezza non danno un grosso valore.

Per un grosso cliente m’è capitato proprio di dover fare in modo che ogni ora i log creati dal webserver venissero utilizzati per ricavare il numero di impression generate da ogni banner presente sulle pagine del suo sito. Elaborare all’incirca 200MB di log ogni ora non è come lavorare con ordini dei PB ma inizia ad essere un’attività piuttosto time consuming quando da qualche decina o centinaia di migliaia di righe vogliamo ottenere una manciata di numeri.

Gli esempi presentati e le idee proposte forse mi permetteranno di migliorare questo compito: voto 8.

Scrum – Just do it! – Sebastian Schürmann, Dominik Jungowski

Agile non è solo XP, esistono vari filoni che mettono in pratica il manifesto agile e avere una visione più completa anche sulle altre metodologie non fa di certo male. Il workshop mi ricorda molto quello ormai collaudatissimo che Jacopo Romei e Francesco Trucchia propongono con grande successo e che seguo sempre volentieri in Italia. Anche qui è una coppia coach-developer a tenere il talk da quanto mi pare di capire, uno più tecnico e l’altro più dedito al management dei team ed al coaching.

Interessante il gioco della palla in team per simulare l’evoluzione delle stime del team stesso e di come in poche iterazioni si riesca a raffinare la decisione finale per rispondere in modo corretto ad una certa project velocity.

Proposta anche qui la partita a carte per il game planning, non si parla di XP o Scrum ma di Agile. Le affinità sono molte, per lunghi tratti le cose sono coincidenti, per molti altri le differenze sono poche. L’idea di fondo è solo una, il manifesto agile, metterlo in pratica correttamente non permette di allontanarsi molto ipotizzando soluzioni “creative”. Ecco quindi che nascono le affinità.

Ognuno è poi libero di crearsi il metodo che meglio si adatta ai propri clienti ed al proprio mercato, allargare le vedute è fondamentale: voto 8.

Sul suo blog Potencier ha espresso un po’ di idee sullo stato attuale dell’arte in termini di template engine paragonando ciò che la rete offre, ha anche pubblicato alcuni test comparativi delle performance dei vari prodotti. Risultato: poco meno di 90 commenti in nemmeno una settimana ed un post in risposta da parte di Eli White che solleva alcuni dubbi. Il cerchio si chiude con la risposta di Potencier in un altro post. Consiglio la lettura dei post e di tutti i commenti visto che ci sono degli spunti davvero interessanti su cui non voglio soffermarmi al momento.

Quello di cui vorrei parlare è ad un livello un po’ più alto: template engine si o no?

Personalmente negli ultimi anni ho sviluppato applicazioni con un framework, sviluppato internamente dall’azienda per cui lavoro, basato su Smarty per la creazione dei template. Da quando ho iniziato ad usare symfony, che ricordo è un MVC, mi sono sempre chiesto se mi mancasse davvero Smarty visto che i template si realizzano direttamente in PHP.

La risposta non la so ancora dare, posso tuttavia esprimere dei pareri sulle due strade che si possono seguire:

PHP

• creare i template direttamente in PHP evita di aggiungere un ulteriore layer al tutto
• non si deve imparare un altro linguaggio (per semplice che sia)
• permette più libertà (con attenzione)

TEMPLATE ENGINE

• rende più leggibili i template, specialmente quelli più complessi
• rende più accessibili, in termini di manutenzione, i template anche ai non sviluppatori
• aiuta ad essere più aderenti al design pattern MVC

Quello che più è importante secondo me, che si usi PHP od un template engine, è fare in modo che nella vista (V, di MVC) ci si limiti a presentare i dati e non ad elaborarli. PHP è uno strumento potente più del necessario per “mostrare” dei dati, va usato nel modo giusto. Un template engine dal canto suo, più scarno e povero di funzioni, potrebbe aiutare in tal senso a patto che non lo si vada ad estendere con mille plugin sviluppati ad hoc per tutte le occorrenze. A quel punto tanto vale restare con PHP…

E voi come agite? Quali sono le vostre esperienze in merito?

In questa serie di articoli voglio condividere vari aspetti tecnici delle fasi di migrazione di un grosso sito web come Estatica (enciclopedia di musica italiana), all’utilizzo del framework open source PHP Symfony.

La serie è potenzialmente molto interessante visto che potrebbe affrontare molti di quei problemi che lo sviluppatore può incontrare durante la migrazione di un’applicazione già esistente. Buona lettura!

24hrsCamp è un evento di 24 ore che mira alla realizzazione concreta di un progetto umanitario. Si terra’ a Milano il sabato 15 e domenica 16 Novembre ed e’ alla ricerca di sviluppatori PHP ma non solo! 24hrsCamp, nato dalle frustrazioni, dalle delusioni e dalle speranze infrante della vita lavorativa di tutti i giorni, si propone di realizzare qualcosa.

Come? Attraverso eventi di 24 ore, in cui chiunque può partecipare e dare il proprio contributo. Ognuno di noi è portatore di idee, conoscenza, metodi e procedure che, per qualche motivo, non riesce a concretizzare. Il nostro obiettivo, ambizioso, è di organizzare eventi dove lasciarsi alle spalle tutto questo! 24 ore per progettare, al termine delle quali si chiude un progetto e lo si consegna alla comunità Internet.

Il nostro obiettivo è quello di creare un nuovo format di evento che superi i normali limiti del puro brainstorming e cerchi di capire quanto sia possibile progettare e fare in un arco di tempo delle 24 ore. Non pensate solo ad un idea per tecnici, in realtà il nostro desiderio sarebbe quello di vedere in atto un esperimento pluridisciplinare.

Maggiori informazioni sul sito ufficiale: http://24hrscamp.org/?page_id=3