Rencontre avec des problèmes de performances faibles avec in_array de PHP

Les performances PHP s'améliorent constamment. Cependant, si vous ne l'utilisez pas correctement ou si vous ne faites pas attention, vous risquez toujours de tomber dans les pièges de l'implémentation interne de PHP. J'ai rencontré un problème de performances il y a quelques jours

Les performances de PHP se sont améliorées. Cependant, si vous ne l'utilisez pas correctement ou si vous ne faites pas attention, vous risquez toujours de tomber dans les pièges de l'implémentation interne de PHP. J'ai rencontré un problème de performances il y a quelques jours.

Voici ce qui s'est passé. Un collègue a signalé qu'une de nos interfaces mettait 5 secondes à revenir à chaque fois. Nous avons examiné le code ensemble, et nous avons été « surpris » de constater qu'elle était appelée en boucle (environ 900). fois). Une opération de lecture du cache a été effectuée, mais la clé du cache n'a pas changé, nous avons donc déplacé ce code en dehors de la boucle et testé à nouveau. Le temps de retour de l'interface est tombé à 2 secondes, woohoo ! Même s’il a doublé, ce n’est évidemment pas un résultat que nous pouvons accepter !
La quantité de code à l'origine du problème de performances n'était pas importante. Après avoir éliminé le problème d'E/S, nous avons écrit un morceau de code de test et, bien sûr, le problème est réapparu rapidement.

Copier le code Le code est le suivant :

<?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; 
} 
} 
?>

shell$ time /usr/local/php/bin/ php test.php

real 0m1.132s
user 0m1.118s
sys 0m0.015s

Oui, nous utilisons des nombres de type chaîne. C'est ce que nous obtenons. la cache. Bon sang ! Le voici donc spécialement converti en chaîne (s'il s'agit directement d'un nombre, ce problème ne se produira pas, vous pouvez le vérifier par vous-même). On peut voir que le temps consommé est de 1 seconde, soit seulement 3000 cycles. Le temps système suivant est également destiné à ce que nous n'obtenions aucune information efficace en utilisant strace.

shell$ strace -ttt -o xxx /usr/local/php/bin/php test.php
shell$ less xxx



us J'ai seulement vu que le délai entre ces deux appels système était très important, mais je ne savais pas ce qui était fait ? Je suis perdu. Heureusement, en plus de strace, les outils de débogage sous Linux incluent également ltrace (bien sûr, il existe également dtrace et ptrace, qui dépassent le cadre de cet article et seront omis).

Citation : strace est utilisé pour suivre les appels système ou la génération de signaux d'un processus, tandis que ltrace est utilisé pour suivre le processus d'appel des fonctions de la bibliothèque (via IBM Developerworks).

Afin d'éliminer les facteurs d'interférence, nous attribuons directement $x à la forme du tableau(« 0″ », « 1″ », « 2″,…) pour éviter des appels malloc excessifs affectant les résultats. Exécutez

shell$ ltrace -c /usr/local/php/bin/php test.php

Comme le montre la figure 2




Nous avons vu que la fonction de bibliothèque __strtol_internal est appelée très fréquemment, atteignant 94%, ce qui est trop exagéré. Ensuite, j'ai vérifié à quoi sert cette fonction de bibliothèque __strtol_internal. Il s'avère que c'est un alias de strtol. est Convertir la chaîne en un entier long. On peut deviner que le moteur PHP a détecté qu'il s'agit d'un numéro de chaîne, il s'attend donc à les convertir en un entier long pour comparaison. Ce processus de conversion prend trop de temps, nous l'exécutons donc. encore une fois :

Copier le code Le code est le suivant :

shell$ ltrace -e "__strtol_internal" /usr/local /php/bin/php test.php

peut facilement intercepter un grand nombre d'appels comme l'image ci-dessous. À ce stade, le problème a été trouvé dans In_array. une comparaison lâche convertira d'abord les chaînes numériques de deux caractères. Comparez à nouveau le type entier long, mais je ne sais pas si les performances sont consommées à ce sujet.



Maintenant que nous connaissons le nœud du problème, nous avons de nombreuses solutions. La plus simple est d'ajouter le troisième paramètre de in_array à true, ce qui devient une comparaison stricte, tout en comparant les types, cela évite les types de conversion intelligents de PHP, et cela s'exécute beaucoup plus rapidement. Le code est le suivant :

Copiez le code Le. le code est le suivant :

<?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;
        }
}
?>

Copier le code Le code est le suivant :

shell$ time /usr/local/php/bin/php test.php

réel 0m0.267s
utilisateur 0m0.247s
sys 0m0.020s

Beaucoup plus rapide ! ! ! On voit que le temps pris par sys n'a pratiquement pas beaucoup changé. Lorsque nous retraçons, nous devons toujours attribuer $x directement pour éliminer les interférences des appels malloc. Parce que dans notre application actuelle, nous le retirons immédiatement du cache, il n'y a donc pas de boucle comme dans l'exemple de code à appliquer. mémoire.
Exécuter à nouveau

Copiez le code Le code est le suivant :

shell$ ltrace -c /usr/local /php/bin /php test.php

Comme indiqué ci-dessous :

__ctype_tolower_loc prend le plus de temps ! J'ai vérifié ce que fait la fonction de bibliothèque __ctype_tolower_loc : la compréhension simple est de convertir les chaînes en minuscules, cela signifie-t-il donc que les chaînes de comparaison in_array ne sont pas sensibles à la casse ? En fait, cet appel de fonction a peu de lien avec notre in_array. Concernant l'implémentation de in_array, il vaut mieux jeter un œil au code source de PHP, je vais probablement le comprendre plus en profondeur. Bienvenue à communiquer avec moi, veuillez me corriger si j'écris quelque chose de mal.

——————2013.08.29 ligne de démarcation————————

J'ai lu le code source suivant de PHP 5.4.10 dans la soirée, et je suis intéressé dans in_array C'est tellement gros, haha. Il se trouve à la ligne 1248 de ./ext/standard/array.c Vous pouvez voir qu'il appelle la fonction php_search_array ci-dessous ajuste également cela, mais le dernier paramètre est différent ! Après quelques recherches, dans le cas d'une comparaison lâche in_array, il a finalement appelé la fonction zendi_smart_strcmp (vraiment une fonction "intelligente") pour comparaison, située dans ./Zend/zend_operators.c. Nous avons utilisé ltrace pour convertir un grand nombre de données capturées. en entiers. L'opération est le comportement de is_numeric_string_ex.



La fonction is_numeric_string_ex est définie dans ./Zend/zend_operators.h Après un tas de jugements et de conversions, strtol est appelé à la ligne 232, c'est-à-dire la fonction système que nous avons. mentionné dans l'article convertit une chaîne en un entier long, avec des images et des faits

Recommandations associées :

Encore une fois, j'ai rencontré des caractères tronqués

lorsque PHP a inséré le chinois dans MYSQL et l'a affiché.

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!