Regardez la bataille de performances entre PHP7 et HHVM

Récemment, la comparaison des performances entre PHP7 et HHVM est devenue un sujet brûlant et controversé. Tout le monde discute et prête attention à lequel. C'est mieux. C'est l'avenir de l'amélioration des performances PHP.

L'origine de HHVM (HipHop Virtual Machine)

HHVM est une machine virtuelle PHP open source qui utilise la compilation JIT et d'autres technologies pour améliorer considérablement les performances d'exécution du code PHP. Selon la rumeur, les performances d'exécution de la version actuelle du code PHP natif pourraient être améliorées de 5 à 10 fois.

HHVM est originaire de Facebook. La plupart des premiers codes de Facebook ont ​​été développés en utilisant PHP. Cependant, avec le développement rapide de l'entreprise, l'efficacité de l'exécution de PHP est devenue un problème de plus en plus évident. Afin d'optimiser l'efficacité de l'exécution, Facebook a commencé à utiliser HipHop en 2008, un moteur d'exécution PHP conçu à l'origine pour convertir la grande quantité de code PHP de Facebook en C++ afin d'améliorer les performances et d'économiser des ressources. Les performances du code PHP utilisant HipHop ont été améliorées plusieurs fois. Plus tard, Facebook a ouvert la plate-forme HipHop et l'a progressivement développée pour devenir le HHVM actuel.

1. Pourquoi PHP est-il lent ?

PHP est plus lent que les langages de niveau C/C++. En fait, le langage PHP n'a pas été conçu à l'origine pour résoudre des scénarios d'application gourmands en calcul. On peut grossièrement comprendre que PHP sacrifie l'efficacité d'exécution afin d'améliorer l'efficacité du développement.

Nous savons qu'une fonctionnalité importante de PHP est la fonctionnalité de type faible, c'est-à-dire que je peux définir une variable à volonté, puis l'attribuer à différents types de données à volonté. Prenons l'exemple d'un nombre entier int, en langage C :

int num = 200; // Généralement 4 octets

Cependant, si PHP définit la même variable, la structure de stockage correspondante est :

Cette structure occupera beaucoup plus de mémoire que les variables C. Elle est définie en PHP comme suit :

$a = 200;//Cette variable. occupera en fait plusieurs fois l'espace de stockage par rapport à la variable C.

En fait, pour PHP, quel que soit le type de données stockées, elles sont implémentées en utilisant la structure "killing" mentionnée ci-dessus. Afin d'être compatible avec le type de variable "intrusion" des programmeurs PHP, PHP a été convivial pour les développeurs, mais cruel pour le moteur d'exécution. La consommation de mémoire d'une seule variable n'est peut-être pas encore évidente. Une fois les tableaux PHP utilisés, la complexité augmente de façon exponentielle (l'implémentation des tableaux est HashTable). Ensuite, lorsque le moteur Zend est exécuté, ces codes PHP sont compilés en opcode (le bytecode intermédiaire de PHP, le format est quelque peu similaire à l'assembly), qui est interprété et exécuté ligne par ligne par le moteur Zend.

Qu'il s'agisse de l'opération de connexion de chaînes ou de la simple modification de tableaux, etc., c'est presque le rythme de "un mot d'un programmeur PHP, et le moteur Zend va tomber en panne". Par conséquent, pour la même opération, PHP consomme plus de ressources système telles que le CPU et la mémoire que C. De plus, il existe un recyclage automatique de la mémoire, un jugement de type variable, etc., qui augmenteront la consommation des ressources système.

Par exemple, j'ai utilisé la fonction de tri rapide et la fonction de tri native implémentée en PHP pur pour trier 10 000 nombres entiers afin de faire une comparaison chronophage. Les résultats sont les suivants :

<.>

Le tri natif prend 3,44 ms, tandis que la fonction PHP que nous avons implémentée prend 68,79 ms. Nous avons constaté qu’il existe un énorme écart en termes d’efficacité d’exécution entre les deux. Ma façon de tester consiste à calculer l'intervalle de temps avant et après l'exécution de la fonction, et non le temps écoulé entre le début et la fin de l'ensemble du script PHP. Le processus de démarrage et d'arrêt du script PHP lui-même implique une série de travaux d'initialisation et de nettoyage, qui prennent également beaucoup de temps.

Habituellement, le classement de l'efficacité d'exécution de PHP est :

Le plus rapide est la structure du langage PHP (isset, echo, etc.), PHP partie du langage (ce ne sont pas du tout des fonctions).
1. Ensuite, les plus rapides sont les fonctions natives et étendues de PHP. L'extension PHP, basée sur l'API Zend, implémente des fonctions en C, et son efficacité d'exécution est du même ordre de grandeur que C++/Java.
2. Ce qui est vraiment lent, c'est le code et les fonctions que nous écrivons nous-mêmes via PHP. Par exemple, si nous utilisons un framework relativement lourd implémenté en PHP pur, parce que le framework lui-même comporte de nombreux modules, il réduira évidemment l'efficacité d'exécution au niveau du langage et occupera plus de mémoire. (Le framework Yaf domestique est implémenté de manière étendue, donc l'efficacité d'exécution est beaucoup plus rapide que le framework écrit en PHP pur)

Dans des circonstances normales, nous ne recommandons pas d'utiliser PHP pour implémenter des fonctions de calcul logique complexes, en particulier dans les scénarios où le trafic du système Web est relativement important. Par conséquent, les programmeurs PHP doivent avoir une compréhension relativement large des diverses fonctions natives et des diverses extensions de PHP. Dans des scénarios d'implémentation de fonctions spécifiques, recherchez des solutions plus natives (interfaces ou extensions natives) au lieu d'en écrire une par eux-mêmes. type de fonctionnalité.

Si vous disposez de suffisamment de capacités de développement d'extensions PHP, la réécriture de ce type de fonction métier en tant qu'extension PHP améliorera également considérablement l'efficacité de l'exécution du code. C'est une très bonne méthode et elle est également largement utilisée dans l'optimisation PHP. Cependant, les inconvénients du développement commercial PHP auto-écrit sont également évidents :

1. Le développement d'extensions prend beaucoup de temps et les modifications sont compliquées lorsqu'une mauvaise écriture peut affecter la stabilité des services Web. (Par exemple, dans le mode travailleur d'Apache, s'il se bloque dans un scénario multithread, cela affectera d'autres sous-threads normaux dans le même processus. S'il s'agit d'un mode Web multithread, l'extension d'écriture doit prendre en charge la sécurité des threads. )
2. Les extensions peuvent devoir effectuer un travail de compatibilité supplémentaire lors de la mise à niveau de la version PHP.
3. Les coûts de maintenance et de reprise après changement de personnel sont également relativement élevés.

En fait, parmi les sociétés Internet de première ligne, la solution la plus courante n'est pas d'ajouter des extensions PHP, mais d'écrire un serveur de service indépendamment en C/C++, puis PHP communique avec le serveur de service via des sockets. Le traitement métier ne couple pas PHP lui-même avec l'entreprise.

Cependant, la plupart des goulots d'étranglement en termes de performances des services Web résident dans le temps de transmission réseau et d'autres serveurs de services (tels que MySQL, etc.). Le temps d'exécution de PHP représente une très petite proportion de celui-ci. le temps global prend, donc d'un point de vue commercial, l'impact peut ne pas être évident.

2. La façon dont HHVM améliore les performances d'exécution de PHP

La façon dont HHVM améliore les performances de PHP est de remplacer le moteur Zend pour générer et exécuter des PHP. bytecode intermédiaire (HHVM génère son propre format de bytecode intermédiaire) et exécutez-le via JIT (Just In Time, Just In Time Compilation est une technologie d'optimisation logicielle, qui fait référence au bytecode sera compilé en code machine au moment de l'exécution) et converti en code machine pour exécution. L'approche par défaut du moteur Zend consiste d'abord à le compiler en opcode, puis à l'exécuter une par une. Habituellement, chaque instruction correspond à une fonction de niveau langage C. Si nous générons un grand nombre d’opcodes répétés (codes et fonctions écrits en PHP pur), Zend exécutera ces codes C un par un plusieurs fois. Ce que fait JIT, c'est aller plus loin et compiler un grand nombre de bytecodes exécutés à plusieurs reprises dans le code machine au moment de l'exécution pour améliorer l'efficacité de l'exécution. Habituellement, la condition qui déclenche le JIT est que le code ou la fonction est appelé plusieurs fois.

Code PHP ordinaire, car le type de la variable ne peut pas être fixé, un code logique supplémentaire pour déterminer le type doit être ajouté. Ce code PHP n'est pas propice à l'exécution du processeur. et optimisation. Par conséquent, HHVM a généralement besoin d'utiliser du code PHP avec la méthode d'écriture Hack (code technique supplémentaire ajouté pour être compatible avec certaines fonctionnalités) pour « coopérer », afin de corriger le type de variable et de faciliter la compilation et l'exécution de la machine virtuelle. PHP cherche à accueillir tous les types sous une seule forme, tandis que Hack peut marquer tout ce qui est hébergé avec un certain type.

Exemples d'écriture Hack de code PHP :

L'exemple ci-dessus , le code PHP est principalement ajouté avec des types de variables. L'orientation générale de l'écriture Hack est de changer la méthode d'écriture « dynamique » précédente en une méthode d'écriture « statique » pour coopérer avec HHVM.

HHVM a attiré beaucoup d'attention en raison de ses hautes performances, et certaines sociétés Internet de premier plan ont également commencé à emboîter le pas. À en juger par les résultats des tests de performances d'exécution du langage pur, HHVM est bien en avance sur la version PHP7 en cours de développement.

Cependant, du point de vue de scénarios commerciaux spécifiques, l'écart entre HHVM et PHP7 n'est pas si grand En utilisant la page d'accueil du blog open source WordPress comme scénario de test, l'actuel. l'écart entre eux n'est pas évident.

Cependant, PHP7 est encore en développement. À en juger par les solutions techniques disponibles, le HHVM actuel est légèrement meilleur. Cependant, il existe quelques problèmes dans le déploiement et l'application de HHVM :

1. Le déploiement du service est compliqué et entraîne certains coûts de maintenance.
2. Le code natif PHP n'est pas entièrement pris en charge et les extensions PHP doivent également être correctement compatibles.
3. HHVM est une nouvelle machine virtuelle et peut provoquer des fuites de mémoire lors d'une exécution prolongée. (On dit que lorsque les sociétés Internet de premier plan appliquent cette technologie, elles résolvent les fuites de mémoire en se corrigeant elles-mêmes)

Après tout, HHVM est un projet open source relativement nouveau. Il lui faut encore du temps pour mûrir.

Innovation en termes de performances de PHP7

Les problèmes de performances pour lesquels PHP a longtemps été critiqué seront grandement améliorés dans cette version. Il n'y a pas de PHP6 au milieu de la version. On dit que cette version a un projet, et plus tard la plupart des fonctions ont été implémentées dans la version 5.x. Afin d'éviter toute confusion, la prochaine version majeure sera directement PHP7. . (Il y a quelques années, j'ai aussi lu des livres sur PHP6.)

1 Introduction à PHP7

Bien que la version officielle de PHP7 soit. ne sortira peut-être pas avant octobre 2015, mais une version test devrait être disponible en juin de l'année prochaine, suivie de 3 à 4 mois d'assurance qualité.

Le plan de projet de la communauté PHP est le suivant :

Parce que le projet est toujours en cours de développement, les descriptions des fonctionnalités que l'on peut voir sont relativement vagues. Il y a certainement d'autres fonctionnalités, mais elles n'ont tout simplement pas encore été annoncées. Ce qui suit provient de la communauté PHP. Parce que PHP7 est un projet en cours de développement, ce qui suit peut ne pas être exact, mais cela ne nous empêche pas d'y jeter un œil.

1. PHPNG (PHP next Generation, Next Generation PHP), diverses optimisations de performances pour le moteur d'exécution Zend lui-même, parmi lesquelles JIT peut être implémenté dans le composant Zend Opcache.
2. AST (Abstract Syntax Tree, Abstract Syntax Tree) vise à introduire un middleware dans le processus de compilation PHP pour remplacer la façon de cracher l'opcode directement depuis l'interpréteur. Le découplage de l'interpréteur et du compilateur peut réduire beaucoup de code Hack et, en même temps, rendre l'implémentation plus facile à comprendre et à maintenir.
3. La syntaxe de variable uniforme introduit une syntaxe de variable cohérente et complète en interne, permettant à l'analyseur PHP de prendre en charge plus pleinement différents types de variables. L'utilisation de certaines variables doit être ajustée, comme la variable $$a, etc.
4. Prend en charge la sémantique entière (sémantique entière), telle que NaN, Infinity, <<, >>, corrige la cohérence de list(), etc.

Parmi les fonctionnalités ci-dessus, la plus attendue est l'optimisation des performances de PHPng. La communauté PHP a publié des données de tests de vitesse de performances. À en juger par les données, les performances d'exécution de PHPng ont presque doublé par rapport au début du projet. Ce résultat est déjà très bon. De plus, le plus important est qu'il existe encore de nombreux plans d'optimisation pour PHP7 qui ne sont pas encore terminés. Quand tout sera terminé, je pense que nous pourrons voir un PHP7 avec des performances plus élevées.

Ces données de speed test proviennent de la communauté PHP (wiki.php.net/phpng), et interceptent une partie des données :

Pour l'actuel PHP5. Version 6, l'amélioration des performances de PHPNG en octobre a été très évidente :

Une traduction simple :

• La vitesse du test complet a augmenté de 35. %.
• Dans les scénarios d'application réels, il y a une augmentation de la vitesse de 20 % à 70 % (la page d'accueil WordPress a une amélioration de 60 %)
• Moins de consommation de mémoire
• Supports les plus couramment utilisés SAPI
• Prend en charge la plupart des extensions PHP liées à l'allocation de ressources (69 terminées, 6 à migrer)
• Fournit une vitesse d'exécution comparable à HHVM3.3.0

2. La controverse sur le type faible de PHP

PHP a de nombreuses fonctionnalités controversées, mais à mesure que la version linguistique est publiée et améliorée, les critiques sur les fonctions et les fonctionnalités ont commencé à diminuer. Cependant, la fonctionnalité "type faible" de PHP a évidemment été plus controversée. Du fait que HHVM a directement "supprimé" la fonctionnalité "type faible" via Hack, on peut voir que HHVM n'aime pas la fonctionnalité "type faible". Cependant, aux yeux de beaucoup d’entre nous, programmeurs PHP, c’est l’un des avantages importants de PHP. Les variables en PHP sont conçues pour être décontractées et élégantes, englobant tout. Cela ne rend-il pas le langage plus simple ?

En fait, certaines personnes pensent qu'il s'agit d'un problème sérieux, et la critique de la "faible frappe" ressemble à ceci :

1. Dans les langues "strictes", elle est généralement prédéfinie Le type d'une variable est fixe du début à la fin, et le champ d'utilisation est également fixe. Quant aux variables PHP, nous ne pouvons généralement voir que leurs noms, et la plupart des types ne peuvent pas être prédéfinis et peuvent être modifiés à volonté. (L'allocation de mémoire n'est pas facile à gérer)
2. Afin d'être compatible avec les fonctionnalités de type faibles, PHP doit implémenter une grande quantité de code compatible, y compris le jugement de type, la conversion de type, les méthodes de stockage, etc., qui augmente la complexité interne du langage. (Faible efficacité d'exécution)
3. Le type de la variable est incontrôlable. Il existe un grand nombre de "conversions de type implicites" pendant le processus d'exécution, qui peuvent facilement produire des résultats imprévisibles. (Il faut souligner ici que la conversion de types PHP est un point qui doit être maîtrisé. La conversion de différents types entre eux peut causer de nombreux problèmes, en particulier pour les étudiants qui débutent en PHP)

Ils estiment que celles-ci ne correspondent pas à la simplicité du « ce que vous voyez est ce que vous obtenez », et que les langues à grammaire stricte sont plus efficaces et plus faciles à « comprendre ».

Des langages tels que Javascript ont également été critiqués de la même manière car ils fonctionnent de la même manière sur cette question. Cependant, si une langue est finalement utilisée à grande échelle, elle doit avoir ses raisons. PHP est devenu le langage de script de choix pour le développement de services Web, et Javascript a directement dominé le domaine du front-end Web. Ce n'est pas un hasard si les développeurs ont voté pour eux. Le langage de programmation est un pont entre les humains et les machines, et l’objectif ultime est d’atteindre le grand objectif de « tout le monde peut programmer ».

Tout au long de l'histoire du développement des langages, nous sommes partis du code machine des 0 et des 1, au langage assembleur, puis au langage C, puis au langage de script dynamique PHP. L'efficacité d'exécution diminue de façon exponentielle, mais le seuil d'apprentissage diminue également de façon exponentielle. Le langage PHP protège non seulement la complexité de la gestion de la mémoire et des pointeurs du C, mais protège également davantage la complexité des types de variables. Cela améliore l’efficacité du développement du projet et abaisse le seuil d’apprentissage, mais sacrifie en même temps une certaine quantité de performances d’exécution. Ensuite, le Hack de HHVM nous procure une sensation de « retour au primitif », réintroduisant la complexité des variables. Bien entendu, différents langages résolvent des problèmes dans différents scénarios et ne peuvent pas être généralisés.

Résumé

Les améliorations des performances de HHVM pour PHP sont impressionnantes, et le PHP7 qui travaille dur est impressionnant. il. Les deux sont d’excellents projets open source et tous deux avancent et se développent constamment. Pour l’instant, comme il reste encore beaucoup de temps avant la sortie de la version officielle de PHP7, le choix actuel de solution d’optimisation des performances est bien entendu HHVM. Cependant, personnellement, je suis plus optimiste à propos de PHP7 car il est plus rétrocompatible avec le code PHP. S’il n’y a pas beaucoup de différence de performances entre les deux, je choisirai le plus simple.

Tutoriel recommandé : "Tutoriel vidéo php"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!