현재 영국에서는 웹 서버의 첫 번째 응답이 200ms 미만이어야한다는 요구 사항을 해결하기 위해 노력하고 있습니다. 현재로드 밸런서 아래에 2 개의 전용 웹 서버와 1 개의 db 서버가 있으며 800ms에 도달합니다.

현재이 사이트에는 5 명 미만의 고객, 2 개의 제품, 4 개의 카테고리가 있으며, 현재 사이트에 대한 프론트 엔드가 없으며 스타일이없고 이미지가 없습니다.

또한 니스와 함께 nginx에서 실행 중입니다.

누구든지 웹 서버 설정에 대한 조언을 줄 수 있습니까? 왜 천천히 들어 오나요? 이것을 최적화하기 위해 무엇을 추천 할 수 있습니까? 400 % 더 빨라야합니다!

물어 볼게요

웹 서버의 첫 번째 응답은 영국에서 200ms 미만이어야합니다
. 현재 사이트에 대한 프런트 엔드가 없으며 스타일과 이미지가 없습니다.

니스 또는 FPC (또는 둘 다)의 도움 없이는 이러한 수치를 달성 할 수 없습니다. 필자는 그림에 정적 콘텐츠 (추가 할 때마다)를 포함 할 필요가 없기를 희망합니다-거의 불가능한 이미지 (js / cs / css가 거의 없음).

우리는 800ms에오고
있습니다. 또한 니스와 함께 Nginx 에서도 실행됩니다.

니스가 잘못 구성되었습니다.

올바르게 구성된 바니시 설치는 <100ms 페이지로드 시간을 제공합니다 (<10ms에 가까움)

사실, 마 젠토에게는 이와 같은 것을 보게 될 것입니다.

고객이 로그인하지 않은 경우 ...
즉. 고유 세션을 만들지 않은 경우 (카트에 추가 / 위트리스트, 로그인 등)

--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
  Uncached    Mage default cache   Partial FPC cache   Total FPC cache   Varnish

고객이 로그인 할 때 ...
즉. 고유 한 세션을 생성했습니다 (로그인, 장바구니의 항목 등). 이 시점에서 바니시는 꺼져있을 것입니다. 리버스 콜에 따라 ESI를 사용하기로 선택한 경우 FPC 캐시와 유사한 페이지로드 시간을 유지하거나 (부트 스트랩 오버 헤드로 인해) 실제로 캐시되지 않은 페이지로드 시간을 늘릴 수 있습니다.

--1.4s--------0.8s-----------------0.6s--------------
  Uncached    Mage default cache   Total FPC cache   

바니쉬 튜닝의 경우 가 아니라 "실제로는 아무것도 캐싱하지 않습니다" 의 경우이다 .

이상적인 Magento 서버 구성 파일

글쎄요, 글쎄요.

우리는 다양한 크기와 용량의 400 개 이상의 서버, 모든 순수한 Magento 매장을 운영합니다. 그리고 하나의 구성 파일이 다른 구성 파일과 일치하는 경우는 거의 없습니다. 모든 비즈니스가 똑같지는 않기 때문입니다.

여러 가지 이유로 병목 현상이 발생할 수 있습니다.

1. 활발한 세션과 함께 많은 수의 방문자 동시성
2. '나쁜'크롤링 봇의 희생자, 필요한 귀중한로드 생성
3. 계층화 된 내비게이션 조회 비율이 높음
4. 많은 수의 검색어
5. 시간당 많은 거래량
6. 잘못 작성된 템플릿
7. 너무 많거나 느리거나 불규칙한 타사 확장
8. 404 적중률로 이어지는 오래된 인바운드 링크
9. 네트워크 인터페이스 용량 제한
10. 대형 / 복잡한 카탈로그 (많은 제품 / 카테고리 / 속성)

따라서이 스펙트럼 전체에 걸쳐 상점이 있으면 각각 최적의 성능에 대한 다른 접근 방식이 있습니다.

위에서 설명한 문제를 해결하기 위해; 우리는 의도적으로 "더 많은 / 더 나은 하드웨어"를 언급하지 않을 것입니다

1. 니스보다 FPC를 사용하십시오
2. 네트워크 에지에서 불량 봇을 필터링 / 차단하거나 쿠키 상태 / URL에 관계없이 모든 요청을 Varnish로 리디렉션
3. 스톡 계층 탐색을 SOLR로 변경하고 계층 탐색 필터를 종속으로 설정
4. 재고 검색을 SOLR로 변경
5. 마스터 / 슬레이브 구성에 MySQL로드 분산-찾아보기로드가 Varnish / FPC에 의해 흡수되도록 보장 한 경우에만 수행
6. 템플릿을 다시 빌드하십시오.
7. 그들을 제거
8. Nginx / Varnish에서 제공하기 전에 액세스 로그를 지속적으로 모니터링하고 URL을 다시 씁니다. Nginx 수준에서 수행하는 경우-니스가 301/302 리디렉션을 캐싱하는지 확인하십시오.
9. 정적 컨텐츠를 CDN으로 분리하거나 연결성을 개선하십시오.
10. 더 많은 하드웨어를 추가하십시오 (물론 우리는 언젠가 말해야했습니다)

따라서 이것을 염두에두고-Nginx 구성 파일, PHP fcgi 풀 구성 파일, MySQL 구성 파일 또는 Varnish 구성 파일이 동일하지 않을 것입니다. 하드웨어 변경 자체와 결합하십시오. 사용 가능한 메모리, I / O 성능 (HDD 및 네트워크) 및 CPU-400 %의 성능 향상으로 이어지는 미묘한 변형이 있지만 온라인에서 쉽게 찾을 수있는 방법은 없습니다.

Peer 1 후원 Magento 백서 를 성능에 복사하여 붙여 넣을 수 있습니다 (권장하지 않음). 설정이 사용 가능한 메모리, 스레드 제한, TCP / IP 상태, I / O 용량을 초과하지 않고 바닐라 Apache / mod_php 구성보다 성능이 저하되지 않기를 바랍니다.

계속 진행하겠습니다.

이상적인 마 젠토 서버 스택

이것은 현실에 더 가까이 갈 가능성이 높습니다. 이를 입증하는 좋은 예는 전용 Magento OS 인 MageStack 구성 방법을 보여주는 것입니다.

별도의 하위 구성 요소를 가져 가면 올바르게 구성된 경우 Magento 저장소를 실행하는 가장 최적 / 중요한 소프트웨어 목록이 표시 됩니다 . 특히 :

방화벽, DOS 필터,로드 밸런서, 니스, Nginx, PHP, Redis, Memcached, MySQL

그래서 당신이 요청할 때 :

최고의 마 젠토 서버 설정은 무엇입니까?

당신의 목표는 정확히 무엇입니까?

1. 고 가용성
2. 신뢰할 수 있음
3. 관리의 단순성
4. 공연
5. 확장 성

충분한 강의, 우리는 그것을 어떻게 할 것인가

서버 결함에 대한 답변 을 부분적으로 반영하기 위해 비슷한 맥락에서 3 대의 서버를 사용할 수 있습니다. 따라서 가능한 한 최적의 서버 방향을 설정하십시오. 우리는이 답변의 범위를 훨씬 넘어서는 고 가용성 솔루션을 피할 것입니다.

다중 서버 구성에 필요한 하위 구성 요소는 다음과 같습니다.

• 방화벽
• 로드 밸런서
• 웹 서버
• MySQL 서버
• 공통 스토리지

그래서 우리는 일부 시스템을 다목적으로 사용할 것입니다. PCI-DSS 준수는 각 서버에 대한 역할을 나타냅니다. 따라서 5 개의 역할과 3 개의 서버를 통해 즉시 위반할 수 있습니다. MageStack 은 가상화를 사용하여 이를 해결합니다. 동일한 작업을 수행 할 수 있습니다.

서버 1 :로드 밸런서 + 웹 서버
서버 2 : 웹 서버
서버 3 : 데이터베이스 서버

일반적인 스토리지를 사용하지 않고 대기 시간이 짧고 네트워크 대역폭 (> 1Gbps, <125µs)이없는 경우 각 머신에 매장 루트 디렉토리를 저장하고 실시간으로 사용 ionotify하거나 경과 한 데이터를 복제하는 것이 좋습니다 cron작업. 다시 말하지만 광대 한 조정과 적절한 네트워크 대역폭이 필요하므로 NFS와 같은 네트워크 파일 시스템이나 Gluster 또는 DRBD와 같은 복제 블록 장치를 피할 수 있습니다.

바니시는 가능한 한 정면에 가까이 있어야합니다. 그러나 니스는 SSL을 해독 할 수 없습니다. SSL 터미네이터와 결합하십시오. Nginx, Pound, Stunnel, Stud 등. 니스에 내장 된로드 밸런서는 훌륭하지 않지만 2 대의 서버 설정에 적합합니다.

Nginx + PHP-FPM은 훌륭하지만 Nginx kool-aid를 너무 많이 마시지 마십시오. 일반적인 Apache / mod_php 구성과 거의 동일하게 작동합니다. 여기 Nginx를 사용하지 않는 이유에 대한 좋은 자료가 있습니다 . Nginx는 훌륭하지만 실제로는 훌륭하지만 Magento 상점의 병목 현상은 아니며 복잡하고 고유 한 Magento 지원이 부족하다는 점을 감안할 때 확실합니다. 대부분의 초보자 시스템 관리자는 다른 것보다 Apache / mod_php를 사용하는 것이 좋습니다. 이것은 PHP-FPM를 사용하여 통해 고대의 추천처럼 보일 수있다 - 그러나 우리의 성능 테스트는 만 ~ 7 % 더 빠르게 Nginx의 솔루션으로 성능을 보여 주었다 - 제대로 구성된 경우. 고성능의 안정적인 Nginx / PHP-FPM 설정에 필요한 튜닝 및 경험은 Apache / mod_php보다 성능이 우수합니다. 당신이 사용하기로 선택한 것은 전화입니다.

데이터베이스 서버는 간단합니다. MySQL. 그러나 앞에서 언급했듯이 높은 변환 사이트가있는 경우 마스터 / 슬레이브 구성이 권장됩니다. 이 방법을 따라야하는지 여부는 이 기사 를 읽고 결정할 수 있습니다 .

그런 다음 주변 백엔드 캐시, Memcached 및 Redis. 소규모 저장소에서는 한 Memcache 인스턴스에 세션을 저장하고 다른 백엔드 캐시에 빠른 백엔드 캐시를 저장하면 성능이 향상됩니다. 우리는 캐시 백을 느린 백엔드에 저장하는 것을 옹호하지 않습니다 . 그것이 제공하는 것보다 더 많은 문제를 야기하기 때문입니다. 따라서 Memcached 설정을 사용하면 캐시 태깅 을 포기해야 합니다 . 대신, 우리는 같은 구성에 사용 이 .

Redis는 Magento에 고유 한 것이 아니지만 Memcache보다 우수한 솔루션 인 Colin Mollenhour 의 확장 기능으로 캐시 태그, 세션 스토리지 및 영구 캐시 스토리지를 지원합니다 . Memcache만큼 변동성이 적습니다 . 그러나 단점이 있습니다. 우리가 발견 한 대규모 의 LRU 메커니즘은 다소 실패 생산 저장 (> 500 개 주문 / 시간,> 30K의 순 / 시간) 포화 점을 명중 된 후 캐시 (및 태그) 매우 빠르게 채울 수 있다는 ( 설정이 다르더라도 즉시 병목 현상이 발생합니다. 따라서 오래된 레코드를 수동으로 정리하는 것이 좋습니다.

그렇다면 어떤 하드웨어를 사용해야합니까?

웹 서버 : 가장 빠른 CPU, 대부분의 CPU 코어, 2GB RAM 비율 / 코어
DB 서버 : 빠른 CPU, 가장 빠른 디스크 I / O, 대부분의 RAM

따라서 3 대의 머신을 여러 번 사용할 때 가장 좋은 레이아웃은 다음과 같습니다.

서버 1 : SSL 종료 기-> 니스-> Nginx / Apache> PHP
서버 2 : Nginx / Apache> PHP, Redis, (MySQL Slave)
서버 3 : MySQL

각 응용 프로그램의 특정 구성에 관해서. 하드웨어 사양, 매장 복잡성, 방문자 유형 및 방문자 유형 및 방문자 수에 따라 다릅니다.

당신은 그 클러스터 구성으로 좋은 길을 가고 있습니다. Redis 전용 캐시 호스트를 추가하는 것이 좋습니다. 높은 CPU 전력과 많은 RAM (~ 64GB)을 선택하십시오.

다음 은 고 ​​가용성, 내결함성, 분산 및로드 밸런싱 LEMP 클러스터에 사용한 전체 구성 목록입니다 . 그것은 포함 app/etc/local.xml의 core_config_dataMySQL은, PHP-FPM, nginx를, 그리고 레디 스에 대한 테이블 및 구성을. 모두 Ubuntu 12.04 LTS 64 비트를 실행합니다. 구성에는 단점없이 많은 최적화가 포함됩니다.

하이라이트

• 관리자 : 46
• 카테고리 : 2,450 (가장 큰 제품에는 2,400 개의 제품이 있습니다)
• 제품 실체 : 101,000
• 콤보 제품 : 484
• 제품 관계 : 54,000
• 재고 및 사용 가능한 구성 가능 제품 : 10,100
• CMS 블록 : 3,100
• CMS 페이지 : 1,400

2013 년 8 월 트래픽 :

• 월별 4 천만 페이지 뷰
• 230 만 명의 순 방문자
• 월 46,000 회 점검
• 미국 방문객의 89 %

웹 호스트

중복 고 가용성 하드웨어 방화벽 및 하드웨어로드 밸런서 뒤에는 10 개의 호스트가 있습니다. 대부분의 정적 자산은 CDN으로 오프로드됩니다.

• 사이트 전체 평균 응답 시간 : 282ms
• 평균 FPC 응답 : 48ms
• 부하 평균 : 0.6 ~ 1.0 (테스트에서 부하 평균이 ~ 5.0에 도달하면 성능이 35 % 저하됨)
• 듀얼 Intel Xeon CPU E3-1230 V2 @ 3.30GHz (각 4 코어)
• 32GB DDR3 1333MHz RAM

모듈

• https://github.com/colinmollenhour/Cm_RedisSession
• https://github.com/colinmollenhour/Cm_Cache_Backend_Redis
• https://github.com/aligent/CacheObserver.git --branch = models
• https://github.com/aligent/Lokey_ShippingAdjustments
• https://github.com/aligent/VF_CustomMenu.git --branch = production
• https://github.com/Vinai/customer-activation
• https://github.com/gknoppe-guidance/magento-cachebuster

캐시 호스트

자동화 된 장애 조치로 마스터-슬레이브 구성에서 Redis를 실행하는 호스트는 두 가지입니다. 3 개의 Redis 인스턴스 (세션, 백엔드 및 FPC)는 처리량을 높이고 지속성 동작을 미세 조정하는 데 사용됩니다.

• 초당 3,000 명령
• 0.7ms 평균 응답 시간
• 1.0 ~ 1.5의 평균로드
• 쿼드 Intel Xeon CPU E5-2620 0 @ 2.00GHz (각 6 코어)
• 128GB 버퍼링 DDR3 1333MHz RAM
• 기계 디스크, RAID 1, 하드웨어 컨트롤러

데이터베이스 호스트

웜 페일 오버가있는 마스터-슬레이브 구성에서 MySQL 5.6.11을 실행하는 두 개의 호스트가 있습니다.

• 초당 1,500 개의 명령
• 평균 응답 시간 1.1ms
• 로드 평균 0.1 (마스터) 및 0.4 (슬레이브)
• 쿼드 Intel Xeon CPU E7-2860 @ 2.27GHz (각 10 코어)
• 128GB 버퍼링 DDR3 1333MHz RAM
• SSD, RAID 1 + 0, 하드웨어 컨트롤러
• tcmalloc이있는 MySQL 5.6.11

Magento를위한 또 다른 서버 팁은 OPcache 와 함께 PHP 5.4 또는 5.5를 설치하는 것 입니다. PHP 5.4는 5.3보다 훨씬 빠릅니다 ( http://www.eschrade.com/page/magento-performance-on-php-5-3-5-4-and-5-5rc3/ ).

니스로 캐시되지 않았을 때 마 젠토 페이지 속도를 개선하고 기본적으로 활성화되어 있지 않은 중요한 팁을 추가하고 싶습니다 (카트 페이지 로딩 시간이 6sc에서 1.5sc로 변경됨).

/etc/mysql/my.conf에서 mysql 쿼리 캐시 활성화

query_cache_size = 268435456
query_cache_type= 1
query_cache_limit=1048576

cache_type은이를 가능하게하고, 캐시 크기는 메모리에서 캐시가 사용하는 값이고 캐시 한계는 캐시 할 쿼리 결과의 최대 크기입니다.

현재 구성에서는 400ms의 초기 응답을 받고 2 초 안에 문서를 완료합니다 (표준 연결은 5mbps). 우리 홈페이지 크기는 1mb입니다.

설정은 다음과 같이 AWS를 기반으로합니다.로드 밸런서가 RDS 데이터베이스 (페일 오버 포함)에 연결된 ec2 인스턴스가 있습니다. 또한 캐시 스토리지와 세션 스토리지 모두에 대한 redis 캐시 백엔드로 전체 페이지 캐시를 구현했습니다.

평균적으로 하루에 300-400 명의 방문자가 있지만 redis 캐싱을 사용하면 속도를 유지하고 비용을 줄이면서 최소한의 ec2 리소스 사용이있었습니다.

로드 밸런서가있는 이유는 현재 설정에서 처리 할 수없는 트래픽 급증이있는 경우 ec2가 새 인스턴스를 자동으로 부팅하도록 설정되어 있기 때문입니다.