Einführung in die Website-Architektur:
Viele Unternehmen verwenden jetzt lnmp oder Lamp als Website-Serverarchitektur. Wir sind mit der Servicearchitektur dieser beiden Websites relativ vertraut Besser als Apache. Viele Unternehmen ersetzen Apache nach und nach durch Nginx. Schließlich sind die integrierte Hochverfügbarkeitskonfiguration, der Reverse-Proxy und andere Funktionen sehr wichtig.
Die Lnmp-Website-Serverarchitektur ist eigentlich ein Linx+Nginx+MySQL+PHP-Architektursystem. Ich werde nicht näher auf die Architekturinstallation eingehen. Lassen Sie uns als Nächstes über einen Fall sprechen, auf den ich gestoßen bin
Fall:
Eines Tages sagte ein Kollege im Backend, dass der Backend-Zugriff sehr langsam sei und manchmal 502-Fehler aufgetreten seien. Dann habe ich es meinen technischen Vorgesetzten gemeldet und dann gefunden, dass ich mich darum kümmere (ich trank gerade Tee), und dann wusste ich, dass ich wieder etwas zu tun hatte.
Analyse:
Dann bin ich direkt zum Kollegen gegangen und habe gefragt, ob es am Netzwerk liegt. Ich habe auch andere Kollegen zu Besuch gerufen, aber es gab immer noch ein Problem mit dem besetzten Zugang. Zu diesem Zeitpunkt wusste ich, dass die Dinge nicht so einfach waren. Das Unternehmen verwendet die LNMP-Website-Serverarchitektur und hat bisher nicht viel Optimierung vorgenommen. Als nächstes müssen wir die Servicearchitektur der Website optimieren
1. Fallanalyse.
Wir können davon ausgehen, dass es vorher kein Problem war, da der Zugriff langsam ist und manchmal nicht direkt darauf zugegriffen werden kann, aber jetzt gibt es plötzlich ein Problem, das daran liegen muss, dass unser Nginx und PHP nicht reagieren können Der Grund kann ein anderer sein. Dies wird durch den enormen Anstieg der Anzahl der Benutzerverbindungen zu Domainnamen-Websites verursacht. Dann können wir die Ursache des Problems finden, es lösen und optimieren. Dann verlassen Sie sich bei der Lösung des Problems auf Ihre eigene Erfahrung und Baidu. 2. Problemlösung und Prozessanalyse
Protokollieren, Fehler finden`$` cat `/usr/local/nginx/logs/error.log` | grep `error`
Nein Fehler gefunden, normal
Überprüfen Sie die access.logs des Hintergrunddomänennamens$ cat /var/log/access_nging.log | grep error
(Das Bild wurde nicht rechtzeitig aufgenommen, das Protokoll wurde gebürstet, das Protokoll wurde lokal ausgeschnitten und regelmäßig gelöscht)Ich habe festgestellt, dass das Protokoll kann be Die Fehlermeldung wurde gefunden und es gab mehr als ein Dutzend 502-Fehler. Habe das Problem gefunden. 2, Problemanalyse und Nginx
Optimierung1 Verursacht durch die Begrenzung der Anzahl geöffneter Dateien in Nginx. 1) Zunächst dachten wir über den möglichen Grund für das Problem beim Öffnen von Dateien in Nginx nach und erhöhten die Anzahl der geöffneten Dateien in Nginx. Geben Sie die Nginx-Konfigurationsdatei ein und stellten fest, dass die Anzahl der geöffneten Dateien 4096 betrug. Wie erwartet wurde die Anzahl der geöffneten Dateien nicht auf den optimalen Wert angepasst. Dies kann der Grund sein. Wir müssen 4096 auf 51200 ändern; Nginx speichern und neu laden offene Dateien
ulimit –n
Wir können sehen, dass die Anzahl der offenen Dateien im System ebenfalls 4096 beträgt. Als nächstes ändern wir die Anzahl der offenen Dateien im System und machen die Konfiguration dauerhaft.
Geben Sie die Konfigurationsdatei ein.
vim /etc/security/limits.conf 5
Hinweis: Systemeinschränkungen Sie können Ändere es nach Belieben, ich brauche nur, dass es größer ist als die Anzahl der geöffneten Dateien in Nginx.3, Fastcgi
von Nginxwird durch eine zu kurze Verbindungszeit verursacht.
Im Allgemeinen antwortet Nginx auf PHP und ruft es über die FastCGI-Schnittstelle auf. Daher ist die Konfiguration der FastCGI-Parameter sehr wichtig. Jedes Mal, wenn der HTTP-Server auf ein dynamisches Programm trifft, kann es direkt zur Ausführung an den FastCGI-Prozess übermittelt werden Das erhaltene Ergebnis wird an den Browser zurückgegeben, und viele PHP-Webseiten verwenden dynamische Programme. Daher spielt auch die Konfiguration von fastcgi eine entscheidende Rolle. Dies ist also ein wesentlicher Bestandteil der Optimierung. Geben Sie die Konfigurationsdatei nginx.conf einvim /usr/local/nginx/conf/nginx.confÄndern Sie die Zeit der Fastcgi-Verbindungs-, Sende- und Leseparameter auf 300. Die Konfiguration lautet wie folgt: Neu laden NginxService Nginx Reload
4
- , Zugriff auf den Domänennamentest.
- Ich habe den Domainnamen erneut besucht und festgestellt, dass die Webseite geladen wurde. Ich habe sie mehrmals besucht und festgestellt, dass der Zugriff immer noch etwas langsam war, obwohl der Zugriff stabil war. An diesem Punkt können wir das Problem auf PHP verweisen und mit dem nächsten Schritt der PHP-Optimierung fortfahren.
- 2
, PHP-Optimierung:
1, PHP-Protokoll überprüfenZuerst müssen wir dasselbe wie Nginx tun, wir müssen zuerst das Protokoll überprüfen. tail -n 100 /usr/local/php/var/log/php-fpm.logIm Protokoll können wir feststellen, dass eine Warnung im PHP-Protokoll erscheint
WARNUNG: [pool www] scheint beschäftigt zu sein (Sie Möglicherweise müssen Sie pm.start_servers oder pm.min/max_spare_servers erhöhen. Aus der Bedeutung des Alarms wissen wir, dass in PHP ein Alarm vorliegt, und er fordert uns auf, den Wert von php, pm.start_servers oder zu erhöhen 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次的结果，但然你自己压测的时候，慢慢的提升参数，测试你的网站的瓶颈。