L'80% in più di performance con PHP, parola di Facebook

[Redazione HostingTalk]

Nulla di nuovo in casa Facebook, la compagnia ci starebbe lavorando da un paio di anni, ma sicuramente un passo avanti curioso per il mondo degli sviluppatori PHP possono ora avere una versione compilata del famoso linguaggio di scripting. Dopo aver ottimizzato i propri server e aver optato per la realizzazione di un proprio data center, il passo successivo, come preannunciato anche nell'intervista segnalata sul nostro blog, è quello di aumentare le performance del software che permette il funzionamento di Facebook.



Leggi L'80% in più di performance con PHP, parola di Facebook

[Ste]

Direi un esempio interessante di come ad un certo punto non basti più solamente aggiungere server ma si debba prevedere una soluzione diversa. Da quel che si può leggere era una cosa prevista già da 2 anni, per cui un progetto di lunga durata, e in previsione già della crescita odierna di Facebook, da capire come mai non abbiano pensato di adottare un linguaggio diverso, probabilmente per il discorso sviluppatori e piattaforma annessa?

[Antonio]

da capire come mai non abbiano pensato di adottare un linguaggio diverso, probabilmente per il discorso sviluppatori e piattaforma annessa?

Azzardo una ipotesi: avendo attualmente una applicazione che tutto sommato fa il suo dovere e gira su migliaia di server già con diversi accorgimenti particolari, si saranno resi conto che rifare tutto in un altro linguaggio non sarebbe stato conveniente; i frutti si sarebbero avuti a distanze di svariati mesi, si sarebbe dovuta fare una lunga fase di beta test e la reingegnerizzazione dell'infrastruttura per poter usare al meglio il nuovo sw.

Senza contare che andando ad ottimizzare direttamente un componente dell'infrastruttura attuale hai anche la possibilità di poter implementare a step le migliorie man mano che vengono scritte e, quindi, poter usufruire da subito del lavoro dei developer

Poi come dice il detto: non cambiare mai la strada vecchia per quella nuova, si sa cosa si lascia non si sa cosa si trova

[Uno]

Sinceramente o non ho capito qualcosa io o hanno infiocchettato per bene una cosa relativamente banale.
Non capisco il diagramma del passaggio dal php al C++ (lo capisco, ma non ne capisco il senso)

Potrebbero/dovrebbero semplicemente riscrivere tutto l'applicativo in c++ (o quel che gli pare) mantenendo la base di dati.
Penso che un buon sviluppatore in pochi mesi ne poteva uscire vittorioso.
A prima lettura pareva che volessero "semplicemente" compilare l'applicativo php già esistente, cosa che avrebbe anche avuto un senso se ci fosse un compilatore decente già pronto, ma fare tutti quei passaggi non ha senso, almeno per me.

[Uno]

Azzardo una ipotesi: avendo attualmente una applicazione che tutto sommato fa il suo dovere e gira su migliaia di server già con diversi accorgimenti particolari, si saranno resi conto che rifare tutto in un altro linguaggio non sarebbe stato conveniente; i frutti si sarebbero avuti a distanze di svariati mesi, si sarebbe dovuta fare una lunga fase di beta test e la reingegnerizzazione dell'infrastruttura per poter usare al meglio il nuovo sw.

Senza contare che andando ad ottimizzare direttamente un componente dell'infrastruttura attuale hai anche la possibilità di poter implementare a step le migliorie man mano che vengono scritte e, quindi, poter usufruire da subito del lavoro dei developer

Poi come dice il detto: non cambiare mai la strada vecchia per quella nuova, si sa cosa si lascia non si sa cosa si trova

Se non la smetti di infilarti mentre scrivo ti banno
Per me facevano comunque prima a riscrivere tutto. Forse non conosco (sicuramente, l'ho aperto solo un paio di volte per sbaglio) facebook ma mi pare piuttosto semplice come interfaccia e conseguente engine.

[Rebel]

mha, mi pare di capire che dato che PHP lo imparano ad usare anche le scimmie in 10 minuti, hanno preferito creare un applicativo che riscrive in C++ il codice PHP piuttosto che migrare verso un altro linguaggio completamente.

[Ste]

mha, mi pare di capire che dato che PHP lo imparano ad usare anche le scimmie in 10 minuti, hanno preferito creare un applicativo che riscrive in C++ il codice PHP piuttosto che migrare verso un altro linguaggio completamente.

Esatto, quel che è da pensare è che abbiano scelto di continuare con PHP perchè è un linguaggio semplice e consente a tutti di scrivere applicazioni basate sulla loro piattaforma e di conseguenza aumentare "il giro" su facebook

[Antonio]

Esatto, quel che è da pensare è che abbiano scelto di continuare con PHP perchè è un linguaggio semplice e consente a tutti di scrivere applicazioni basate sulla loro piattaforma e di conseguenza aumentare "il giro" su facebook

Un attimo, calma e gesso, cosa centrano le applicazioni esterne a facebook con l'applicativo su cui gira facebook stesso?

Basta mantenere l'interfaccia e rivoluzionare l'implementazione dei metodi sottostanti ed i dev esterni non se ne accorgono neanche delle modifiche.

[Ste]

Vero, ma sono ulteriori modifiche che probabilmente hanno poi un costo, anche in termini di performance, più alto. Ora cerco qualcosa di approfondito, dato che dovrebbero aver rilasciato tutto e vediamo di cosa si tratta.

[Rebel]

Comunque e' molto interessante come cosa. Peccato che il link al codice presente nell'articolo non funzioni.

[andrea.paiola]

da capire come mai non abbiano pensato di adottare un linguaggio diverso, probabilmente per il discorso sviluppatori e piattaforma annessa?

eh eh ti ricordi quando scrivevo di fare un'analisi preventiva?
http://www.hostingtalk.it/forum/shar...tml#post105661

[usu]

In effetti, a prescindere dal discorso convenienza di fb, se questo sistema nei mesi (anni?) a venire si evolvesse in modo tale da supportare la (quasi) totalità di funzioni ed estensioni di php sarebbe una gran bella cosa.
Vi porto la mia esperienza, ormai è proprio php a consumare la maggior parte delle risorse sul server di itasa (joomla + smf) dato il pesante caching eseguito e le tantissime ottimizzazioni lato codice/db/webserver.

Percentuali in termini di CPU:

php-cgi (33) 202.8%, mysqld (1) 57.6%, memcached (2) 4.6%, nginx (13) 1.2%, (other) (56) 0.3%

Il tutto su un totale di 800% (dual xeon quad core) dimezzare l'uso di CPU significherebbe comunque moltissimo, per non parlare della velocità di apertura di una pagina

[Kuro]

Il tutto su un totale di 800% (dual xeon quad core) dimezzare l'uso di CPU significherebbe comunque moltissimo, per non parlare della velocità di apertura di una pagina

la tua esperienza è leggermente diversa da fb, loro utilizzano applicativi php ad-hoc e che, per forza di cose, sono già il massimo dell'ottimizzazione da quel lato.
Probabilmente se ti sviluppassi una piattaforma tua, avresti un incremento delle performance non indifferente.

[Rebel]

In effetti, a prescindere dal discorso convenienza di fb, se questo sistema nei mesi (anni?) a venire si evolvesse in modo tale da supportare la (quasi) totalità di funzioni ed estensioni di php sarebbe una gran bella cosa.
Vi porto la mia esperienza, ormai è proprio php a consumare la maggior parte delle risorse sul server di itasa (joomla + smf) dato il pesante caching eseguito e le tantissime ottimizzazioni lato codice/db/webserver.

Percentuali in termini di CPU:

php-cgi (33) 202.8%, mysqld (1) 57.6%, memcached (2) 4.6%, nginx (13) 1.2%, (other) (56) 0.3%

Il tutto su un totale di 800% (dual xeon quad core) dimezzare l'uso di CPU significherebbe comunque moltissimo, per non parlare della velocità di apertura di una pagina

Potresti dimezzare il load se in Italia, nelle scuole, iniziassero ad insegnare un inglese decente.

[andrea.paiola]

PHP comunque rimane il linguaggio Web con più sviluppatori a prezzi contenuti, percui non è detto che facendo due conti non convenga comunque