첫째, 이것은 진단 접근법만큼 답이 아닙니다.

이것은 결코 포괄적 인 것이 아니며 가까운 곳에서도 시작점 일뿐입니다.

첫 바이트까지의 시간

TTFB (Time to First byte)에는 많은 구성 요소가 있습니다.

• DNS 조회 : 도메인의 IP 주소 찾기 (개선 가능 : 더 많은 / 분산 / 응답 DNS 서버)
• 연결 시간 : 서버에 대한 소켓을 열고 연결 협상
• 대기 중 : 첫 번째 바이트를 전송하기 전에 초기 처리가 필요합니다 (즉, 개선해야 할 위치-동적 내용에 가장 중요합니다).

ApacheBench 출력을 보면 다음 사항도 볼 수 있습니다.

• 처리 : 이것은 대기 + 컨텐츠의 완전한 전송의 합계입니다 (전송 시간이 수신 된 데이터의 양을 다운로드 할 것으로 예상되는 것보다 상당히 긴 경우 추가 처리 (첫 번째 바이트 수신 후)가 발생합니다 (예 : 페이지는 컨텐츠를 플러시 함)

구성 요소를 제거하기위한 비교

몇 가지 예외가 있지만 문제는 일반적으로 지나치게 복잡하거나 비효율적 인 코드 또는 잘못 구성된 MySQL로 인한 백엔드 처리에 있습니다.

이 문제에 접근하는 좋은 방법은 설정의 다양한 측면을 제거하는 일련의 비교를 통하는 것입니다. 좋은 비교는 문제를 좁히기 위해 가능한 한 일정하게 유지해야합니다. 현재 다음 비교를 제공했습니다.

1. 기존 서버와 새 서버에서 실행되는 동일한 (복제 된) 사이트 :
   • 차이 : 서버
   • 결과 : 오래된 서버가 빠릅니다. 새로운 서버가 느리다
   • 참고 : 여기에 필요한 것은 사용 된 스택 (Nginx 등)과 하드웨어 측면에서 이들 서버 간의 차이점을 수량화하는 것입니다 (이전 서버는 더 강력한 머신이기 때문에 더 빠른 서버입니까?).
   • 결론 : 코드가 올바른 설정에서 빠르게 실행될 수 있습니다.
2. 새 서버에서 테스트 사이트와 전체 사이트
   • 차이점 : 컨텐츠, 테마, 플러그인 등
   • 결과 : 테스트 사이트가 빠르며 전체 사이트가 느립니다.
   • 참고 : 이론적 으로이 테스트는 DNS, 네트워크, 심지어 nginx / php / mysql 설정과 같은 설정의 많은 측면을 제거하는 데 도움이되지만 상당히 공정하지는 않습니다.
   • 결론 : 추가 컨텐츠는 성능에 상당한 영향을 미칩니다.

이상적인 테스트는 전체 사이트를 복제 한 다음 한 기사와 관련 주석을 제외한 모든 내용을 삭제하는 것입니다. 이 테스트의 요점은 많은 양의 컨텐츠가 문제인지 또는 설정의 다른 측면 (wordpress 플러그인, 테마 등)이 원인인지 결정적으로 결정하는 것입니다. 동일한 (새로운) 서버에서 동일한 사이트 (동일한 길이 등)를로드하는 것과 동일한 사이트의 성능을 본질적으로 비교하면 전체 사이트 컨텐츠 만 다릅니다 (예 : 일부 플러그인이 그렇지 않을 가능성이 있음) 콘텐츠 증가에 따라 확장 가능).

아무것도 변경하지 않고 다른 비교를 수행 할 수 있습니다.

• 원격 위치와 로컬에서 테스트-네트워크, 대기 시간, DNS 등이 원인인지 식별하는 데 도움이됩니다.
  • 이미 (어느 정도)이 작업을 수행했으며 대부분 네트워크 문제가 없다고 결론 내 렸습니다.
• 니스 (예 : 포트 80)와 nginx를 직접 테스트 (포트 8080)-테스트간에 구성을 변경하지 말고 올바른 포트만 사용하십시오. 이것은 니스의 영향을 보여줍니다. Varnish는 캐싱 계층이므로 첫 번째 요청 이후 모든 요청을 매우 빠르게 처리해야합니다. 본질적으로 백엔드와 동적 페이지를 생성하는 데 필요한 처리를 무시하고 캐시 된 사본을 매우 빠르게 제공해야합니다.
  • 이 작업을 수행했지만 (로컬은 아니지만) 니스는 성능에 상당한 긍정적 영향을 미칩니다.

백엔드 튜닝

이 시점에서 문제를 발견했거나 백엔드에 있다고 결론을 내 렸습니다. 그러면 Nginx, PHP 또는 MySQL이 남습니다.

(나는 당신의 병목 현상은 CPU, RAM, 또는 I / O 있는지 알고 항상 편리하다, 여기 언급해야한다 – 사이 sar, top, iostat, vmstat, free., 등이이에 대한 몇 가지 결론에 도달 할 수 있어야한다)

니 진스

Nginx는 요청을 받고 정적 컨텐츠를 제공하거나 요청을 PHP-FPM으로 옮기는 중입니다. 일반적으로 Nginx로 최적화 할 것이 많지 않습니다.

• 작업자 설정 = # CPU 코어
• Keepalive 활성화 (10-15의 값이 좋음)
• 불필요한 로깅 비활성화
• 필요한 경우 버퍼 크기 늘리기
• if 문을 피하십시오 (가능한 경우 정규 표현식 대신 정적 이름을 사용하고 불필요한 확장자를 제거하십시오)

테스트 블로그와 복제 된 블로그의 구성이 동일한 것이 이상적이며,이 경우 문제로 Nginx를 효과적으로 제거했습니다.

신청

코드에서 문제 (예 : 느린 플러그인 등)를 식별하려는 경우 느린 로그가 시작됩니다.

• MySQL 느린 로그 및 PHP-FPM 느린 로그를 사용하여 벤치 마크를 실행하고 느린 결과를 확인하십시오.

MySQL

• 캐시를 늘리고 mysqltuner.pl 을 실행 하여 좋은 시작점을 얻으십시오.

PHP

• 불필요한 확장을 비활성화하고
• register_globals, magic_quotes_ *, expose_php, register_argc_argv, always_populate_raw_post_data 비활성화
• memory_limit를 늘리십시오
• open_basedir 및 safe_mode는 성능에 상당한 영향을 주지만 추가적인 방어 계층을 제공 할 수도 있습니다. 이들의 유무에 관계없이 성능에 미치는 영향이 허용 가능한지 확인하십시오.

PHP-FPM

• 오후 * 값을 조정하십시오-높은 부하를 처리하기 위해 증가

htop 결과가 대량의 CPU를 소비하는 것으로 php-fpm을 표시한다는 점은 주목할 가치가 있으며 문제는 직접 관련이있는 것으로 보입니다.

캐싱

각 병목 현상을 최적화 한 후 캐싱을 시작하십시오.

• opPC 캐시 (APC)가 이미 있습니다. 테스트 파일과 함께 작동하는지 확인하십시오. 캐시 적중률을 확인하고 가능한 경우 APC 캐시를 디스크 대신 메모리에 저장하십시오.
• 캐시하도록 코드 설정 (예 : W3TC와 같은 WordPress 용 플러그인 사용)
• nginx를 사용하면 FastCGI 캐싱을 설정할 수 있지만 Varnish가 있으므로이를 피하는 것이 가장 좋습니다.
• Varnish (이미 수행 한)와 같은 캐싱 계층을 설정하고 작동하는지 확인하십시오 (예 : varnishstat 사용, 높은 적중률 달성 )
• 사이트 구성 요소에 대한 캐싱 추가-예 : 해당되는 경우 MemCached

때로는 응용 프로그램 및 하드웨어의 제한으로 인해 백엔드 사용을 최소화하기 위해 백엔드 성능을 크게 향상시키지 못할 수도 있습니다.

추가 자료

• 성능 조정 PHP
• PHP 최적화
• 고부하를위한 Nginx 최적화

---

답변