PHP 最適化ケースを記録する

PHP 最適化の事例を思い出してください

Web サイト アーキテクチャの紹介:
現在、多くの企業が Web サイト サーバー アーキテクチャを構築するために lnmp または Lamp を使用しています。さまざまな Web サイトのサービス アーキテクチャ; nginx ベースのパフォーマンスは Apache より優れています. 現段階で、多くの企業が Apache を nginx に徐々に置き換えています. 結局のところ、nginx には高可用性構成、リバース プロキシなどが付属しています。非常に優れています。

Lnmp Web サイト サーバー アーキテクチャは、実際には linx nginx mysql php アーキテクチャ システムです。アーキテクチャのインストールについては詳しく説明しません。次に、私が遭遇したケースについて話しましょう。

ケース:

ある日、バックグラウンドで作業している同僚が、バックグラウンド アクセスが非常に遅く、時々 502 が表示されると言いました。間違い。それから私はそれを技術上の上司に報告し、その後私が対処してくれることを発見し（その時私はお茶を飲んでいました）、その後、またやることがあったと悟りました。

分析:

その後、私はその同僚に直接行き、ネットワークが原因かどうか尋ねました。また、他の同僚にも電話して訪問させましたが、依然として訪問は忙しかったです。この時点で、物事はそれほど単純ではないことがわかりました。同社は lnmp ウェブサイト サーバー アーキテクチャを使用していますが、これまであまり最適化を行っていませんでした。次に、ウェブサイトのサービス アーキテクチャを最適化する必要があります。

1. ケース分析。

アクセスが遅く、直接アクセスできないこともあったので、以前は問題なかったと考えられますが、突然問題が発生しました。nginx の障害が原因であると考えられます。および php が応答します。その理由は、他のドメイン名を持つ Web サイトへのユーザー接続数の大幅な増加が原因である可能性があります。その後、問題の根本原因を見つけて解決し、最適化することができます。次に、あなた自身の経験と Baidu を頼りに問題を解決してください。

2. 問題解決とプロセス分析

1、Nginx最適化:

1、nginx のログを確認し、エラーを見つけます

`$` cat `/usr/local/nginx/logs/error.log` | grep `error`

エラーは見つかりませんでした、正常です

バックグラウンド ドメイン名の access.logs を確認してください

$ cat /var/log/access_nging.log | grep error

(画像のキャプチャが間に合わず、ログがフラッシュされました。ログはローカルに作成されており、定期的に切り取って削除してください)

エラー メッセージはログ ログにあることがわかり、12 個以上の 502 エラーがあることがわかりました。問題が見つかりました。

2、問題分析と nginx最適化

1、nginx のオープン ファイル制限が原因。

1) まず、nginx でファイルを開く問題の考えられる原因を考え、nginx で開くファイルの数を増やしました。

nginx 設定ファイルを入力すると、その数が判明しました。開いているファイルの数は 4096 でした。予想どおり、開いているファイルの数が最適に調整されていません。これは、この理由による可能性があります。 4096 を 51200 に変更する必要があります; nginx

vim /usr/local/nginx/conf/nginx.conf
worker_rlimit_nofile 51200;
events {
worker_connections 51200;
}
service nginx relaod

2 を保存して再ロードしてください)、Linux システム ファイル制限

nginx のオープン ファイル構成を変更しましたが、これは役に立たない可能性があります。システムを確認するには、開いているファイルの数を制限します

ulimit –n

システム内で開いているファイルの数も 4096 であることがわかります。次に、数値を変更します。システム内で開いているファイルの数を削除し、構成を永続的にします。

設定ファイルを入力します

vim /etc/security/limits.conf

パラメータを変更します:

• soft nofile 65535
• hard nofile 65535
• soft nproc 65535
• hard nproc 65535

  注: システム制限は自由に変更できます。開いているファイルの数より大きくする必要があるだけです。 nginxで。

3、nginx の fastcgi 接続時間が短すぎます。

一般的に、nginx は php に応答し、FastCGI インターフェイスを通じてそれを呼び出すため、fastcgi パラメーターの設定は非常に重要です。HTTP サーバーが動的プログラムに遭遇するたびに、それを FastCGI プロセスに直接配信できます。多くの PHP Web ページでは動的プログラムが使用されています。したがって、fastcgi の設定も重要な役割を果たします。したがって、これは最適化に不可欠な部分です。

nginx.conf 設定ファイルを入力します

vim /usr/local/nginx/conf/nginx.conf

fastcgi の接続、送信、および読み取りパラメーターの時間を変更します。

Reload nginx

service nginx reload

4、ドメイン名テストにアクセスします。

ドメイン名に再度アクセスすると、Web ページが読み込まれており、何度かアクセスした後、アクセスは安定していましたが、依然としてアクセスが少し遅いことがわかりました。この時点で、問題の原因が PHP にあることを指摘し、PHP 最適化の次のステップに進むことができます。

#2、Php 最適化:

#1、PHP ログを確認

まず、nginx と同じように、ログを確認する必要があります。

tail -n 100 /usr/local/php/var/log/php-fpm.log

ログを見ると、php ログに警告が表示されていることがわかります

警告: [プール www] がビジーのようです (pm.start_servers または pm.min/max_spare_servers を増やす必要があるかもしれません)

アラームの意味から、php にアラームがあることがわかります。 php.pm.start_servers または pm.min/max_spare_servers の値を増やすように求められます。

2、原因分析

首先我们，看到日志只是出现这个警告，证明还不是很严重，至于为什么出现源码交易这个警告，接下来我们一起分析一下。

首先我们很明确的知道，pm.start_servers,、pm.min/max_spare_servers在php里面是起着啥作用先，为什么会出现这个警告。我先把的以前的配置参数贴一下。

接下来我们分析一下这几个参数的作用：

参数分析：

· pm= dynamic 表示php启用的动态模式 注： php有动态和静态(static)两种工作模式，默认是动态模式。

· pm.max_children 表示静态下最大线程数

· pm.start_servers 表示动态下启动时的线程数，该参数大于pm.min_spare_servers，小于pm.max_spare_servers

· pm.min_spare_servers 表示动态下最小空闲线程数

· pm.max_spare_servers 表示动态下最大空闲线程数

工作模式：

Static模式

当工作模式设置为静态后，就只有pm.max_children项有效，即表示php-fpm工作时一直保持的线程数。

Dynamic 模式

动态模式下，与他相关的参数有pm.start_servers、pm.min_spare_servers 、pm.max_spare_servers，分别表示开启的php进程数，最小的进程数、与最大的进程数。

模式比较：

静态模式的话，比较适合一些内存比较大一点的服务器，8G及以上的，因为对于比较大内存的服务器来说，设置为静态的话会提高效率。

动态模式适合小内存机器，灵活分配进程，省内存。可以让php自动增加和减少进程数，不过动态创建回收进程对服务器也是一种消耗。

3、php参数优化

首先我们需要考虑一下问题，如何去调试参数，达到优化的目的呢，一般来说开始的时候一个php-fpm进程只占用3M左右内存，但是运行一段时间后就会上升到20-40M，这是因为PHP程序在执行完成后，或多或少会产生内存的泄露。

所以按理来说php的最大的进程数，大概是本地内存/40，因为也要考虑系统占用内存的的这种情况，我们不能直接把除处理的结果，当成的最大进程数，不然你会死翘翘的。

我的服务器是8G内存的，所以按理来说是，最大的php进程数是200左右，所以按这个参数我做了一下调整：

采用静态模式，最大进程数设为125-150之间，搞定。

重新加载php

service php-fpm relod

查看进程数：

netstat -anpo | grep php-fpm | wc -l

`128`

效果达到了

4、结果

重新访问，发现访问php页面快了很多，查看日志，没出现告警了，后台访问也好了。

3、压测

一个网站的性能好不好，承受量有多高，这个我们可以通过压测去，去获取数据，我这里简单介绍ab工具来做压测，用法如下

ab -n 1000000   -c 10000  (一个php文件)

-n参数表示 你压力测试 总量

-c参数表示 你的模拟的并发用户数

Ab压力测试工具，是apache自带的，用起来也方便，只要本地有，就可以远程测你的服务器的性能了。个人觉得还是可以了，下面是模拟一千个用户访问100000次的结果，但然你自己压测的时候，慢慢的提升参数，测试你的网站的瓶颈。

以上がPHP 最適化ケースを記録するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。