Die PHP-Leistung verbessert sich ständig. Wenn Sie es jedoch unsachgemäß verwenden oder nicht vorsichtig sind, können Sie dennoch in die Fallstricke der internen Implementierung von PHP geraten. Ich bin vor ein paar Tagen auf ein Leistungsproblem gestoßen.
Folgendes ist passiert: Eine unserer Schnittstellen brauchte jedes Mal 5 Sekunden, um zurückzukehren. Wir überprüften den Code gemeinsam und stellten „überrascht“ fest, dass er in einer Schleife aufgerufen wurde (ca. 900). Mal). Obwohl es sich verdoppelt hat, ist das natürlich kein Ergebnis, das wir akzeptieren können!
Die Menge an Code, die das Leistungsproblem verursachte, war nicht groß. Nachdem wir das E/A-Problem behoben hatten, schrieben wir einen Testcode und tatsächlich trat das Problem schnell wieder auf.
<?php
$y="1800";
$x = array();
for($j=0;$j<2000;$j++){
$x[]= "{$j}";
}
for($i=0;$i<3000;$i++){
if(in_array($y,$x)){
continue;
}
}
?>Nach dem Login kopieren
Shell$-Zeit /usr/local/php/bin/php test.php
echt 0m1,132s
Benutzer 0m1,118s
sys 0m0,015s
Ja, wir verwenden String-Nummern, und so sehen sie aus, wenn sie aus dem Cache genommen werden! Hier wird es also speziell in eine Zeichenfolge konvertiert (wenn es sich direkt um eine Zahl handelt, tritt dieses Problem nicht auf, Sie können es selbst überprüfen). Es ist ersichtlich, dass die verbrauchte Zeit 1 Sekunde beträgt, also nur 3000 Zyklen. Die nachfolgende Systemzeit ist auch dazu bestimmt, dass wir mit Strace keine effektiven Informationen erhalten.
shell$ strace -ttt -o xxx /usr/local/php/bin/php test.php
shell$ less xxx
us Ich habe nur gesehen, dass die Verzögerung zwischen diesen beiden Systemaufrufen sehr groß war, aber ich wusste nicht, was getan wurde? Glücklicherweise enthalten die Debugging-Tools unter Linux neben strace auch ltrace (natürlich gibt es auch dtrace und ptrace, die den Rahmen dieses Artikels sprengen und daher weggelassen werden).
Zitat: strace wird verwendet, um die Systemaufrufe oder Signalgenerierung eines Prozesses zu verfolgen, während ltrace verwendet wird, um den Prozess des Aufrufs von Bibliotheksfunktionen zu verfolgen (über IBM Developerworks).
Um Störfaktoren zu eliminieren, weisen wir $x direkt der Array-Form zu („0“, „1“, „2“,...), um zu vermeiden, dass übermäßige Malloc-Aufrufe die Ergebnisse beeinflussen. Führen Sie
shell$ ltrace -c /usr/local/php/bin/php test.php
Abbildung 2
us I aus Ich habe gesehen, dass die Bibliotheksfunktion __strtol_internal sehr häufig aufgerufen wird und 94 % erreicht. Dann habe ich überprüft, was diese Bibliotheksfunktion __strtol_internal tut. Es stellt sich heraus, dass es sich um einen Alias von strtol handelt Bei der Konvertierung in eine lange Ganzzahl können wir vermuten, dass die PHP-Engine erkannt hat, dass es sich um eine Zeichenfolgenzahl handelt, und erwartet daher, sie zum Vergleich in eine lange Ganzzahl umzuwandeln. Dieser Konvertierungsprozess nimmt zu viel Zeit in Anspruch. Wir führen ihn erneut aus:
shell$ ltrace -e "__strtol_internal" /usr/local/php/bin/php test.php
Nach dem Login kopieren
Sie können problemlos eine große Anzahl von Aufrufen wie den unten gezeigten abfangen. An diesem Punkt wurde das Problem gefunden. Dieser lose Vergleich in_array konvertiert zunächst zwei Zeichenfolgen in lange Ganzzahlen und vergleicht sie dann Ich weiß nicht, wie gut die dafür ausgegebene Leistung sein wird.
Da wir nun den Kern des Problems kennen, haben wir viele Lösungen. Die einfachste besteht darin, den dritten Parameter zu in_array auf true hinzuzufügen, was zu einem strengen Vergleich wird. Während auch zum Vergleichen von Typen die clevere Konvertierung von PHP-Typen vermieden wird und der Code wie folgt lautet:
<?php
$y="1800";
$x = array();
for($j=0;$j<2000;$j++){
$x[]= "{$j}";
}
for($i=0;$i<3000;$i++){
if(in_array($y,$x,true)){
continue;
}
}
?>Nach dem Login kopieren
shell$ time /usr/local/php/bin/php test.php
real 0m0.267s
user 0m0.247s
sys 0m0.020s
Nach dem Login kopieren
Um ein Vielfaches schneller! ! ! Man erkennt, dass sich die von sys benötigte Zeit kaum verändert hat. Wenn wir erneut ltraceen, müssen wir $x immer noch direkt zuweisen, um die Interferenz von Malloc-Aufrufen zu beseitigen. Denn in unserer eigentlichen Anwendung ziehen wir es sofort aus dem Cache, sodass es keine Schleife wie im Beispielcode gibt, die beantragt werden muss Erinnerung.
Erneut ausführen
shell$ ltrace -c /usr/local/php/bin/php test.php
Nach dem Login kopieren
wie unten gezeigt:
__ctype_tolower_loc nimmt die meiste Zeit in Anspruch! Ich habe überprüft, was die Bibliotheksfunktion __ctype_tolower_loc macht: Das einfache Verständnis besteht darin, Zeichenfolgen in Kleinbuchstaben umzuwandeln. Bedeutet das also, dass in_array-Vergleichszeichenfolgen nicht zwischen Groß- und Kleinschreibung unterscheiden? Tatsächlich hat dieser Funktionsaufruf wenig mit unserem in_array zu tun. Es ist besser, einen Blick auf den Quellcode von PHP zu werfen. Ich werde ihn wahrscheinlich am Abend besser verstehen. Ich habe den folgenden PHP 5.4.10-Quellcode gelesen, der mich wirklich interessiert: in_array, haha, er befindet sich in Zeile 1248 von ./ext/standard/array.c. Sie können sehen, dass er die Funktion „array_serach“ aufruft Unten wird dies ebenfalls angepasst, aber der letzte Parameter ist anders! Nach einigem Nachverfolgen rief er im Falle eines in_array-losen Vergleichs schließlich die Funktion zendi_smart_strcmp (wirklich eine „intelligente“ Funktion) zum Vergleich auf, die sich in ./Zend/zend_operators.c befindet. Wir haben ltrace verwendet, um eine große Anzahl erfasster Daten zu konvertieren in ganze Zahlen umwandeln. Die Operation ist das Verhalten von is_numeric_string_ex.
Die Funktion is_numeric_string_ex ist in ./Zend/zend_operators.h definiert. Nach einer Reihe von Beurteilungen und Konvertierungen wird strtol in Zeile 232 aufgerufen, was wir im Artikel The gesagt haben Die in erwähnten Systemfunktionen konvertieren Zeichenfolgen in lange Ganzzahlen. Es gibt Bilder und Fakten Wenn Sie Probleme mit der Leistung haben, achten Sie bitte auf die chinesische PHP-Website!
