Introduction à l'architecture de site Web :
De nombreuses entreprises utilisent désormais lnmp ou lamp pour construire leur architecture de serveur de site Web. Ces deux-là, nous sommes tous. familier avec l'architecture de service de divers sites Web ; les performances basées sur nginx sont meilleures que celles d'Apache. À ce stade, de nombreuses entreprises remplacent progressivement Apache par nginx. Après tout, nginx a sa propre configuration de haute disponibilité, son proxy inverse, etc. . Les fonctions sont tout à fait remarquables.
L'architecture du serveur de site Web Lnmp est en fait le système d'architecture linx+nginx+mysql+php. Je n'entrerai pas dans les détails de l'installation de l'architecture. Parlons ensuite d'un cas que j'ai rencontré
Cas :
Un jour, un collègue en arrière-plan m'a dit que l'accès en arrière-plan était très lent, et parfois 502 apparaissait. erreur. Ensuite, je l'ai signalé à mes supérieurs techniques, puis je me suis trouvé pour m'en occuper (je buvais du thé à ce moment-là), et puis j'ai su que j'avais encore quelque chose à faire.
Analyse :
Ensuite, je suis allé directement voir le collègue et lui ai demandé si c'était à cause du réseau. J'ai également appelé d'autres collègues pour lui rendre visite, mais il est quand même apparu que. la visite était une question chargée. À ce stade, je savais que les choses n’étaient pas si simples. L'entreprise utilise l'architecture du serveur du site Web lnmp et n'a pas fait beaucoup d'optimisation auparavant. Nous devons ensuite optimiser l'architecture des services du site Web
1. Analyse de cas.
Nous pouvons penser que comme l'accès est lent et que parfois l'accès direct ne peut pas être effectué, ce n'était pas un problème avant, mais maintenant le problème survient soudainement, il doit être causé par la panne de notre nginx et php pour répondre. , la raison peut être due à l'augmentation considérable du nombre de connexions d'utilisateurs à des sites Web portant d'autres noms de domaine. Nous pouvons alors trouver la cause première du problème, le résoudre et l’optimiser. Fiez-vous ensuite à votre propre expérience et à Baidu pour résoudre le problème.
2. Résolution de problèmes et analyse des processus
1, NginxOptimisation :
1, vérifiez le log de nginx pour trouver l'erreur
`$` cat `/usr/local/nginx/logs/error.log` | grep `error`
Aucune erreur trouvée, normal
Vérifiez les access.logs du nom de domaine en arrière-plan
$ cat /var/log/access_nging.log | grep error
(La photo n'a pas été prise à temps, le journal a été brossé, et le journal a été créé localement (coupé et supprimé régulièrement)
J'ai constaté que le message d'erreur se trouvait dans le journal et qu'il y avait plus d'une douzaine d'erreurs 502. J'ai trouvé le problème.
2, analyse des problèmes et nginx optimisation
1. l'ouverture des fichiers dans nginx a été provoquée.
1). Tout d'abord, nous avons réfléchi à la cause possible du problème d'ouverture des fichiers dans nginx et avons augmenté le nombre de fichiers ouverts dans nginx
Entrez le fichier de configuration nginx et avons trouvé cela. le nombre de fichiers ouverts était de 4096. Comme prévu, le nombre de fichiers ouverts n'est pas ajusté de manière optimale, ce qui peut être dû à cette raison. Nous devons changer 4096 en 51200 ; enregistrer et recharger nginx
vim /usr/local/nginx/conf/nginx.conf
worker_rlimit_nofile 51200;
events {
worker_connections 51200;
}
service nginx relaod2), restrictions de fichiers système Linux
Nous avons modifié la configuration des fichiers ouverts de nginx, ce qui peut ne pas être utile. jetez un œil au système Limiter le nombre de fichiers ouverts
ulimit –n
Nous pouvons voir que le nombre de fichiers ouverts dans le système est également de 4096. Ensuite, nous modifions le nombre de ouvrez les fichiers dans le système et rendez la configuration permanente.
Entrez le fichier de configuration
vim /etc/security/limits.conf
Modifier les paramètres :
- soft nofile 65535
- hard nofile 65535
- soft nproc 65535
- hard nproc 65535
Remarque : la limite du système peut être modifiée à volonté. J'ai juste besoin qu'elle soit supérieure au nombre de fichiers ouverts. dans nginx.
3, fastcgi de nginx est causé par la connexion courte temps .
Généralement, nginx répond à php et l'appelle via l'interface FastCGI, donc la configuration des paramètres fastcgi est très importante chaque fois que le serveur HTTP rencontre un programme dynamique, il peut être directement transmis au processus FastCGI. pour l'exécution. , puis renvoie le résultat au navigateur, et de nombreuses pages Web PHP utilisent des programmes dynamiques. Par conséquent, la configuration de fastcgi joue également un rôle essentiel. Cela fait donc partie intégrante de l’optimisation.
Entrez le fichier de configuration nginx.conf
vim /usr/local/nginx/conf/nginx.conf
Modifiez l'heure des paramètres de connexion, d'envoi et de lecture de fastcgi en 300, la configuration est la suivante :
reload nginx
service nginx reload
4, accédez au test du nom de domaine.
J'ai revu le nom de domaine et j'ai constaté que la page Web avait été chargée. Après l'avoir visité plusieurs fois, j'ai trouvé que l'accès était encore un peu lent, même si l'accès était stable. À ce stade, nous pouvons signaler le problème à PHP et passer à l’étape suivante de l’optimisation PHP.
2, Optimisation Php :
1, vérifier le journal php
Tout d'abord, nous devons faire la même chose que nginx, nous devons d'abord vérifier le journal.
tail -n 100 /usr/local/php/var/log/php-fpm.log
Dans le journal, nous pouvons constater qu'un avertissement apparaît dans le journal php
ATTENTION : [pool www] semble occupé (vous devrez peut-être augmenter pm.start_servers, ou pm.min/max_spare_servers)
De par la signification de l'alarme, nous savons qu'il y a une alarme en php, et on nous demande d'augmenter php La valeur de pm.start_servers, ou 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次的结果，但然你自己压测的时候，慢慢的提升参数，测试你的网站的瓶颈。