VPS에서 실행되는 Apache / php / mysql 최적화 연결 지연이 없습니다. 그러나 트래픽이 많은 날

RAM이 512m 인 VPS에서 apache / mysql 서버를 최적화하는 방법에 대한 질문입니다. 정상 부하 상태에서는 모든 것이 빠르게 실행되며 연결 지연이 없습니다. 그러나 트래픽이 많은 날 (5 만 회 이상 방문)이되면 사이트가 크롤링되고 아파치에서 콘텐츠를 다시 가져 오는 데 30 초 이상이 걸립니다.

이 사이트는 Expression Engine (CMS) (PHP)에서 실행 중이며로드 최적화 최적화 가이드를 따랐습니다. 나는 운 좋게 아파치를 위해 거기에서 꽤 많은 것을 따라 갔고 지금의 위치로 가져 가지만 일정한 응답 시간을 받아야합니다.

충분한 RAM이 있으므로 (내가하려고하는 일에 대해) 여기에있는 ‘메모리 부족에 최적화’문제와 다른 것으로 가정하고 서버가 과부하 상태에서 질식하지 않도록해야합니다.

어떤 recommondations?

답변

PHP의 경우 용량을 늘리는 두 가지 중요한 사항이 있습니다.

  1. 언급 한대로 고급 PHP 캐싱 (APC). 이것이 Yahoo!에서 사용하는 것입니다. 다른 유사한 프로젝트가 있지만 이것은 Rasmus의 아기입니다.
  2. mod_php 대신 FastCGI . mod_php가 가장 빠르기 때문에이 문제에 대한 논쟁이 있습니다. 그러나 동적 PHP 내용과 정적 자산 (JS, CSS, 플래시, 이미지, PDF 등)을 모두 제공하는 단일 Apache 서버가 있다고 가정합니다. 정적 자산에 대한 요청은 많은 메모리를 소비 할 필요는 없지만 PHP는 모듈이므로 모든 Apache 스레드에 있습니다.

Apache의 경우 :

  1. 작업자 MPM 사용
  2. KeepAlive 활성화

Apache에서 Lighttpd 또는 Nginx 로 전환하는 것을 고려할 수도 있습니다 . 나는 아파치를 좋아한다. 나는 많은 고급 기능 중 바보를 사용합니다. 나는 그것이 제공하는 것이 필요하기 때문에 오버 헤드를 받아들입니다. 일반적인 LAMP 스택의 경우 필요한 것 이상이며 자원 낭비입니다.

MySQL의 경우 :

  1. my.cnf 값을 조정하는 대신 쿼리 분석 및 수정에 소비 할 때 최적화 노력으로 10 배의 효과가 있습니다. 캐싱, 연결 등을 올바르게하는 것이 중요하지 않다는 말은 아니지만 대부분의 사람들에게는 문제의 9 %에 불과합니다.
  2. QA 중에 스테이징 / dev mysqld 의 일반 쿼리 로그 를 켜서 전송 된 모든 쿼리를 캡처하십시오. (생산 mysql 서버에서는 그렇게하지 마십시오!)
  3. 사용은 EXPLAIN 쿼리를 분석 할 수 있습니다. 특히 ORM이있는 프레임 워크를 사용하는 경우 (DB를 멀리하고 자신의 SQL을 작성하지 못하게하십시오) 외부 JOIN, WHERE 절이없는 SELECT, ‘fileort 사용’을 유발하는 ORDER BY 및 쿼리를 정리해야합니다 색인을 사용하지 않는
  4. MySQL 5.1 을 사용 하는 경우 쿼리 프로파일 러를 활용하십시오 .

고려해야 할 다른 도구는 mk-visual-explain입니다.

나는 10 개의 훌륭한 참고 문헌을 인용했습니다. 이런 것들이 당신을 흥얼 거리게해야합니다. 어떻게되는지 알려주십시오.

답변

PHP 세션 파일을 tmpfs로 옮기고 APC 또는 기타를 사용하고 필요하지 않은 모든 PHP 모듈을 제거하십시오 . 필요하지 않거나 사용하지 않는 모든 Apache 모듈을 제거하십시오 .

tmpfs (RAM의 디렉토리!)를 만들려면

mkdir /tmpfs; chmod 777 /tmpfs
mount -t tmpfs -o size=256M tmpfs /tmpfs

에서 의 / etc / fstab에 다시 부팅을 만들려면 아래 줄을 추가!

tmpfs     /tmpfs    tmpfs   size=256m,mode=0777    0       0

에서 /etc/apache2/php.ini은 RAM (의 tmpfs)에 세션을 저장하기 위해 조정!

session.save_handler = files
session.save_path = "/tmpfs"

참고 : PHP 파일과 세션 파일이 RAM에 있으면 디스크를 거의 만지지 않습니다!

아파치에서 expires_module 을 사용 하면 브라우저가 대부분의 것을 캐시합니다.

ExpiresActive On
ExpiresDefault "access plus 90 days"
ExpiresByType image/gif "access plus 90 days"
ExpiresByType image/ico "access plus 90 days"
ExpiresByType image/png "access plus 90 days"
ExpiresByType image/jpeg "access plus 90 days"
ExpiresByType image/x-icon "access plus 90 days"
ExpiresByType text/css "Access plus 90 days"
ExpiresByType text/html "Access plus 90 days"
ExpiresByType application/x-shockwave-flash "Access plus 90 days"
ExpiresByType application/x-javascript "Access plus 90 days"

.htaccess 파일을 사용하지 마십시오 ! 대신, vhost 설정 파일에 하드 코딩하십시오! 모든 http 요청마다 디스크 검사를 크게 제거 / 감소합니다. 실제로 추가됩니다.

Options FollowSymLinks
AllowOverride None

vhost.conf 파일에 사용 된 .htaccess의 예 …

<Directory /home/user/www/site.com/secure>
    Order Allow,Deny
    Deny from All
</Directory>

답변

몇 가지가 떠 오릅니다.

Opcode 캐시는 항상 좋은 생각입니다. APC보다 http://eaccelerator.net/ 을 선호합니다 . APC를 추가하려는 방식으로 개발하지 않은 경우 거의 항상 고통 스럽습니다. 화려하지는 않지만 촉진제는 효과가있는 것 같습니다.

리버스 프록시도 좋은 생각이지만 RAM 사용을 감시해야합니다. mpm-worker가 포함 된 Apache 2.2는 자체적으로 상당한 양의 RAM을 차지합니다. 귀하의 경우 Nginx와 같은 더 가벼운 것을 권장하고 PHP로 FASTCGI로 Apache를 실행하거나 프로세스별로 그대로 두십시오. Varnish, Squid, Nginx 등을 사용하는 아이디어는 정적 컨텐츠를 제공하고 사용자 연결을 처리하며 응용 프로그램 서버로 취급하는 Apache에만 PHP 요청을 전달하는 것입니다.

5.1.24 이상과 같이 최신 버전의 Mysql 5.1을 실행중인 경우 이제 초 미만의 느린 로그에 액세스 할 수 있습니다. long_query_time을 1 또는 2에서 시작한 다음 정말로 긴 것을 처리 할 때 0.5로 줄입니다. 인터넷에는 Mysql에 대한 일반적인 튜닝 정보가 많이 있지만 많은 작업을 수행 할 RAM이 없습니다. 기본값에서 설정을 늘렸습니까? 대부분의 기본 my.cnf 파일은 약 64MB의 RAM을 사용하도록 구성되어 있습니다. key_buffer를 16MB에서 64MB로 올리는 것이 가장 좋습니다.

또한 Myisam 또는 Innodb 테이블을 사용하고 있습니까? DB에서 세션을 유지하는 경우 세션 수준을 행 수준 잠금 대신 테이블 수준 잠금을 수행하는 Mysiam 테이블로 두지 않고 세션 테이블을 Innodb로 변경하거나 쿠키로 설정하십시오. 기본적으로 20 % 이상의 쓰기에서 80 %의 읽기에 이르는 모든 테이블은 Innodb로 이동하기위한 후보입니다. 각각의 버퍼는 개별적으로 구성되므로 Myisam 테이블과 Innodb 테이블 사이의 RAM 양의 균형을 유지해야합니다.

그리고 마지막으로 512MB의 RAM이 더 저렴하거나 거의 같은 가격이라면 Mysql을 실행하기 위해 설정에서 또 다른 512MB VPS까지 먼 길을 갈 것입니다. 사용 가능한 디스크 IO를 두 배로 늘리기 때문에 실제로 두 번째 인스턴스에 의존합니다. VPS 서버의 문제점 중 하나는 IO가 동일한 물리적 서버의 다른 사람들로부터 보호되지 않는다는 것입니다.

흠 내 게시물은 모두 흩어져 있지만 볼 곳이 많이 있습니다. 행운을 빕니다.

답변

  • apc와 같은 PHP에는 opcode 캐시를 사용하십시오.
  • 오징어 또는 바니시와 같은 http 가속기를 사용하십시오.

답변

메모리가 부족한 상황 (트래픽이 많은 서버의 경우 512Mb가 낮음)에서는 웹 서버와 DB 엔진을 선택하는 것이 좋습니다.

Lighttp는 Apache가 일반적으로 많은 조정 후에 만들 수있는 것보다 더 가벼우 며, 그보다 더 가벼운 옵션이 있습니다. 다른 서버에서 지원하지 않는 Apache 기능이있는 경우에는 불가능합니다.

sqlite는 mySQL보다 훨씬 단단하며 많은 조건에서 더 빠릅니다. 사용중인 엔진이이를 지원하는지 확인하고 시도해보십시오.

다른 옵션 인 쉬운 옵션은 여유가있는 경우 VM에서 더 많은 RAM을 얻는 것입니다.

답변

여기에서 큰 제안을 넘어서서 모든 VPS가 동일하게 만들어지지는 않았다는 점에 유의해야합니다. 내 경험상 PHP는 CPU가 무겁습니다.

EC2에서 nginx / apc / phpfpm / mysql (local) 의 WordPress AB 벤치 마크 (ab -n 500 -c 25 http://domain.com/index.php )로 인해 엔트리 레벨 “2GB에서 초당 2 회 요청이 발생했습니다. RAM / 1 컴퓨팅 유닛 서버 “.

512MB Rackspace Cloudserver에서 동일한 정확한 스택 (스크립트로 동일한 OS에 배포)에 대해 동일한 벤치 마크를 실행하면 ~ 80 req / 초가 반환됩니다. 이 초보 실험에서 4 배 적은 램, 40 배 성능

AB 동안 상단을 보면 EC2가 동시성을 처리 할 수없고 즉시 100 % CPU로드에 도달하여 잠길 수 있음을 알 수 있습니다. 동일한 벤치 마크에서 512MB 서버 (가상화 된 쿼드 코어 CPU)에서 상위를 보면 코어가 ~ 60 %로드에 도달하고 벤치 마크를 원활하게 처리합니다.

VPS는 확약없이 스핀 업 및 종료가 매우 쉽고 VM / VPS가 상주하는 인프라 스트럭처를 테스트에 적용하는 것은 해가되지 않습니다!

편집 1 : 또한 EC2의 “High CPU”Small Instance는 CPU가 여전히 병목 상태 인 상태에서 ~ 10 / req 초만 산출 할 수있었습니다. 제 결론은 EC2를 사용하여 안정성 / 견고성에 대한 성능을 희생하고 그러한 환경을 요구하는 많은 사용 사례가 있다는 것입니다.

답변