Alcuni numeri su Php e framework

[Uno]

Paul M. Jones Blog Archive Labor Day Benchmarks è un pò vecchiotto (fine 2008) ma ritengo che sia ancora interessante.
Il lavoro di benchmarking svolto da Paul ci mostra come da una pagina in html se parsiamo lo stesso contenuto, il classico Hello World!, in php quasi raddoppiamo i tempi che poi inevitabilmente aumenteranno utilizzando un framework.
Ai tempi di questo lavoro i framework migliori (da questo punto di vista) erano codeigniter e solar, sarebbe interessante aggiornare i test, ma io in questo periodo non ho tempo.

[andrea.paiola]

l'utilità?

[Uno]

Aiutarci nello scegliere in base alle esigenze?

[Uno]

Qui ci sono altri test PHP framework comparison benchmarks AVNet Labs purtroppo vecchiotti pure questi ma in linea con gli altri. Questi sono interessanti perchè prendono anche in considerazioni cache lato server.

[Uno]

Girovagando in cerca di info su alcuni aspetti che mi interessano mi sono imbattuto in PHPulse (PHPulse.com - PHPULSE) che mi ha dato informazioni preziose.
Interessanti i benchmark (PHPulse.com - BENCHMARKS) che mostrano come brucia sulla velocità alcuni tra i principali concorrenti, per quanto, come loro stessi scrivono non si può fare affidamento al 100% su dei semplici test le indicazioni sembrano comunque incontrovertibili.
In un gruppo che comprende CodeIgniter, Symfony, CakePHP è il più scalabile per siti ad alto traffico. Tant'è che sono arrivato a trovarlo per un riferimento ad un suo uso da parte di telecom Messicana su una applicazione per cellulari con un db di 10TB e centinaia di clienti contemporanei.

Quello che mi ha più interessato è però l'architettura che da quello che ho rapidamente capito (ho scaricato i sorgenti per "studiarli", anche se probabilmente non lo userò per la licenza ed altre cosette che non mi soddisfano) poggia controller, viste e modelli interamente sul db, qualcosa di simile a ciò che vorrei fare io.

Se si studia bene il db la cosa ha innumerevoli vantaggi, ora al volo posso fare solo un esempio. Se ho viste, modelli e controller su file system, normalmente si apre la pagina per poi magari scoprire che l'utente non ha i permessi per vederla, quindi bisogna caricare un'altra pagina per indicare la cosa. Se gestisco tutto a livello di db controllati i permessi carico direttamente la pagina giusta.
A conti fatti parrebbe da diversi test che una singola pagina caricata con query semplice da db sia più veloce dell'apertura di un file su filesystem, poi ovviamente ci sono casi e casi, e a prima vista potrebbe sembrare che numeri con tanti zeri davanti non valgano la pena di sbattersi o di caricare il db... ma se ragioniamo sulla scalabilità l'evidenza dei fatti sembrerebbe dare ragione ad uno studio del genere.
Se prendiamo per buoni i benchmark proposti da phpulse superato un certo carico di richieste i principali framework in sostanza si piantano
"As you can see, during a heavy spike in traffic, only PHPulse can can continue to fulfill requests while all the other frameworks start dropping requests, dieing and timing out; we could not get a single one of them to complete. This shows not only PHPulses speed but it's ability to scale beyond the ability of other frameworks."

[andrea.paiola]

penso siano molto più importante le funzionalità offerte, la documentazione, la facilità di uso e modifica, la comunità degli utenti, gli aggiornamenti del software e la licenza che la mera "velocità"

numeri con tanti zeri davanti non valgano la pena di sbattersi o di caricare il db... ma se ragioniamo sulla scalabilità l'evidenza dei fatti sembrerebbe dare ragione ad uno studio del genere.

purtroppo richiede MySQL... non è proprio il massimo per la scalabilità... pradossalmente è più facile avere una CDN per i file che un MySQL scalabile...

poi dipende da quanto materiale vuoi mettere sul sito, ma MySQL rende bene solo se sta in ram... quindi il limite della grandezza del sito è presto detto... ammesso che il db sia progettato e "riempito" a regola d'arte eh

ps: nei test non c'è Zend Framework? che dovrebbe essere quello di riferimento...

[Uno]

Un momento Andrea, non ho scritto che PHPulse sia il migliore framework (come impostazione di diverse cose non mi piace), ho scritto che se i dati sono reali hanno testato qualcosa che già pensavo.

La velocità potrebbe essere ininfluente su un piccolo sito (dove per piccolo intendo anche qualche migliaio di utenti unici giornalieri) ma su un sito grande, se non vuoi aggiungere server in continuazione, è fondamentale per poter servire più clienti.

Questo framework è stato testato con 10TB di db (non credo che li abbiano messi tutti in ram, poi può essere) e centinaia di clienti contemporanei, mi sembrano cifre di tutto rispetto, poi è ovvio che un facebook, un ebay e simili hanno bisogno di ben di più di un framework php (anche il sito dell'esempio della telecom era sicuramente su uno o più server ben ottimizzati, mica su shared hosting, di questo ne sono certo anche senza avere dati in mano).
Il concetto di tutta la struttura del sito nel db è slegato da Mysql (lascia perdere l'esempio di questo framework), penso che si ottengano risultati simili (diversi, ma tendenti alle stesse evidenze) anche con altri dbms, sarei pronto a scommettere perfino su sqlite.

[ceccus]

Salve,
Mi trovo d'accordo con Uno ... nel senso che quando si hanno centinaia se non migliaia di "accessi" da servire in contemporanea (o quasi) , la velocità di esecuzione è tutto ... e quando dico tutto ... è tutto.
Un fattore da non sottovalutare assolutamente è COME viene acceduto il DB ... nel senso che più si riescono a parallelizzare gli accessi (e con accessi intendo letture/scritture) e più l' applicazione risulterà scalabile in senso orizzontale ... ed è questo quello che chiedono le aziende ... mica si può cambiare l' Hardware ogni anno ... solitamente gli investimenti sono a 3 anni ...
Per il discorso "permission" ... francamente sono un po' scettico ad inserirle in un contesto DB ... solitamente le autorizzazioni, in grandi aziende , stanno in Directory particolari, per esempio Active Directory ... o strutture di tipo LDAP ...

Ciao !!

[Uno]

Per il discorso "permission" ... francamente sono un po' scettico ad inserirle in un contesto DB ... solitamente le autorizzazioni, in grandi aziende , stanno in Directory particolari, per esempio Active Directory ... o strutture di tipo LDAP ...

Si questo è sacrosanto , qui stavo valutando (e l'esempio era solo uno degli esempi possibili) l'uso di/su un prodotto finale unico, vedi cms, ecommerce etc, che possa essere installato anche su shared.
E qui torniamo alla base del ragionamento, anche uno stupido blog se inizia ad essere visto da tanta gente necessita di upgrade in continuo se non è ottimizzato. Facciamo l'esempio wordpress?
Quindi se sopra ho detto che per il sitino da un migliaio di utenti die, può essere ininfluente la velocità dobbiamo pure però essere sicuri che mai quel traffico aumenterà perchè magari è un sito di nicchia che ci va bene così. In qualsiasi altro caso avere un prodotto software che lavora bene non può che essere un vantaggio.
Se poi facciamo il discorso da parte dello sviluppatore (che spesso non è neanche sviluppatore, ma poco più che un installatore) è logico che conviene più avere il framework che fa di tutto e di più, che magari ha anche widget per le view. Ma questo dal punto di vista prestazionale è quasi sempre un handicap.

Dimenticavo, Zend Framework è robusto, ha molte funzioni e copre diversi range ma sempre di più sto scoprendo che è il wordpress dei framework, ti fa pure il caffè ma non è una caffettiera. E' migliorato nelle ultime versioni come prestazioni, ma non è sicuramente uno dei più leggeri. Quindi a chi piace, se deve sviluppare siti di diverso tipo ma mai con ambizioni di crescita oltre un certo limite potrei dire che può essere perfetto (dipende dai gusti). Ma per progetti ambiziosi non lo trovo la giusta scelta...

[andrea.paiola]

se la velocità fosse "tutto" non si userebbero linguaggi di programmazione interpretati...

è più importante che la piattaforma scali senza problemi orizzontalmente ( anche per questioni di rindondanza per aumentare la disponibilità del servizio e diminuire i rischi )




farlo con postgresql a quanto ho capito è molto meno problematico...

per esempio tra le caratteristiche che considero fondamentali in un framework c'è almeno un layer di astrazione dal database, che permette di cambiare facilmente...

[andrea.paiola]

tra l'altro sto benchmark PHPulse.com - BENCHMARKS è ridicolo: non scrivono neanche cosa fa la pagina ( le pagine? ) su cui hanno sguinzagliato ab...

[ceccus]

Salve,

se la velocità fosse "tutto" non si userebbero linguaggi di programmazione interpretati...

Beh ... un po' "rischiosa" come affermazione ... in ogni caso, in applicazioni "mission critical" , la velocità di elaborazione è tutto ... e anche in applicazioni non Mission Critical, tipo un esecuzione di un ordine di borsa ... la velocità è TUTTO ... perchè se il cliente ti chiede di fare l' ordine di borsa in quel momento ... te lo DEVI fare in quel momento ... e non dopo ... ovviamente, in quel momento è compreso un lasso di tempo molto piccolo (millisecondi) ...
Poi, ovviamente, la "robustezza" e il grado di scalabilità di un DB , e se mi permettete , anche dell' Application Server è fondamentale ... il "presentation" , da questo punto di vista, è molto meno problematico ...

Ciao !!

[andrea.paiola]

non è vero che nelle applicazioni "mission critical" la velocità di elaborazione è tutto... per definizione l'unica cosa che è "tutto" è raggiungere l'obiettivo... esistono casi in cui i tempi di elaborazione sono fondamentali e altri casi in cui vengono molto prima molte altre cose: ti confondi con le applicazioni real-time, in cui è fondamentale avere un output con un vincolo temporale

[ceccus]

Salve,
Mi sembra di aver fatto un esempio poco sopra ... di applicazione Mission Critical ... il cui tempo di esecuzione è fondamentale ... se non la pensi così ... beh ... che ti devo dire ... di sicuro non "giocare" in borsa ...
Non a caso, invece, non ho fatto l' esempio "classico" di applicazione "real time" , ovvero quello che fanno ad ogni "convention" dove si parla di "real time" ... ovvero l' esempio di software che sovraintende alla gestione delle valvole di reflusso di una centrale nucleare ... che , ovviamente, devono essere bloccate , in caso di necessità , con tempi di reazione "real time" ... c'è un S.O. che è certificato Real Time ... e che nessuno, ma proprio nessuno, si aspetterebbe che lo fosse ........... ... e che è basato , appunto, su di un Framework ... quindi, interpretato ...
In ogni caso, concordo sul fatto che è difficile massimizzare ... ogni applicazione va vista a sè stante , perchè poi, il confine, si sposta, appunto fra il framework utilizzato e come l' applicazione stessa lo utilizza.

Ciao !!

[Uno]

se la velocità fosse "tutto" non si userebbero linguaggi di programmazione interpretati...

Si usano linguaggi interpretati in applicazioni (come quelle comuni web) che evolvono spesso nel tempo e che da una base comune si specializzano in vari settori.
Gli sviluppatori necessitano di modifiche veloci, parziali etc... quindi è decisamente più complicato sviluppare in linguaggi complilati. Comunque ci sono cms in C o misti C e php... ma per i motivi che ho appena detto non sono molto usati neanche dove serve scalabilità.
Comunque una pessima applicazione in linguaggio compilato è più lenta di una codata bene in linguaggio interpretato. Senza interfaccia grafica (di quella si occupa in ogni caso html nel web) non è che ci sia tutta questa differenza tra compilato ed interpretato. Sui desktop una volta con i pc meno performanti era un must compilare per avere applicazioni decentemente performanti.

per esempio tra le caratteristiche che considero fondamentali in un framework c'è almeno un layer di astrazione dal database, che permette di cambiare facilmente...

Questo pure io anche se magari non lo userò mai per cambiare dbms.

tra l'altro sto benchmark PHPulse.com - BENCHMARKS è ridicolo: non scrivono neanche cosa fa la pagina ( le pagine? ) su cui hanno sguinzagliato ab...

Te lo dicono quando scrivono perchè hanno escluso Zend, la pagina di default. Il test è ovviamente spannometrico, lo dicono loro per primi, ma se già sull'index del framework ci sono quelle differenze enormi la cosa mi fa pensare. Poi magari potrebbe essere che caricando dati ed interazione le cose cambino, ma mi risulta difficile che si invertano i risultati.

non è vero che nelle applicazioni "mission critical" la velocità di elaborazione è tutto... per definizione l'unica cosa che è "tutto" è raggiungere l'obiettivo... esistono casi in cui i tempi di elaborazione sono fondamentali e altri casi in cui vengono molto prima molte altre cose: ti confondi con le applicazioni real-time, in cui è fondamentale avere un output con un vincolo temporale

Oddio se parliamo di web sono tutte applicazioni real-time. Se l'utente si collega al sito e questo non si apre addio.... se è un utente abituale ci riprova, purchè non succeda in continuazione a meno che tu non regali soldi sul sito