Comment résoudre l'erreur de syntaxe dans les rapports à haute concurrence en PHP

Solution à l'erreur de syntaxe signalée par PHP avec une simultanéité élevée : 1. Vérifiez le nombre d'accès ou de connexions configurés de nginx, et augmentez les deux paramètres de nginx 2. Confirmez si le processus de travail de php-fpm est suffisant, et puis augmentez le nombre de processus worker_connections Quantité ; 3. Désactivez simplement le journal lent enregistré.

L'environnement d'exploitation de ce tutoriel : système Windows 10, PHP version 8.1, ordinateur Dell G3.

Comment résoudre l'erreur de syntaxe dans les rapports à haute concurrence en php ?

Nginx+Php high simultané reporting 502, 504 résolution de problèmes :

Récemment aidé l'entreprise à optimiser le projet PHP. Baidu tout en optimisant. Ce projet a un grand nombre de visites (en moyenne plus de 80 000 requêtes par minute).

Utilisation de trois serveurs AWS. Deux 16G à 8 cœurs et un 16G à 4 cœurs. Le petit exécute Nginx et exécute un petit nombre de processus php-fpm. En gros, installez-le et raccrochez-le. Les accès sont tous 502 et 504. Parce qu'il n'y a aucun problème avec le projet et que le test a déjà été exécuté. Ensuite, j'ai commencé à chercher des problèmes sur Baidu.

1. On soupçonne que le nombre d'accès ou de connexions configurés de nginx est trop petit pour être géré, alors augmentez les deux paramètres de nginx.

Le nombre maximum de connexions autorisées par chaque processus. Théoriquement, le nombre maximum de connexions par serveur nginx est worker_processes*worker_connections

 worker_connections 5000；

Le nombre maximum de descripteurs de fichiers ouverts par un processus nginx. La valeur théorique doit être le nombre maximum de. fichiers ouverts (ulimit - n) Divisez par le nombre de processus nginx

worker_rlimit_nofile 20000;

Délai d'expiration et cache des requêtes PHP, etc.

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 256k;

Redémarrez nginx après l'avoir configuré. . Mais lorsque je l’ai testé, il n’y a eu aucune réponse.

2. Il s'agit probablement d'un problème de configuration PHP.

Confirmez si le processus de travail de php-fpm est suffisant. S'il ne suffit pas, cela signifie qu'il n'est pas activé.

Calculez le nombre de processus de travail ouverts :

ps -ef | grep 'php-fpm'|grep -v 'master'|grep -v 'grep' |wc -l

Calculez les processus de travail utilisés et les requêtes en cours. processed

netstat -anp | grep 'php-fpm'|grep -v 'LISTENING'|grep -v 'php-fpm.conf'|wc -l

Si les deux ci-dessus Si la valeur est proche, vous pouvez envisager d'augmenter le nombre de processus worker_connections

et de modifier le nombre de processus php dans php-fpm.conf. Peu importe que vous augmentiez ou diminuiez ces paramètres. . . . Désespéré!

Modification du niveau de journalisation log_level = debug dans php-fpm.conf. J'ai vu une erreur dans le fichier error_log :

[29-Mar-2014 22:40:10] ERROR: failed to ptrace(PEEKDATA) pid 4276: Input/output error (5)
[29-Mar-2014 22:53:54] ERROR: failed to ptrace(PEEKDATA) pid 4319: Input/output error (5)
[29-Mar-2014 22:56:30] ERROR: failed to ptrace(PEEKDATA) pid 4342: Input/output error (5)

Alors, j'ai recommencé à rechercher cette erreur sur Google. Retrouvez l'article (http://www.mamicode.com/info-detail-1488604.html). Il est indiqué ci-dessus que le journal lent enregistré doit être désactivé ; slowlog = /var/log/php-fpm/slow.log; request_slowlog_timeout = 15s. A cette époque, j'ai réalisé que PHP enregistre également les requêtes lentes lors des journaux d'accès. Ensuite, ouvrez le fichier journal lent. Il a été constaté que tous les journaux d'erreurs étaient causés par PHP demandant Redis. . .

La cause du problème est trouvée. Lorsque PHP demande des données redis, il se peut que trop de connexions soient demandées. Problèmes causés par l'échec de la connexion de Redis. . Parce que le métier ici est relativement complexe, la clé Redis est divisée en plusieurs champs. La requête floue est utilisée lors de l'interrogation. Tout cela entraîne une diminution des performances de Redis et un grand nombre de requêtes ultérieures ne peuvent pas se connecter à Redis. Parce que le code de lien vers Redis a été modifié par moi. . J'ai donc restauré le code original pour demander MySQL. .

À l'heure actuelle, le projet fonctionne normalement et le CPU de chaque serveur est fondamentalement proche de 100 %. Je crains qu'il y ait des problèmes, que le processeur soit plein et que la demande de connexion MySQL ne puisse pas y résister. . . Optimisons-le plus tard ! ! ! !

Apprentissage 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!