PHP での同時実行性の高いレポートでの構文エラーを解決する方法

php の同時実行性の高さによって報告される構文エラーの解決策: 1. nginx の設定されたアクセス数または接続数を確認し、nginx の 2 つのパラメーターを追加します; 2. php-fpm のワーカー プロセスが実行されているかどうかを確認します。十分である場合は、worker_connections プロセスの数を増やします。 3. 記録された低速ログを無効にします。

このチュートリアルの動作環境: Windows 10 システム、PHP バージョン 8.1、Dell G3 コンピューター。

php での同時実行性の高いレポートの構文エラーを解決するにはどうすればよいですか?

Nginx Php のパフォーマンスが高く、502 および 504 の問題解決を同時に報告します:

最近、私は会社の PHP プロジェクトの最適化を支援しています。 Baidu の最適化中。このプロジェクトへのアクセス数は非常に多くなります (1 分あたりの平均リクエスト数は 80,000)。

3 台の aws サーバーを使用しました。 8 コア 16G が 2 つと 4 コア 16G が 1 つ。小さいものは Nginx を実行し、少数の php-fpm プロセスを実行します。基本的には立てて吊るしておきます。アクセスはすべて 502 と 504 です。プロジェクトに問題はなく、テストは以前に実行されているためです。それから、Baidu で問題を探し始めました。

1. nginx の設定されたアクセスまたは接続の数が小さすぎて処理できないと考えられる場合は、nginx の 2 つのパラメーターを増やしてください。

各プロセスによって許可される接続の最大数。理論的には、nginx サーバーあたりの最大接続数は、worker_processes*worker_connections

 worker_connections 5000；

nginx プロセスによって開かれるファイル記述子の最大数です。理論値は、開いているファイルの最大数 (ulimit -n) を nginx プロセスの数で割った値です。

worker_rlimit_nofile 20000;

PHP リクエストのタイムアウトやキャッシュなど。

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;

設定後に nginx を再起動します。それをアップします。 。しかし、試してみると全く反応がありませんでした。

2. PHP の設定に問題があると考えられます。

php-fpm のワーカープロセスが十分であるか確認し、不足している場合は有効になっていないことを意味します。

開いているワーカープロセスの数を計算します:

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

使用中のワーカープロセス、処理中のリクエストを計算します

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

上記 2 つの値が近い場合は、worker_connections プロセスの数を増やすことを検討できます

およびphp-fpm.conf内のphpプロセスの数を変更します。これらのパラメータを上げても下げても関係ありません。 。 。 。絶望的な！

php-fpm.conf のログ レベル log_level = debug を変更しました。 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)

そこで、このエラーをもう一度 Google で調べ始めました。記事を見つけてください (http://www.mamicode.com/info-detail-1488604.html)。上記では、記録されたスローログを無効にする必要があると述べています (slowlog = /var/log/php-fpm/slow.log; request_slowlog_timeout = 15s)。この時、PHPでは遅いリクエストもアクセスログに記録していることに気づきました。次に、低速ログ ファイルを開きます。すべてのエラー ログは、PHP が Redis を要求したことが原因であることが判明しました。 。 。

問題の原因が判明しました。PHP が Redis データをリクエストするときに、リクエストされる接続が多すぎることが原因であるはずです。 Redis の接続失敗によって引き起こされる問題。 。ここでのビジネスは比較的複雑であるため、redis キーは複数のフィールドに結合されています。ファジークエリはクエリ時に使用されます。これらすべてが Redis のパフォーマンスの低下につながり、後続の多数のリクエストが Redis に接続できなくなります。 Redisにリンクするコードを私が変更したためです。 。そこで、mysql をリクエストするための元のコードを復元しました。 。

現在、プロジェクトは正常に稼働しており、各サーバーのCPU使用率は基本的に100%に近い状態です。問題が発生してCPUがいっぱいになり、MySQLの接続リクエストに耐えられなくなるのではないかと心配です。 。 。あとで最適化しましょう！ ！ ！ ！

推奨学習: 「PHP ビデオ チュートリアル 」

以上がPHP での同時実行性の高いレポートでの構文エラーを解決する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。