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 relaod2 を保存して再ロードしてください)、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次的结果，但然你自己压测的时候，慢慢的提升参数，测试你的网站的瓶颈。