당신은 여기에서 광범위하고 광범위한 최적화 세계에 들어가고 있으며 모든 크기에 맞는 단일 크기는 아닙니다.
성능 정의
단일 사용자의 페이지로드 시간 또는 전체 용량 / 총 동시성을 의미합니까? 이 두 가지는 매우 분명하게 다르며 엄격히 관련이 없습니다. 제한된 용량의 빠른 상점을 갖는 것은 전적으로 가능합니다. 또는 용량이 많은 느린 상점.
따라서 어느 유형의 성능을 다룰 때 :
- 단일 사용자 인식 페이지로드 시간
- 총 용량 / 동시성
특히 자체 병목 현상이 있기 때문에 자체 솔루션을 사용하여 독립적으로 해결해야합니다.
상점의 최적의 서버의 다른 측면을 이미 구성한 유능한 호스트가 있다고 가정합니다.
단일 사용자 인식 페이지로드 시간
MySQL은 병목 현상이
아닙니다. 직접적으로는 아닙니다. 페이지로드 시간을 테스트 할 때 대부분의 경우 대기 시간에 관한 것입니다. 캐시 만 적중합니다. 여기서 핵심은 대기 시간을 최소화하는 것입니다.
- MySQL 캐시 크기를 적절하게 조정하십시오 (올바른 대답은 없으며, 상점마다 매월 다르게 설정을 조정합니다)
- 네트워크 대기 시간을 줄입니다. 64 바이트 프레임의 경우; 10Mbps : 51.2µs, 100Mbps : 5.12µs, 1Gbps : 4.096µs 이는 100Mbps에서 1Gbps로 전환하는 것만으로도 20 %의 향상을 제공합니다. s1
- 네트워크 용량을 늘리십시오. 웹과 DB 서버 사이에서 초당 10MB를 초과하는 초당 메가 바이트가 놀랄 것입니다. 따라서 최소 100Mb / s가 필요합니다 s1 . 또는 DB 서버를 로컬로 옮기십시오.
- SOLR 사용 외부 엔진은 때때로 더 적합하며 SOLR은 더 큰 카탈로그 에 더 빠릅니다 (그리고 더 큰 카탈로그에는 스트레스를줍니다 ). 조정되지 않은 SOLR조차도 MySQL보다 더 빠른 계층 탐색 및 검색 결과를 생성합니다.
그러나 이러한 변경으로 인해 병목 현상이 실제로 발생하는 페이지로드 시간에 부분적으로 영향을 미칩니다.
- 응용 프로그램을 조정하십시오. Magento는 컬렉션을 만들고 캐시하는 방식에 상당히 큰 버그가 있습니다. 우리는 성능을 저해 할 수있는 여러 가지 큰 핵심 코드 문제를 발견했습니다. 경우에 따라 계층화 된 탐색 결과에서 제품 수 표시를 제거하면 큰 컬렉션을로드하는 데 2 초가 소요 됩니다.
- MySQL 느린 로그를 검토하십시오. 느린 쿼리를 확인하고 필요에 따라 인덱스를 추가하십시오. 적절한 인덱스가 있거나 없는 여러 조인으로 복잡한 쿼리를 실행하는 것의 차이는 수십 초가 될 수 있습니다 .
응용 프로그램이 병목 현상입니다. 소프트웨어가 아닙니다. 그래서 단순히 코어 코드를 개선하거나 템플릿 덜 무거운보다 성능에 훨씬 더 극적인 효과가 떨어집니다 어떤 MySQL의 구성 변화를.
우리가 귀찮게하지 않을 것
- 스토리지 엔진 변경 MariaDB와 Percona는 동일한 InnoDB 엔진 인 Percona XtraDB를 공유합니다. 그것들은 하나로서 동일하게 취급 될 수 있습니다. 단일 쿼리 실행 시간과 관련하여 성능은 정확하게 바닐라 MySQL 빌드를 반영합니다. 이것은로드 / 동시 상태에서 작동합니다.
- MySQL 슬레이브 실행 슬레이브가 물리적으로 가까이 있거나 (네트워크 관점에서) 슬레이브가 마스터보다 더 나은 하드웨어를 가지고 있지 않으면 성능이 향상되지 않습니다. 이것은로드 / 동시 상태에서 작동합니다.
- 외부 DB 서버를 실행합니다. 이것은 많은 호스트 / 대행사에 의해 반복적으로 전달되는 최악의 조언입니다. 하드웨어 / 리소스가 한도에 도달하거나 여러 개의 웹 서버가있을 때까지 (읽기 : 고 가용성) Magento 저장 소용 로컬 컴퓨터의 MySQL은 좋은 생각입니다. 모든 네트워크 오버 헤드와 대기 시간을 줄입니다. 100Gb / s 네트워크 (예, 초당 100 기가비트) 도 원시 볼륨, 처리량 및 대기 시간에 대해 로컬 유닉스 소켓과 비교 되지 않습니다 .
s1 별도의 데이터베이스 서버에만 해당됩니다. 로컬 DB 서버에는 적용되지 않습니다.
총 용량 / 동시성
MySQL이 병목 현상
일까요? 그러나 일단 MySQL 성능이 저하되는 지점까지 PHP 성능과 용량을 조정 한 후에 만 가능합니다. Varnish와 FPC를 올바르게 구성 했다면 (실제로 실패한 시도 횟수를 시작하지 마십시오) MySQL은 병목 현상이 발생합니다.
따라서 위의 수정 외에도.
- MySQL 엔진을 변경하십시오. XtraDB는로드시 탁월하며 주식 MySQL 배포에 비해 진정한 이점을 보여줍니다.
- MySQL로 최신 상태를 유지하십시오. 5.5는로드시 5.0보다 낫습니다.
- PHP MySQL 드라이버를 변경하십시오. PHP 5.3 이상에는 기본 MySQL 드라이버가 있지만 경우에 따라 Magento 용 MySQLND보다 성능이 우수한 별도의 드라이버가있는 PHP 5.2를 발견했습니다. 직접 테스트
- 검색 엔진을 변경하십시오. 검색을 SOLR / Sphinx (또는 일부 타사 외부 서비스)로 옮기면 비 트랜잭션로드 (예 : 주문을하지 않는 사람)의 부담을 줄일 수 있습니다.
- 계층 탐색 엔진을 변경하십시오. 다시 말하지만, SOLR은 계층 내비게이션을위한 훌륭한 엔진이며, 비 잠금 특성으로 인해 MySQL보다 훨씬 빠릅니다.
- MySQL 슬레이브를 추가하십시오. 이 방법 은 비 트랜잭션로드를 찾아 보는 데 도움 이 되지만 시간당 더 많은 주문을 처리하는 데 도움이되지 않습니다. 마스터가이 데이터를 처리하고 복제하는 데 의존하기 때문입니다.
우리가 귀찮게하지 않을 것
- 마스터 / 마스터. 마스터 / 슬레이브 설정의 하드웨어 포화도는 시간당 1000 개를 초과하는 매우 높은 티핑 포인트로 인해 프로덕션에서 마스터 / 마스터를 사용해야하는 것은 결코 없습니다. 우리는 광범위한 테스트를 수행했지만 성능 측면에서 유리하고 마스터 / 마스터의 내재 된 위험과 문제로 인해 유리하다는 것을 결코 발견하지 못했습니다. 단순히 그만한 가치가 없습니다.
읽기 및 쓰기 확장 성
마지막 단락은 실제로 읽기 및 쓰기 확장 성의 핵심 영역으로 이어집니다. 점점 더 많은 슬레이브를 추가하여 너무 복잡하지 않으면 서 읽기 스케일링을 상당히 무한대로 수행 할 수 있습니다.
Magento의 Reads to Writes 비율은 약 0.1 %입니다. 쓰기가 큰 문제가되지 않아야한다는 점을 고려하십시오. 그렇기 때문에 MySQL 클러스터 와 자동 샤딩 (테이블을 별도의 시스템으로 분리)과 같은 영리한 기능에 대해 언급하지 않았습니다 .
하드웨어, 하드웨어, 하드웨어
하드웨어는 개선에있어 가장 빠른 답변입니다. 따라서 두 시나리오에서 의도적으로 언급하지 않았습니다.
그러나 기본 하드웨어가 충분하지 않은 경우 세상의 모든 소프트웨어 변경 사항이 아무런 영향을 미치지 않습니다. 그 의미는 ...
- 버퍼가 제한된 저품질 스위치
- 지나치게 포화 된 네트워크 링크
- 지리적으로 멀리 떨어진 서버
- 네트워크 QoS / CoS 불량
- 제한된 총 RAM 양
- 낮은 메모리 대역폭 RAM
- 낮은 IOP HDD 하위 시스템
- 소프트웨어 RAID 컨트롤러
- 저속 클럭 CPU
- 저 대역폭 칩셋
- 하드웨어 가상화 (커널 레벨 가상화를 제외한 거의 모든 유형)
요즘에는 실제로 하드웨어를 얼마나 확장 할 수 있는지에 대한 최고 한도가 있습니다. 클라우드 하드웨어가 상당히 평범한 경향이 있기 때문에 "클라우드에서"무한 확장의 신화를 무시하자. 예를 들어 아마존의 주력 모델은 3.3GHz에서 12 코어입니다. 그러나이 밖에도 사용할 수있는 매우 강력한 서버가 있습니다. 최상위 서버 에는 160 개의 코어와 2TB (예, 테라 바이트)의 RAM이 있습니다. 우리는 아직 그 기능을 능가하는 사람을 보지 못했습니다.
따라서 수평 스케일링을 고려해야하기 전에 수직 스케일링에 대한 방대한 범위가 있습니다.
끊임없이 움직이는 표적
성능을 추구 할 때 병목 현상은 항상 계속 움직일 것입니다.
재고 마 젠토 상점.
캐시를 켭니다. PHP는 병목 현상
입니다. 백엔드 캐시를 추가하십시오. PHP는 병목 현상입니다
응용 프로그램 수준의 전체 페이지 캐시를 추가하십시오. PHP는 병목 현상입니다
. 서버 수준 프런트 엔드 캐시 (예 : Varnish)를 추가하십시오. MySQL이 병목 현상
임 대안 검색 / 계층 탐색 엔진 (예 : SOLR / Sphinx)을 추가하십시오. PHP는 병목 현상
입니다. 응용 프로그램 서버를 더 추가하십시오. MySQL은 병목 현상입니다
MySQL 슬레이브를 추가하십시오. 프런트 엔드 캐시가 병목 현상입니다
프런트 엔드 캐시 서버를 더 추가하십시오. PHP는 병목 현상
입니다. 응용 프로그램 서버를 더 추가하십시오. SOLR / Sphinx는 병목 현상입니다
기타.
헹굼 반복의 경우가 대부분입니다. 그러나 분명히 이해해야 할 점은 MySQL이 최적화를위한 첫 번째 요구 사항이 아니며 실제로 MySQL이 PHP에 비례하여 CPU를 더 많이 소비 할 때만 작동한다는 것입니다. 이는 FPC와 Varnish가 모두 사용 중일 때만 발생합니다 그리고 서버는 순전히 주문을 처리하고 있으며 다른 모든 것은 캐시에 있기 때문에 아무것도 없습니다.
맹목적으로 변경하지 마십시오
MySQL 슬레이브를 추가하는 것만으로도 도움이 될 것이라고 위에서 말 했으므로 성능과 안정성을 크게 높일 수 있습니다. 혼잡 한 네트워크, 사양이 낮은 슬레이브 서버 또는 부적절한 설정으로 인해 복제 문제가 발생하여 저장소를 처음보다 느리게 만들거나 마스터와 슬레이브간에 동기화 문제가 발생할 수 있습니다.
사물을 원근법으로 만들기-실제 사례.
예 1-시간당 300 개의 주문
우리는 시간당 300 건의 주문을 처리 하기 위해 다음 하드웨어를 사용했습니다 . 티핑 포인트에서만 전용 MySQL 서버와 로컬 MySQL 슬레이브를 추가 할 필요성을 느꼈습니다.
1 서버
CPU : 2x Intel E5-4620
RAM : 64GB HDD : 4x 80k IOP / s SSD
RAID : 하드웨어 RAID 10 마
젠토 버전 : Magento EE
OS : MageStack
전체 시간 동안 부하 평균은 3.00 미만으로 유지되었습니다.
예 2-시간당 180 주문
이틀 전에 새로운 고객이 쉽게 트래픽을 급증했습니다. 단일 서버 및 Magento Community Edition으로 시간당 180 개의 주문 처리 .
1 서버
CPU : 2x Intel E5-4620
RAM : 64GB HDD : 4x 80k IOP / s SSD
RAID : 하드웨어 RAID 10 마
젠토 버전 : Magento CE
OS : MageStack
웹 사이트 : Wellgosh.com
전체 시간 동안 부하 평균은 6.00 미만으로 유지되었습니다. 이 시나리오에서는 부하가 더 높았으며 몇 가지 요인으로 인해 감소했습니다.
- 실시 예 1에서와 같이 저장 측 튜닝이 수행되지 않았다
- 응용 프로그램 수준 FPC 부족
그리고 최근에, 그래프로 피드백을 줄 수있는 자세한 통계를 얻었습니다. 이들은 분리 된 Magento 아키텍처 (로드 밸런서, 웹 서버, db 서버 등 -MageStack 사용 ) 의 주요 구성 요소간에로드가 어떻게 분배되는지에 대한 훌륭한 이야기를 제공합니다 .
앞뒤로 ...보고 싶은 날짜는 2 월 22 일 12:00 am입니다.
방화벽 패킷
바니시 트래픽
Nginx 트래픽
MySQL로드
CPU로드
그리고 가장 중요한 것은 하중 분포
이 이미지는 실제로 모든 것을 알려줍니다. 그리고 MySQL은 확실히 최소한 의 부담이 아닙니다. 따라서 시간당 수천 건 이상의 주문을 처리하지 않는 한 성능 문제를 다른 곳에 집중하십시오.
그리고 요약하면
성능을 변경하는 것이 "하나의 크기에 모두 해당되는 것은 아닙니다". 현재 병목 현상을 분석하고 상점과 인프라에 맞게 미묘한 변경 / 조정을 수행하는 경우입니다.
그러나 성능을 제외하고 Percona를 사용하면 다른 이점이 있습니다.
우리는 거의 독점적으로 Percona XtraDB를 사용합니다. 우리는 Magento를 위해 특별히 개발 한 MySQL의 커스텀 컴파일 빌드를 실행하고 프로세스 중에 Percona와상의했습니다. 그러나이 선택에 영향을 준 것은 성능 만이 아닙니다.
- 퍼 코나 툴킷
- pt- 쿼리-다이제스트
- xtrabackup
- 기타
- 퍼 코나 방출 빈도
- Percona 상담 지원
- InnoDB 풀 보존으로 웜 캐시 재시작
그리고 훨씬 더. 따라서 MySQL보다 그것을 사용하면 성능뿐만 아니라 다른 이점이 있습니다. 실제로 MySQL은 성능과 안정성 추구에있어 우리의 관심사 중 최소한의 관심사입니다.
속성 : wellgosh.com , sonassi.com , iebmedia.com .