Ne m’en parle pas. Notre cellule sécurité tombe tous les jours sur des XSS et des SQL injections triviales. C’est dramatique, on en a aussi dans Magento que nous n’avons pas releasé car elles sont en correction chez Varien…

Certes le C n’est pas en disparition lui même, mais côté appli web, on en voit de moins en moins. Ca se limite aux modules/bibliothèques et rarement à l’applicatif.

Après sur les XSS, je désespère à chaque fois que je lis le code de tiers, mais cela tient plus à une culture qu’au langage. Des mauvais développeurs C il y en a aussi et les résultats peuvent être bien plus dramatiques.

“”"Sans parler de jeter PHP, visiblement sans trop modifier le langage, on peut arriver à le rendre “compilable”, ce qui déjà est un gain. On va tester mais je pense que ca ira bien au delà des 5% que tu annonce et d’un grand facteur. “”"

Attention, je ne parle pas de 5% du CPU mais 5% du temps de chargement de la page (images, javascript, html, réseau, tout compris)

Ceci dit, 50% ca reste un gain très alléchant. J’espère qu’on pourra faire un solide benchmark prochainement de ces questions.

On a des stats assez différentes visiblement sur ce qui charge les machines. Les I/O disk sont négligeables (all to ram) pour nous, les I/O réseau également, l’OS tiens dans très peu de CPU, nos frontaux sont donc des machines à loop sur de l’apache / mod_php et des opcode optimizers. 90% + du temps CPU en fait.

Sans parler de jeter PHP, visiblement sans trop modifier le langage, on peut arriver à le rendre “compilable”, ce qui déjà est un gain. On va tester mais je pense que ca ira bien au delà des 5% que tu annonce et d’un grand facteur.

Quand au C, il n’est pas en voie d’abandon à mon sens. Avec ses moutures, C++, C#, il reste la composante principale de tous les OS et d’une grande part de l’opensource (qui ne se réduit pas au paradigme LAMP). Ruby, Python et Java ont pu voir le jour car les ressources augmentait et effectivement le ratio temps de dev / vitesse d’execution dont tu parlais a fait basculer vers le développement plus facile. Il y a moyen de ne pas régresser sur les deux plans. Hip hop va dans ce sens. Peut être aurons nous d’ailleurs de nouveaux langages dans quelques années.

Quand au temps passé sur des algos d’optimisation apprenait au moins quelques bases dont tout le monde se fout maintenant. Le C m’a appris à penser à mon code avant de le jeter dans un fichier. Les XSS à profusions que l’on voit, c’était du non controle des entrées dont on se préoccupais bien plus il y a 10 ans pour éviter des buffers overflows. Quand au C++/C#, il reste bien loin du processeur dans sa syntaxe et très proche une fois compilé, mais effectivement, il est fortement typé et il faut gérer ses allocations de RAM, en fait savoir ce que l’on manipule.

Ceci étant, merci de ta participation, c’est un débat et visiblement on est maintenant plus sur des opinions que sur des faits tangibles.

Je t’invite à participer avec nous à un benchmark de tout cela, avec hardware, soft, ingénieurs et tout ce qu’on a en expérience des deux cotés pour fournir des réponses factuelles, scientifiques et statistiques à nos questions sur le domaine et surtout à la communauté.

Mais surtout je m’adresse à ton affirmation sur le fait que les fichiers sont relus et réintéerprétés à chaque exécution. Sauf à se passer de APC, e-accelerator et autres équivalents, ce n’est plus le cas. Et parler performance sans même installer ça serait vraiment étrange.
L’opcode est en mémoire, PHP aussi, les seules “relectures” qui restent ce sont les check de date de fichier au cas où ils ont changé (et même ça c’est désactivable).

Bref, l’état de l’art est bien moins désastreux que ce que ton billet sous-entend.

Après je crains que tu ne surestimes beaucoup l’effet de la compilation. Hip Hop, en réécrivant les interfaces des modules, en transposant en C++ qui compile, ne gagne que 50%. On est loin du rapport 1 à 10 que tu imagines. C’est pour ça que je te parlais de dynamique faiblement typé. Le principe même est complexe, qu’on soit en compilé ou pas.

Après les 50% de Facebook c’est avec des bons développeurs, des systèmes de données dédiés, etc. Pour un site sérieux avec des développeurs pas mauvais le temps pris par les exécutions c’est de l’I/O disque, du SGBDR, des variables d’environnement, des modules tiers bof-bof, etc. Je m’attends à avoir des statistiques bien moins glorieuses sur la plupart des configurations (même pour des développeurs qui se jugent “bons”).

Alors certes on peut retirer le typage faible, trouver un moyen de passer par un compulateur, corriger la liaison entre le serveur web et PHP pour se passer du FastCGI, mais au final on va retrouver les segfault, un confort bien moins grand … quel intérêt de rester avec PHP alors ?

Vu que la force de PHP ce n’est certainement pas sa syntaxe (beurk), ou la cohérence de sa lib standard (beurk x2), autant aller directement sur du C++ ou au moins sur du Java ou du .Net qui ont des VMs qui tournent bien mieux que PHP. Ca fonctionne déjà

Reste après que malheureusement le goulot d’étranglement sur le web ce n’est pas PHP, loin de là. Sur un site classique la page PHP représente moins de 10% du temps de chargement. Optimiser 50% de 10% (donc 5% au final) en tuant tout le confort qui est justement l’avantage de PHP, je ne suis pas convaincu. Ca peut être valable pour certains cas de Facebook mais sinon …

Pour moi ce serait faire l’évolution inverse de toute l’informatique qui a abandonné l’assembleur pour du C, puis abandonné le C pour les langages sur la JVM ou la CLR, et maintenant se penche encore plus sur les langages de scripts comme PHP ruby ou python. Ce n’est pas pour rien, c’est que sauf cas exceptionnels le temps perdu en allant plus près du processeur c’est du temps sur lequel on ne travaille pas l’archi, le réseau, les algos … et qu’au final on ne s’y retrouve pas vraiment.

Actuellement, nos machines ne swap pas, n’utilise quasi par leurs disques, elles utilisent du CPU. 90% de celui-ci est dédié à PHP, le reste étant du apache et des gestions de requêtes ou de l’OS. Actuellement c’est vraiment les seuls processus qui consomment et ils consomment réellement du CPU, peut importe que l’on ait Zend ou APC.

Merci pour ton post sur typepad au sujet de hip hop.

Déjà, même si l’on ne parle que de 50%, ca vaut le coup ! C’est énorme comme gain. Bon visiblement, ce n’est pas gagné car il y a des limites à prendre en compte, des choses à tester et avant que Zend ou Varien certifie le produit dessus… On peut attendre mais le chemin est le bon je crois.

Quand à Apache, effectivement c’est un fat_boy. Il est temps de composer avec les alternatives et que celles-ci montent en puissance. Le libre a encore des pas à faire dans ce domaine. Zeus est très puissant mais payant et nginx n’est pas encore assez supporté (notamment par Zend), les initiatives fleurissent mais ont du mal à se débarrasser du grand père.

“PHP 4 introduced the the Zend engine. This engine splits the processing of PHP code into several phases. The first phase parses PHP source code and generates a binary representation of the PHP code known as Zend opcodes. Opcodes are sets of instructions similar to Java bytecodes. These opcodes are stored in memory. The second phase of Zend engine processing consists in executing the generated opcodes.”

Parser le source, générer un binaire puis executer des opcodes… Voyons voir, comme parser un source en C, le compiler et écrire sa représentation binaire puis l’exécuter? Ou presque. Il reste nécessaire d’avoir ce compilo/VM qui s’exécute et certaines opération se répètent. Un binaire se lance en RAM et y reste jusqu’à nouvel ordre. L’assembleur est stocké en mémoire puis parcouru mais pas de relecture ou rechargement. La définition de compilateur est bien de générer un bytecode ou pseudo bytecode (opcode) mais la différence réside dans le fait de le faire régulièrement ou une seul fois dans le cas qui nous occupe.

De la même façon, Java se compile pour être exécuter dans une VM au final. Ma pensé derrière le terme compilé est celle lié à la génération d’un bytecode directement exploitable par la machine, sans intermédiaire. Comme un code C traduit en assembleur. La démarche de HipHop m’intéresse donc à ce titre.

APC réduit effectivement le temps d’exécution mais les process PHP pullulent quand même en mémoire et mangent un sacré paquet de temps CPU.

Quand aux “traducteurs” (injustement assimilé au compilateur dans mon article), oui, ils peuvent aider, en tout cas je le pense même si cela reste une opinion à étayer par un benchmark. Utiliser Hip Hop et Gcc avec un code C++ sera beaucoup plus efficace que de lire et relire le même bout de code en boucle. Par ailleurs les programmes en C/C++ sont beaucoup plus optimisés puisqu’ils tournent de manière très proche du processeur.

La couche VM est consommatrice de ressource par essence et pas forcément utile, si ce n’est pour la portabilité. Mais il vaut mieux avoir un code nativement optimisé pour le processeur. Je suis donc malgré tout confiant dans cet avenir, peut être que les gens de Facebook le sont aussi sinon ils n’auraient pas regardé dans cette direction ne pensez-vous pas ?

Quand au coté “dynamique”, il s’agit juste de réagir différemment en fonction du résultat d’un requête ou de la valeur d’une variable, ce que font aussi les langages compilés depuis bien longtemps. L’opposition n’est pas entre dynamique et compilé mais entre interprété et compilé. Je vous rejoins par contre sur le fait que le typage faible (assistance aux développeurs peu intéressés par les contingences de ressources à mon sens), est un handicape à la performance et à la capacité à en faire un langage compilé.

Je vous rejoins aussi sur le compromis vitesse de dev / vitesse d’exécution. Il s’agit même de ne pas fermer le club des développeurs car peu d’entre eux veulent se frotter à la gestion de la mémoire et au typage fort. Qui n’a jamais hurlé devant un core dump a 3H du matin avec son GDB. Je comprends donc les développeurs qui veulent confier cela à des framework, des interpréteurs ou des garbages collector mais on perd en optimisation.

Fais du profiling sur un site un peu complexe, côté PHP ce qui va ressortir le plus souvent, ce sont :
- les accès disque (autoinclude de dizaines de classes, caching, templating … )
- les accès réseau (rapatriement des données de la base, contact d’API externes …)
Et après seulement tu vas commencer à voir les limites du langage dans certains cas précis, par exemple si tu fais beaucoup de templating, tu vas voir les manipulations de string et les regexp qui prennent du temps CPU

Côté browser, c’est la même histoire si l’on fait du profiling :
- le browser passe son temps à attendre des css et des fichiers javascript, pendant ce temps la page est soit blanche soit inaccessible
- chaque inclusion de widget ou plus fréquemment de pub bloque aussi le rendu, le temps d’être retrouvé puis exécuté
- une fois toute la page chargée, ce sont les manipulations dans le DOM qui donnent des coups de freeze (animations, insertions de contenu …)
Et après seulement on tombe sur les limites de JS, la principale étant la manipulation des strings.

Bref, connaître des astuces de manipulations de string en PHP et en JS c’est bien, et il faut les appliquer si ça ne rend pas le code illisible pour les autres, mais c’est illusoire de compter là dessus

en aparté, pour + de background sur HipHop PHP : http://jpv.typepad.com/blog/2010/02/facebook-php-compiler-hiphop-php-les-limites.html
voir en particulier les liens en bas, il y a un bench où HPHP s’en sort bien, mais c’est une solution que l’on peut commencer à utiliser quand on a déjà traité les autres (réseau, disque)

Ca fait aussi bien longtemps que le code n’est même plus interprété à chaque requête mais qu’on cache l’opcode (c’est dire justement le résultat de cette compilation) via APC ou d’autres. Bref, ne reste que l’exécution dans la VM de PHP.

Bref, vue la fiabilité de l’analyse de l’article, autant ne pas analyser. Quant aux “compilateurs”, il y a eu des essais vers la JVM, vers le CLR, et le HipHop de facebook, à défaut d’être un réel compilateur, permet de faire passer par l’étape C++ pour obtenir bel et bien du code binaire exécutable directement.

Certes PHP n’est pas une foudre de guerre, mais le principal c’est surtout du à l’aspect dynamique, pas tellement à la VM ou au manque de compilation en code binaire. Le typage faible dynamique, ça coute cher, c’est ainsi.

Tout est une question de compromis entre la vitesse de développement et la vitesse d’exécution.

Je suis d’accord sur le fond. mais tu imagine la galère s’il fallait recompiler une page php à chaque modification (la plus part des modifications sont mineures en général).