1k에서 10k 웹 사이트 / 상점의 성능 문제

웹 사이트 / 상점의 수가 1k를 초과 할 때 Magento 성능을 향상시키는 방법을 찾으려고 노력하고 있으며 목표는 약 10k입니다. 다음은 몇 가지 질문입니다. 모든 팁 / 도움을 환영합니다!

1. 새로운 웹 사이트 / 상점을 추가하는 것은 느립니다.
   Mage_Core_Model_Abstract의 _afterSave ()에서 $ this-> cleanModelCache ()를 주석 처리했으며 상황이 좋아 보이지만 웹 사이트 / 상점 수가 증가함에 따라 속도가 느려집니다. 그리고 이것이 앞으로 전체 시스템에 어떤 영향을 미칠지 모르겠습니다.

2. API 호출이 느려집니다.
   주요 프로세스 중 하나는 주문을하는 것입니다. 내 맞춤형 모델은 일부 데이터를 처리하고 본질적으로 sales / quote 모델과 sales / service_quote 모델을 사용하여 처리합니다. 프로세스는 Oauth로 시작합니다. 웹 사이트 / 상점 수가 증가하면 Oauth 및 주문 순서가 더 오래 걸리고 메모리 소비가 더 커 보입니다. 이것은 구성 XML을로드하는 마법사와 관련이 있으며 웹 사이트 수가 증가함에 따라 구성 데이터가 커진다는 사실이 있습니까?

3. n98-magerun dev : console을 여는 데 시간이 오래 걸립니다. 그 원인을 모릅니다.

4. 관리자 패널에서 구성을 저장하면 시간이 더 걸립니다. 그것을 개선하는 방법을 모른다.

Magento가 구성 데이터를 생성하고로드하는 방식을 재구성하여 메모리 소비를 줄일 수 있습니까? 이것이 내 상황에서 성능 문제를 일으키는 요인 중 하나입니까?

현재 마 젠토 인스턴스 : Version = Magento EE 1.14.2.4;
캐시 설정; 다른 캐시 오프;
Mysql 5.6 및 MongoDB 사용 (catalog_category_entity, catalog_product_entity, core_website);
웹 사이트 수 = 상점 수 = 조회수 = 1024;
제품 수 = 4501;

미리 감사합니다!

속도가 느려지는 이유 중 하나는 각 저장소의 구성이 / config / websites 및 / config / global에서 복제되고이를 수행하는 코드가 최소한 효율적이지 않기 때문입니다. 설정 변경으로 인해 몇 시간이 아니라도 수십 분 동안 성능 및 처리량이 감소 할 수 있습니다. 보다 효율적으로 만드는 것은 기본적으로 Ben Marks가 당신을 뒤따를 것입니다.

이 경로를 사용하려는 경우 가장 쉬운 방법은 10k Magento를 설치하고 적절한 웹 사이트에 요청을 위임하는 일종의 브로커를 사용하는 것입니다. 물론 실제 사용 사례에 따라 다릅니다.

[추가]

유스 케이스에 따라 카테고리를 의사 저장소로 사용할 수 있습니다. 그런 다음 기술적으로 레이아웃 XML을 사용하여 상점 당 테마를 변경할 수 있습니다. 그러나 당신은 체크 아웃의 한계에 부딪 칠 것입니다. 모든 상점은 체크 아웃을 공유해야합니다.

어느 쪽이든, 10k 마 젠토 매장은 불가능하지 않다는 점에서 가능합니다. 그러나 어떤 길을 선택하든 어려운 길이 될 것입니다.

코어를 해킹하고 웹 사이트 캐시 분할을 활성화 할 수 있습니다. 데이터베이스를 해킹하고 구성 정보를 메모리에 저장할 수 있습니다. 재정의 데이터를 동적으로 검색하면서 xml 파일 (정적이며 모든 웹 사이트 및 저장소에 적용됨)의 정보를 캐싱하는 등 구성 캐시를보다 스마트 한 것으로 교체해 볼 수 있습니다.

나는 서버 녀석이므로 데이터베이스와 함께 뭉칠 것입니다. 특히 사소하기 때문에.

데이터베이스 서버를 제어 할 수있는 경우 : core_config_data 테이블의 이름을 core_config_data_offline으로 변경하십시오. MEMORY 스토리지 엔진 http://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html을 사용하여 새 core_config_data 테이블을 작성 하십시오. core_config_data_offline에서 core_config_data로 모든 데이터를 복사하십시오.

모든 데이터를 거기에서 core_config_data_offline으로 복사하는 경우 core_config_data가 존재하는지 확인하도록 cron 작업을 설정하십시오. 그렇지 않은 경우이를 작성하고 core_config_data_offline에서 core_config_data로 모든 항목을 복사하십시오.

구성 캐시를 끄십시오. 구성 캐시를 켜면 데이터베이스에서 구성 데이터를 처음으로 읽은 후에 만 ​​성능이 향상됩니다. 그 후에는 캐시에 있고 문제가 발생합니다. 단점은 xml 파일이 더 이상 캐시되지 않기 때문에 많은 XML 파일을 구문 분석하는 성능 적중에 대해 대규모 구성 데이터를 직렬화 해제하는 성능 적중을 교환 한 것입니다.

Mage / Core / Model / Config.php 파일 변경을 실험하고 개별 웹 사이트 캐시를 활성화 할 수도 있습니다. 기본적으로 각 상점 특정 구성 데이터는 개별적으로 캐시됩니다. 모든 웹 사이트 구성 데이터는 하나의 개체에 캐시됩니다.

이는 구성 재정의를위한 것입니다 [관리자 설정]. 따라서 상점 레벨에서 모든 구성 변경을 수행하면 이미 설정되어 있습니다. "웹 사이트에서 상속"을 사용하고 사이트 레벨에서 대부분의 상점 특정 구성을 변경하는 경우 캐시에는 모든 웹 사이트가 포함됩니다. 그것을 나누면 훨씬 더 나아질 수 있습니다. protected $ _cacheSections = array ( 'admin'=> 0, 'adminhtml'=> 0, 'crontab'=> 0, 'install'=> 0, 'stores'=> 1, 'websites'=> 0);

에

protected $_cacheSections = array(
    'admin'     => 0,
    'adminhtml' => 0,
    'crontab'   => 0,
    'install'   => 0,
    'stores'    => 1,
    'websites'  => 1
);