Heim >Backend-Entwicklung >PHP7 >Sehen Sie sich den Leistungskampf zwischen PHP7 und HHVM an

Sehen Sie sich den Leistungskampf zwischen PHP7 und HHVM an

coldplay.xixi
coldplay.xixinach vorne
2020-06-24 17:47:023587Durchsuche


Sehen Sie sich den Leistungskampf zwischen PHP7 und HHVM an

In letzter Zeit ist der Leistungsvergleich zwischen PHP7 und HHVM zu einem heißen und kontroversen Thema geworden ist besser. Es ist die Zukunft der PHP-Leistungsverbesserung.

Der Ursprung von HHVM (HipHop Virtual Machine)

HHVM ist eine Open-Source-PHP-Virtual-Machine, die JIT-Kompilierung und andere Technologien verwendet, um die Ausführungsleistung von PHP-Code erheblich zu verbessern. Gerüchten zufolge kann die Ausführungsleistung der aktuellen Version des nativen PHP-Codes um das Fünf- bis Zehnfache verbessert werden.

HHVM stammt ursprünglich von Facebook. Mit der rasanten Geschäftsentwicklung ist die PHP-Ausführungseffizienz jedoch zu einem immer offensichtlicheren Problem geworden. Um die Ausführungseffizienz zu optimieren, begann Facebook 2008 mit der Verwendung von HipHop, einer PHP-Ausführungs-Engine. Sie wurde ursprünglich entwickelt, um die große Menge an PHP-Code von Facebook in C++ umzuwandeln, um die Leistung zu verbessern und Ressourcen zu sparen. Die Leistung von PHP-Code mit HipHop wird mehrfach verbessert. Später stellte Facebook die HipHop-Plattform als Open-Source-Lösung zur Verfügung und entwickelte sie nach und nach zum aktuellen HHVM weiter.

1. Warum ist PHP langsam?

PHP ist langsamer als Sprachen auf C/C++-Ebene. Tatsächlich wurde die PHP-Sprache ursprünglich nicht für die Lösung rechenintensiver Anwendungsszenarien entwickelt. Wir können ungefähr verstehen, dass PHP die Ausführungseffizienz opfert, um die Entwicklungseffizienz zu verbessern.

Wir wissen, dass eine große Funktion von PHP die schwache Typfunktion ist, das heißt, ich kann eine Variable nach Belieben definieren und sie dann nach Belieben verschiedenen Datentypen zuweisen. Nehmen Sie als Beispiel eine int-Ganzzahl in der C-Sprache:

int num = 200; // Normalerweise 4 Bytes

Wenn PHP jedoch dieselbe Variable definiert, lautet die tatsächliche entsprechende Speicherstruktur :

Diese Struktur belegt viel mehr Speicher als C-Variablen. Sie ist in PHP wie folgt definiert:

$a = 200;//Diese Variable wird im Vergleich zur C-Variable tatsächlich ein Vielfaches des Speicherplatzes beanspruchen.

Tatsächlich wird PHP unabhängig von der Art der gespeicherten Daten mithilfe der oben genannten „Tötungs“-Struktur implementiert. Um mit dem Variablentyp „Intrusion“ von PHP-Programmierern kompatibel zu sein, war PHP freundlich zu Entwicklern, aber grausam gegenüber der Ausführungs-Engine. Der Speicherverbrauch einer einzelnen Variablen ist möglicherweise noch nicht offensichtlich. Sobald PHP-Arrays verwendet werden, steigt die Komplexität exponentiell (die Implementierung von Arrays ist HashTable). Wenn dann die Zend-Engine ausgeführt wird, werden diese PHP-Codes in Opcode (PHPs Zwischenbytecode, das Format ähnelt in gewisser Weise der Assemblierung) kompiliert, der von der Zend-Engine Zeile für Zeile interpretiert und ausgeführt wird.

Ob es sich um den Verbindungsvorgang von Strings oder die einfache Änderung von Arrays usw. handelt, es ist fast der Rhythmus von „Ein Wort eines PHP-Programmierers, und die Zend-Engine bricht zusammen“. Daher verbraucht PHP für denselben Vorgang mehr Systemressourcen wie CPU und Speicher als C. Darüber hinaus gibt es automatisches Speicherrecycling, Variablentypbeurteilung usw., was den Verbrauch von Systemressourcen erhöht.

Zum Beispiel habe ich die Schnellsortierungsfunktion und die in reinem PHP implementierte native Sortierfunktion verwendet, um 10.000 Ganzzahlen zu sortieren und einen zeitaufwändigen Vergleich durchzuführen. Die Ergebnisse sind wie folgt:

Die native Sortierung dauert 3,44 ms, während die von uns selbst implementierte PHP-Funktionssortierung 68,79 ms benötigt. Wir haben festgestellt, dass zwischen beiden eine große Lücke in der Ausführungseffizienz besteht. Meine Art zu testen besteht darin, das Zeitintervall vor und nach der Ausführung der Funktion zu berechnen, nicht die Zeit vom Anfang bis zum Ende des gesamten PHP-Skripts. Der Start- und Herunterfahrvorgang des PHP-Skripts selbst erfordert eine Reihe von Initialisierungs- und Bereinigungsarbeiten, die ebenfalls viel Zeit in Anspruch nehmen.

Normalerweise ist die Rangfolge der PHP-Ausführungseffizienz:

  1. Am schnellsten ist die PHP-Sprachstruktur (isset, echo usw.), PHP Teil der Sprache (sie sind überhaupt keine Funktionen).
  2. Dann sind die nativen und erweiterten Funktionen von PHP die schnelleren. Die auf der Zend-API basierende PHP-Erweiterung implementiert Funktionen in C und ihre Ausführungseffizienz liegt in der gleichen Größenordnung wie C++/Java.
  3. Was wirklich langsam ist, ist der Code und die Funktionen, die wir selbst über PHP schreiben. Wenn wir beispielsweise ein relativ umfangreiches Framework verwenden, das in reinem PHP implementiert ist, verringert dies offensichtlich die Ausführungseffizienz auf Sprachebene und belegt mehr Speicher, da das Framework selbst über viele Module verfügt. (Das inländische Yaf-Framework wird erweitert implementiert, sodass die Ausführungseffizienz viel schneller ist als das in reinem PHP geschriebene Framework)

Unter normalen Umständen empfehlen wir nicht, PHP zur Implementierung komplexer logischer Berechnungsfunktionen zu verwenden, insbesondere in Szenarien, in denen der Websystemverkehr relativ groß ist. Daher sollten PHP-Programmierer über ein relativ umfassendes Verständnis der verschiedenen nativen Funktionen und Erweiterungen von PHP verfügen und nach mehr nativen Lösungen (nativen Schnittstellen oder Erweiterungen) suchen, anstatt selbst einen Stapel komplexer PHP-Codes zu schreiben Art der Funktionalität.

Wenn Sie über genügend Entwicklungsfunktionen für PHP-Erweiterungen verfügen, wird das Umschreiben dieser Art von Geschäftsfunktion als PHP-Erweiterung auch die Ausführungseffizienz des Codes erheblich verbessern. Dies ist eine sehr gute Methode und wird auch häufig in der PHP-Optimierung eingesetzt. Allerdings liegen auch die Nachteile der selbst geschriebenen PHP-Geschäftsentwicklung auf der Hand:

  1. Die Entwicklung von Erweiterungen dauert lange und Änderungen sind kompliziert, wenn sich Anforderungen ändern. Schlechtes Schreiben kann die Stabilität von Webdiensten beeinträchtigen. (Wenn es beispielsweise im Worker-Modus von Apache in einem Multithread-Szenario hängt, wirkt es sich auf andere normale Unterthreads im selben Prozess aus. Wenn es sich um einen Multithread-Webmodus handelt, muss die Schreiberweiterung Thread-Sicherheit unterstützen )
  2. Erweiterungen müssen beim Upgrade der PHP-Version möglicherweise zusätzliche Kompatibilitätsarbeiten durchführen.
  3. Auch die Wartungs- und Übernahmekosten nach Personalwechseln sind relativ hoch.

Tatsächlich besteht die gängigere Lösung bei Frontline-Internetunternehmen nicht darin, PHP-Erweiterungen hinzuzufügen, sondern einen unabhängigen Dienstserver in C/C++ zu schreiben, und dann kommuniziert PHP mit dem Dienstserver Durch die Geschäftsverarbeitung wird PHP selbst nicht mit dem Geschäft gekoppelt.

Die meisten Leistungsengpässe von Webdiensten liegen jedoch in der zeitaufwändigen Netzwerkübertragung und anderen Dienstservern (wie MySQL usw.). Der Zeitaufwand für die Ausführung von PHP macht einen sehr geringen Anteil aus Das ist insgesamt zeitaufwändig, daher sind die Auswirkungen aus geschäftlicher Sicht möglicherweise nicht offensichtlich.

2. Die Art und Weise, wie HHVM die PHP-Ausführungsleistung verbessert

Die Art und Weise, wie HHVM die PHP-Leistung verbessert, besteht darin, die Zend-Engine zum Generieren und Ausführen von PHPs zu ersetzen Zwischenbytecode (HHVM generiert Zwischenbytecode in seinem eigenen Format) und führt ihn über JIT (Just In Time, Just In Time Compilation) aus. Dies ist eine Softwareoptimierungstechnologie, die sich auf den Bytecode bezieht wird zur Laufzeit in Maschinencode kompiliert) und zur Ausführung in Maschinencode umgewandelt. Der Standardansatz der Zend-Engine besteht darin, sie zuerst in Opcode zu kompilieren und sie dann einzeln auszuführen. Normalerweise entspricht jede Anweisung einer Funktion auf C-Sprachebene. Wenn wir eine große Anzahl wiederholter Opcodes (in reinem PHP geschriebene Codes und Funktionen) generieren, führt Zend diese C-Codes einzeln und mehrmals aus. JIT geht noch einen Schritt weiter und kompiliert zur Laufzeit eine große Anzahl wiederholt ausgeführter Bytecodes in Maschinencode, um die Ausführungseffizienz zu verbessern. Normalerweise ist die Bedingung, die JIT auslöst, dass der Code oder die Funktion mehrmals aufgerufen wird.

Gewöhnlicher PHP-Code, da der Typ der Variablen nicht festgelegt werden kann, muss zusätzlicher Logikcode zur Bestimmung des Typs hinzugefügt werden. Dieser PHP-Code ist für die CPU-Ausführung nicht förderlich und Optimierung. Daher muss HHVM normalerweise PHP-Code mit der Hack-Schreibmethode (zusätzlicher technischer Code hinzugefügt, um mit bestimmten Funktionen kompatibel zu sein) verwenden, um zu „kooperieren“, um den Variablentyp festzulegen und die Kompilierung und Ausführung der virtuellen Maschine zu erleichtern. PHP versucht, alle Typen in einer Form unterzubringen, während Hack alles markieren kann, was einem bestimmten Typ zugeordnet ist.

Beispiele für Hack-Schreiben von PHP-Code:

Das obige Beispiel , PHP-Code wird hauptsächlich mit Variablentypen hinzugefügt. Die allgemeine Richtung des Hack-Schreibens besteht darin, die bisherige „dynamische“ Schreibmethode in eine „statische“ Schreibmethode umzuwandeln, um mit HHVM zusammenzuarbeiten.

HHVM hat aufgrund seiner hohen Leistung viel Aufmerksamkeit auf sich gezogen, und auch einige erstklassige Internetunternehmen haben begonnen, diesem Beispiel zu folgen. Den Ergebnissen des reinen Sprachausführungsleistungstests nach zu urteilen, ist HHVM der in der Entwicklung befindlichen PHP7-Version weit voraus.

Aus der Perspektive spezifischer Geschäftsszenarien ist die Lücke zwischen HHVM und PHP7 jedoch nicht so groß. Unter Verwendung der WordPress-Open-Source-Blog-Homepage als aktuelles Testszenario Die Kluft zwischen ihnen ist nicht offensichtlich.

PHP7 befindet sich jedoch noch in der Entwicklung. Den verfügbaren technischen Lösungen nach zu urteilen, ist das aktuelle HHVM etwas besser. Es gibt jedoch einige Probleme bei der Bereitstellung und Anwendung von HHVM:

  1. Die Bereitstellung von Diensten ist kompliziert und mit gewissen Wartungskosten verbunden.
  2. Nativer PHP-Code wird nicht vollständig unterstützt und PHP-Erweiterungen müssen ebenfalls ordnungsgemäß kompatibel sein.
  3. HHVM ist eine neue virtuelle Maschine und kann bei längerer Ausführung zu Speicherverlusten führen. (Es wird gesagt, dass erstklassige Internetunternehmen, wenn sie diese Technologie anwenden, Speicherlecks beheben, indem sie sich selbst patchen.)

Schließlich ist HHVM ein relativ neues Open-Source-Projekt. Es dauert noch einige Zeit, bis es reif ist.

Leistungsinnovation von PHP7

Die Leistungsprobleme, für die PHP seit langem kritisiert wird, werden in dieser Version erheblich verbessert. In der Version gibt es kein PHP6. Es wird gesagt, dass diese Version ein Projekt hat und die meisten Funktionen später in der 5.x-Version implementiert wurden. Um Verwirrung zu vermeiden, wird die nächste Hauptversion direkt PHP7 sein. (Vor ein paar Jahren habe ich auch Bücher über PHP6 gesehen.)

1 Einführung in PHP7

Obwohl die offizielle Version von PHP7 It Die Veröffentlichung erfolgt möglicherweise erst im Oktober 2015, eine Testversion sollte jedoch im Juni nächsten Jahres verfügbar sein, gefolgt von einer 3-4-monatigen Qualitätssicherung.

Der Projektplan der PHP-Community sieht wie folgt aus:

Da sich das Projekt noch in der Entwicklung befindet, sind die aus der Tabelle ersichtlichen Funktionsbeschreibungen relativ vage. Es gibt definitiv noch weitere Features, diese wurden nur noch nicht angekündigt. Das Folgende stammt von der PHP-Community. Da es sich bei PHP7 um ein in der Entwicklung befindliches Projekt handelt, ist das Folgende möglicherweise nicht korrekt, hindert uns jedoch nicht daran, einen Blick darauf zu werfen.

  1. PHPNG (PHP Next Generation, Next Generation PHP), verschiedene Leistungsoptimierungen für die Zend-Ausführungs-Engine selbst, darunter JIT, das in der Zend Opcache-Komponente implementiert werden kann.
  2. AST (Abstract Syntax Tree, Abstract Syntax Tree) zielt darauf ab, eine Middleware in den PHP-Kompilierungsprozess einzuführen, um die Art und Weise zu ersetzen, Opcode direkt aus dem Interpreter auszuspucken. Die Entkopplung von Interpreter und Compiler kann eine Menge Hack-Code reduzieren und gleichzeitig das Verständnis und die Wartung der Implementierung erleichtern.
  3. Die einheitliche Variablensyntax führt eine intern konsistente und vollständige Variablensyntax ein, sodass der PHP-Parser verschiedene Arten von Variablen besser unterstützen kann. Die Verwendung einiger Variablen muss angepasst werden, z. B. der Variablen $$a usw.
  4. Unterstützt Ganzzahlsemantik (Ganzzahlsemantik) wie NaN, Infinity, <<, >>, korrigiert die Konsistenz von list() usw.

Unter den oben genannten Funktionen ist die Leistungsoptimierung von PHPng die am meisten erwartete. Die PHP-Community hat einige Leistungsgeschwindigkeitstestdaten veröffentlicht. Den Daten zufolge hat sich die Ausführungsleistung von PHPng im Vergleich zum Beginn des Projekts nahezu verdoppelt. Dieses Ergebnis ist bereits sehr gut. Darüber hinaus gibt es noch viele Optimierungspläne für PHP7, die noch nicht abgeschlossen sind. Wenn alles fertig ist, können wir meiner Meinung nach ein PHP7 mit höherer Leistung sehen.

Diese Geschwindigkeitstestdaten stammen von der PHP-Community (wiki.php.net/phpng) und erfassen einen Teil der Daten:

Für den aktuellen Stand PHP5. Version 6, PHPNGs Leistungsverbesserung im Oktober war sehr offensichtlich:

Eine einfache Übersetzung:

  • Die umfassende Testgeschwindigkeit stieg um 35 %.
  • In tatsächlichen Anwendungsszenarien gibt es eine Geschwindigkeitssteigerung von 20–70 % (die WordPress-Homepage hat eine Verbesserung von 60 %).
  • Weniger Speicherverbrauch
  • Unterstützt die am häufigsten verwendeten SAPIs
  • Unterstützt die meisten PHP-Erweiterungen, die an die Ressourcenzuweisung gebunden sind (69 abgeschlossen, 6 müssen migriert werden)
  • Bieten eine mit HHVM3.3.0 vergleichbare Ausführungsgeschwindigkeit

2. Kontroverse um PHPs schwache Typen

PHP hat viele umstrittene Funktionen, aber mit der Veröffentlichung und Verbesserung der Sprachversion begann die Kritik an Funktionen und Merkmalen abzunehmen. Die Funktion „schwacher Typ“ von PHP ist jedoch offensichtlich umstrittener. Aus der Tatsache, dass HHVM die Funktion „schwacher Typ“ direkt durch Hack „entfernt“ hat, geht hervor, dass HHVM die Funktion „schwacher Typ“ nicht mag. In den Augen vieler von uns PHP-Programmierern ist dies jedoch einer der wichtigen Vorteile von PHP. Variablen in PHP sind so gestaltet, dass sie locker und elegant sind und alles umfassen. Macht es die Sprache nicht einfacher?

Tatsächlich denken einige Leute, dass es sich um ein ernstes Problem handelt, und die Kritik am „schwachen Tippen“ geht in etwa so:

  1. In „strengen“ Sprachen ist es normalerweise vordefiniert Der Typ einer Variablen ist von Anfang bis Ende festgelegt, und auch der Anwendungsbereich ist festgelegt. Bei PHP-Variablen können wir normalerweise nur deren Namen sehen, und die meisten Typen können nicht vordefiniert werden und können nach Belieben geändert werden. (Die Speicherzuweisung ist nicht einfach zu verwalten)
  2. Um mit schwachen Typfunktionen kompatibel zu sein, muss PHP eine große Menge kompatiblen Codes implementieren, einschließlich Typbeurteilung, Typkonvertierung, Speichermethoden usw erhöht die interne Komplexität der Sprache. (Geringe Ausführungseffizienz)
  3. Der Typ der Variablen ist unkontrollierbar. Während des Ausführungsprozesses gibt es eine große Anzahl von „impliziten Typkonvertierungen“, die leicht zu unvorhersehbaren Ergebnissen führen können. (Es muss hier betont werden, dass die PHP-Typkonvertierung ein Punkt ist, der beherrscht werden muss. Die Konvertierung verschiedener Typen ineinander kann viele Probleme verursachen, insbesondere für Studenten, die neu in PHP sind)

Sie glauben, dass diese nicht im Einklang mit der Einfachheit „Was man sieht, ist das, was man bekommt“ stehen und dass Sprachen mit strenger Grammatik effizienter und leichter zu „verstehen“ sind.

Sprachen wie Javascript wurden ebenfalls in ähnlicher Weise kritisiert, weil sie in dieser Frage die gleiche Leistung erbringen. Wenn eine Sprache jedoch irgendwann in großem Umfang verwendet wird, muss dies ihre Gründe haben. PHP ist zur bevorzugten Skriptsprache für die Entwicklung von Webdiensten geworden, und Javascript hat den Web-Frontend-Bereich direkt dominiert. Es kann kein Zufall sein, dass die Entwickler diesen Punkt erreicht haben. Programmiersprache ist eine Brücke zwischen Mensch und Maschine, und das ultimative Ziel besteht darin, das große Ziel zu erreichen: „Jeder kann programmieren“.

Im Laufe der Geschichte der Sprachentwicklung begannen wir mit dem Maschinencode der Nullen und Einsen, über die Assemblersprache, dann zur C-Sprache und schließlich zur dynamischen Skriptsprache PHP. Die Ausführungseffizienz nimmt exponentiell ab, aber auch die Lernschwelle sinkt exponentiell. Die PHP-Sprache schützt nicht nur die Komplexität der Speicherverwaltung und der Zeiger von C, sondern auch die Komplexität der Variablentypen. Es verbessert die Effizienz der Projektentwicklung und senkt die Lernschwelle, opfert aber gleichzeitig ein gewisses Maß an Ausführungsleistung. Dann gibt uns der Hack von HHVM ein „Rückkehr zum Primitivem“-Gefühl und führt die Komplexität von Variablen wieder ein. Natürlich lösen verschiedene Sprachen Probleme in unterschiedlichen Szenarien und können nicht verallgemeinert werden.

Zusammenfassung

Die Leistungsverbesserungen von HHVM für PHP sind beeindruckend, und ich freue mich sehr darauf Es. Beide sind hervorragende Open-Source-Projekte und beide entwickeln sich ständig weiter. Da es noch lange dauert, bis die offizielle Version von PHP7 veröffentlicht wird, ist HHVM die aktuelle Wahl für die Lösung zur Leistungsoptimierung. Ich persönlich bin jedoch hinsichtlich PHP7 optimistischer, da es abwärtskompatibel mit PHP-Code ist. Wenn zwischen den beiden kein großer Leistungsunterschied besteht, wähle ich die einfachere Variante.

Empfohlenes Tutorial: „PHP-Video-Tutorial

Das obige ist der detaillierte Inhalt vonSehen Sie sich den Leistungskampf zwischen PHP7 und HHVM an. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:csdn.net. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen

In Verbindung stehende Artikel

Mehr sehen