Portail PHP

Rapport à l'actualité Alternative à PHP Zend

Ma remarque n'était pas dans un but de dénigrer une réponse Open_source à un programme payant. C'est très bien et il peut y avoir pas mal d'applications qui le justifient.
Je voulais juste souligner que pour un projet neuf, il ne faut pas partir dans cette optique avant d'avoir comparé avec des logiciels qui sont faits pour.
La comparaison proposée est à mon avis un peu trop orientée. Elle ne cite pas de programmes "professionnels" cités.
Et surtout, je voulais rendre attentif que ce choix n'est pas forcément une panacée à un problème qui a peut-être une tout autre origine.
Je me trompe peut-être?
PS dans la réponse rapide, je trouve dommage que l'on ne puisse pas pré visualiser

Le prix ne fait pas le professionalisme. Les programmes professionls que je citais sont des programmes tels que Delphi, C, C++. Tu ne fais pas un programme prévu pour être interprété et ensuite tu le compiles, ce sont des logiciels où tu parts avec l'option directe que le programme sera compilé. (autrement, il est inutilisable)
En faisant un paralèlle, le programme prévu est comme une voiture de grand tourisme et la compilation la transforme en voiture de course.
Les logiciels que je cite sont des voitures F1. (que tu ne peux pas utiliser normalement pour aller draguer les nanas, à l'inverse d'une porsche, où ça marche assez bien)
Il est arrivé que Porsche gagne des grands prix, mais ce n'est pas la règle.

Pour la remarque que ce n'est pas forcément la panacée des problèmes de rapidité, j'ai déjà cité l'engorgement des sites, la mauvaise programmation etc

LeSkaMan  a écrit:

Delphi , C , C++ ne sont pas des programmes, mais des languages de programmation

C'est juste, c'est une faute de language.

Ce que je voulais dire, c'est que probablement la compilation en language machine, d'un code fait pour être interprété, est certainement moins bonne qu'un code fait pour être directement compilé.
Ce n'est peut-être pas vrai, mais dans le passé, cela s'est vérifié plusieurs fois
notament avec le basic où l'on a créer des logiciels pour faire du code machine.(VB)
c'était incomparablement plus lourd, lent etc qu'un programme pascal ou fortran.

Les languages de programmation proposés font une première étape dans laquelle ils transforment du code PHP en C++ ou C, je ne sais pas. Ênsuite le C++ est compilé en code machine.
Avec les logiciels dont je te parle, ils sont directement compilés.

En faisant une comparaison hasardeuse: Tu crée une page sur Word ou en Netscape et tu la sauves en html. (je crois que Flash ne fait pas mieux)
A première vue c'est parfait, jusqu'à ce que tu voies le code! Un fichier fait par ce moyen est en moyenne 10 plus volumineux que si tu le fais directement en code html et surtout 20 fois plus lent. Les répétitions inutiles sont la règle et ceci se paie.
En gros, il y a fort à parier qu'en ajoutant une étape, par facilité, dans le développement d'un logiciel, tu n'apportes pas une amélioration des performances. C'est pas évident?
C'est ce qu'il faut comprendre au niveau de la démonstration de rapidité.

C'est comme dire que la voiture la plus rapide C'est Peugeot par exemple: si tu ne prends que Fiat, Volkswagen et autres voiture GT, sans comparer avec une formule 1.

Grossièrement dit: le plus rapide est le language machine. ensuite vient l'assembler, ensuite les languages de programmation qui sont compilés directement, ensuite les programmes qui traduisent un logiciel écrit pour être interprétés en un des languages précédents et pour finir les languages interprétés.

Comme je l'ai dit, je ne condamne pas ces logiciels, au contraire surtout l'Open source, mais je mets simplement en garde que si les problèmes sont d'un autre ordre, (engorgement etc) cela ne résoudra pas grand chose.

Que fait l'accélérateur de programme?
Il transforme ton source PHP en C dans une première étape, puis il fait un binaire avec cela.
Le gain de temps que l'on obtient provient que justement ton programme ne passe plus par un interpréteur, mais tourne directement en language machine à l'appel du programme.
Je n'ai pas dit qu'il ne fallait pas accélérer les programmes. J'ai simplement dit que lors d'un problème de vitesse, cela va faire des déçus.
Prends l'exemple d'un hébergeur mal équipé (le tien?). Ton programme tourne en PHP en 0.4 sec avec un accélérateur en 0.004s
la sortie de chez l'hébergeur, elle prend 30 secondes. Proportionnellement qu'est-ce que tu as gagné?

(ces chiffres sont évidement faux et exagérés pour faire comprendre le problème)

faisons une comparaison en hydraulique:
Tu as un bassin avec un écoulement par un tout petit tuyau. Tu mets une turbine qui double la hauteur d'eau  à la sortie du bassin. cela ne va pas augmenter ton débit sensiblement par rapport à élargissement important du tuyau de sortie.

Bonjour,

TurckMMCache a été crée par Dmitry Stogov pour le compte d'une société. L'objectif était de fournir un cache d'opcode pour accélerer des applications écrites en PHP, et aussi offrir un moyen de "compiler" des scripts php afin de rendre les sources illisibles (encodage, un peu plus poussé qu'une simple obfuscation).

Dmitry Stogov a été recruté par Zend. Depuis le projet TurckMMCache a été abandonné.

eAccelerator est un "fork" (la suite) de turckmmcache, basé sur le même code source, et qui évolue avec 2 developpeurs (pour l'instant) Bart (belge) et Hans (allemand), ainsi qu'une bonne cinquantaine de contributeurs plus ou moins anonymes.

eAccelerator optimise et conserve le résultat de la compilation d'un script PHP (opcode = code intérmédiaire) en mémoire partagée ou fichier texte. Ainsi, lorsque le script est rappellé, le process qui transforme le script php en opcode executable par le Zend Engine (le moteur php en fait) n'a pas besoin d'être ré-executé, ce qui apporte, en fonction du code lui même, un gain en performance qui peut osciller entre 3% et ... 3000% en performance BRUTE. Je met volontairement le mot brute en majuscule car faire un code de 10 lignes qui contient 5 requetes SQL ne bénéficiera que d'un très faible gain en performance. Par contre, avec un algorythme 100% php, non dépendant d'accès à des composants externes (SQL, fonction stream*, curl*, ...), on pourra observer une diminution du temp d'exécution considérable.

Contrairement a ce que j'ai pu le lire un peu plus bas, le code PHP n'est pas réécrit à la volée en C ou C++. eAccelerator ou TurckMMCache ou même Zend Accelerator ne sont que des "caches" de code intermédiaire.

Déroulement = Script PHP -> transformation en code intérmédiaire par l'interpreteur PHP executable par Zend Engine -> Zend Engine -> language machine -> execution.

Le principe de l'acceleration via un cache d'opcode est fiable et ne pose pas de gros probleme. Par contre, l'encodage en est un. En effet, les instructions du code intermédiaire (opcode) sont susceptibles de varier à chaque version de php ou presque. Un code PHP encodé avec eAccelerator (ou turckMMCache) version X et PHP version Y ne fonctionnera peut etre pas avec eAccelerator version X2 et PHP version Y2.
D'ou, par exemple, la nécessité de supprimer les fichiers du cache eAccelerator et/ou redémarrer apache après une mise à jour eAccelerator/php.

Enfin, pour des raisons très techniques et justifiée, sachez qu'eAccelerator ne fonctionne pas en CGI pure (ca fonctionne avec fastCGI) ni en CLI (command line interface). En effet, il y a une notion de mémoire partagée (shared memory) qui n'est accessible que dans un environnement type serveur web avec php compilé en module ou "inside".

En esperant vous avoir apporté quelques lumières...

Cordialement,
Franck T.
Administrateur du projet eAccelerator.

> Merci beaucoup pour cette éclairsissement !
Pas de quoi. Ceci dit, si je rentre vraiment trop dans l'aspect technique, il est fort probable que je commence a dire des bétises. Alors je me suis arrété aux questions que vous vous posiez. Si vraiment vous désirez comprendre le fin fond de l'histoire et le pourquoi du comment de la chose, rendez vous sur irc #eaccelerator (freenode) - anglais indispensable

> Mais, lorsque tu appelles une page php, et qu'elle s'execute sur le serveur ... on ne peux pas comparer ca à la compilation
> d'un programme en C++ ?  Si ?

L'idée, le principe, oui pourquoi pas, on peut comparer, mais c'est très grossier.

Un script PHP sans cache d'opcode est "recompilé" à chaque fois que la page est demandée. Avec un cache d'opcode, le script PHP est "compilé" puis le résultat de la compilation est stocké dans la mémoire vive ou sur le disque afin d'être directement rappellé si le script en question est à nouveau sollicité. Cela évite au serveur d'avoir a "recompiler" le script en question à chaque fois.

Fait un module apache en C pour afficher "bonjour" et fait la meme en PHP, les performances n'ont strictement rien à voir. Le module apache C n'a pas besoin d'être interprété/compilé à chaque fois, il s'execute directement, contrairement a un script PHP.

L'opcode généré par turckMMCache ou eAccelerator ne peut pas être utilisé sans le Zend Engine, alors, on ne peut pas vraiment comparer avec un programme en C qui lui, une fois compilé, est utilisable tout seul (sauf dépendances librairies et plateforme, certes, ...)

> En tout cas merci beaucoup d'être venu nous parler de eAccelerator !
Pas de quoi, google alert m'avertis de tous les nouveaux sites parlant de turckmmcache, alors j'en profite pour expliquer la transition vers eAccelerator ..

Cdt,
Franck T.