PHP 최적화 사례 기록

웹사이트 아키텍처 소개:
현재 많은 회사에서 웹사이트 서버 아키텍처로 lnmp 또는 lamp를 사용하고 있습니다. 우리는 nginx를 기반으로 하는 이 두 웹사이트의 서비스 아키텍처에 비교적 익숙합니다. 이 단계에서는 많은 회사들이 점차적으로 Apache를 nginx로 교체하고 있습니다. 결국 nginx에 내장된 고가용성 구성, 역방향 프록시 및 기타 기능은 상당히 뛰어납니다.

Lnmp 웹사이트 서버 아키텍처는 실제로 linx+nginx+mysql+php 아키텍처 시스템입니다. 아키텍처 설치에 대해서는 자세히 설명하지 않겠습니다. 다음으로 제가 겪은 사례를 말씀드리겠습니다

사례:

어느 날 백엔드에 있는 동료가 백엔드 접속이 너무 느리고 가끔 502에러가 발생한다고 하더군요. 그러다가 기술상급자에게 다시 보고하고 나서 처리하라고 찾아냈는데(당시 차를 마시고 있던 중이었습니다) 그러다가 또 할 일이 있다는 걸 알았습니다.

분석:

그리고 나서 동료에게 직접 가서 네트워크 때문이냐고 물었고 다른 동료들에게도 전화해서 방문했지만 여전히 바쁜 문제가 있었습니다. 이 시점에서 나는 상황이 그렇게 간단하지 않다는 것을 알았습니다. 회사는 lnmp 웹사이트 서버 아키텍처를 사용하며 이전에는 많은 최적화를 수행하지 않았습니다. 다음으로 웹사이트의 서비스 아키텍처를 최적화해야 합니다

1. 사례 분석.

접속 속도가 느리고 가끔 직접 접속이 안되는 경우가 있어서 이전에는 문제가 되지 않았는데 갑자기 문제가 발생한 것은 우리의 nginx와 php가 응답하지 못해서 발생하는 것이라고 생각할 수 있습니다. 이유는 다른 것일 수 있습니다. 이는 도메인 이름 웹사이트에 대한 사용자 연결 수가 크게 증가했기 때문에 발생합니다. 그러면 문제의 근본 원인을 찾아 해결하고 최적화할 수 있습니다. 그런 다음 자신의 경험과 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

(사진이 제 시간에 안 찍혔고, 로그가 브러싱됐고, 로그가 로컬에서 잘려서 정기적으로 삭제됐어요)

로그가 알 수 있는 걸 발견했어요 해당 오류 메시지가 발견되었으며, 502 오류가 12개 이상 있었습니다. 문제를 발견했습니다.

2, 문제 분석 및 nginxoptimization

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의 열린 파일 구성을 변경했는데 이는 유용하지 않을 수 있습니다. open files

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 웹 페이지는 동적 프로그램을 사용합니다. 따라서 fastcgi의 구성도 중요한 역할을 합니다. 따라서 이것은 최적화의 필수적인 부분입니다.

nginx.conf 구성 파일을 입력하세요

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

fastcgi의 연결, 전송 및 읽기 매개변수 시간을 300으로 변경합니다. 구성은 다음과 같습니다.

다시 로드 nginx

service nginx reload

4, 액세스 도메인 이름 테스트.

도메인 이름을 다시 방문하여 웹페이지가 로드된 것을 확인했습니다. 여러 번 방문하여 액세스가 안정적이기는 하지만 여전히 액세스가 약간 느린 것을 확인했습니다. 이 시점에서 우리는 PHP에 문제가 있음을 지적하고 PHP 최적화의 다음 단계를 계속할 수 있습니다.

2, Php Optimization:

1, check php log

우선 nginx와 동일하게 해야 하는데, 먼저 로그를 확인해야 합니다.

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

로그에서 PHP 로그에 경고가 나타나는 것을 확인할 수 있습니다

경고: [pool 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次的结果，但然你自己压测的时候，慢慢的提升参数，测试你的网站的瓶颈。