Как лучше всего исправить медленную работу Magento с более чем 20000 продуктами?

Давайте разберем это:

1. Предположения, которые я сделаю (пожалуйста, проверьте их)

   • Вы используете достаточно мощные инстансы EC2, например m3.large
   • Вы используете кеш PHP, такой как APC
   • Вы используете систему компиляции Magento->инструменты->компиляция
   • Вы используете веб-сервер Apache
   • «От 5 до 10 секунд, чтобы получить ответ от сервера» означает время ответа и не включает время загрузки изображения, CSS и JS в браузер
   • У вас есть плоские таблицы для продуктов и категорий (но если ваш кеш работает правильно, это не должно доминировать в скорости. Вы также должны запускать тесты без плоских таблиц; они не всегда быстрее)
   • Конфигурация вашего веб-сервера оптимизирована для больших объемов трафика для заголовков "keep actives" и "expires"

1. Тройная проверка полностраничного кеширования

По-настоящему странная вещь в вашем вопросе заключается в том, что вы говорите, что у вас есть полный кеш страницы, но интерфейсным страницам продукта требуется от 5 до 10 секунд, прежде чем сервер отправит их в браузер.

На мой взгляд, это означает, что ваш полный кеш страницы не работает. Полный кеш страницы, если он реализован должным образом, будет обслуживать страницу непосредственно из Apache без запуска приложения Magento (Mage.php), поэтому это так быстро. Это означает, что при запросе кэшированной страницы нет накладных расходов, и именно поэтому система полного кеширования страницы должна иметь время «запроса» менее 0,25 секунды, а иногда и менее 0,1 секунды.

Я предлагаю вам отключить полный кеш страницы и посмотреть, какая разница. Проверьте свою тему и документацию кеша, чтобы узнать, как они обрабатывают не кэшируемое содержимое страницы, такое как сводка корзины и отображаемое имя пользователя, но любой кеш в любом случае должен кэшировать все блоки продукта, поэтому создание интерфейсной страницы продукта должно иметь доступ к кешу, а не к база данных.

Конечно, если у вас 20000 продуктов (или 100000? = 20000 настроенных + 4 * 20000 простых), тогда каждую страницу нужно посетить один раз, чтобы заполнить ваши кеши, поэтому вы можете настроить проверку ссылок, работающую в течение ночи, чтобы поразить все ваши URL-адреса и заполнить полный кеш страницы для каждой категории и / или страницы продукта.

1. Проверьте файлы .phtml вашей темы на предмет ужасных

Mage::getModel(catalog/product)->load($_product->getId())

Эта строка попадает в вашу базу данных сильно , и если вы делаете это для каждого продукта на странице категории, это вызовет проблемы. Если ваша тема использует ->load(), поговорите с дизайнерами вашей темы о создании коллекций только с теми атрибутами, которые им нужны. НО, если у вас есть кеш страницы, это не обязательно имеет значение (поэтому я думаю, что ваш кеш не работает).

1. Взгляните на свой стол core_url_rewrite

Скорее всего, эта таблица огромна из-за всех имеющихся у вас продуктов. Это может помочь сделать ваши простые продукты невидимыми и сделать видимыми только настраиваемые параметры в каталоге и поиске. Проверьте, сколько строк имеет таблица, обрежьте ее, затем перейдите к администратору Magento и переиндексируйте перезаписи - это перестроит таблицу, и вы сможете увидеть, меньше ли в ней строк (Magento, кажется, удваивает много перезаписей поверх время). Также вы получите полный набор перезаписей для каждого магазина в Magento, поэтому удалите все магазины, которые вы не используете.

Теперь еще одно замечание о тайниках. Я нахожу core_url_rewrite одним из узких мест, поэтому я помещаю кеш вокруг .phtml, который генерирует меню магазина, потому что меню не сильно меняется и это значительно экономит время базы данных. НО, если у вас уже есть кеш, это не будет проблемой, если ваш кеш не работает или не настроен должным образом.

1. Заставьте работать профилировщик Varien

Чтобы вы могли видеть, что так долго занимает Magento. Я думаю вам нужно будет отключить кеши, чтобы он заработал. Это полезный инструмент для профилирования скорости, но существуют и другие бесплатные инструменты. и на самом деле вы можете просто использовать профилировщик Varien без инструмента. Инструмент даст вам представление о том, что требуется много времени для создания на странице (но если ваш кеш работает должным образом, это не имеет значения; не имеет значения, как долго страница будет строиться, потому что страница будет обслуживаться из кеша, который вот почему я думаю, что ваш кеш не работает).

1. Вы говорите: «База данных MySQL работает нормально - я могу выполнять запросы и быстро их возвращать».

Но это не проверка того, нормально ли работает ваша база данных. Возможно, вы все это знаете, но вы можете использовать phpmyadmin, чтобы проверить, оптимизированы ли ваши настройки my.cnf. phpmyadmin-> status-> Advisor даст вам подсказки для innodb_buffer_pool, key_buffer_size и table_cache. Что бы вы ни делали, у Magento нет оптимизированных индексов, поэтому у mysql всегда будет много работы. Возможно, вы захотите просмотреть свои файлы innodb, как это предлагается здесь (и я это тоже необходимо прочитать) , но если ваш файл ibdata1 и файлы журнала innodb не слишком велики, и у вас ничего нет в журналах медленных запросов, и вы не страдаете от слишком большого количества ожиданий блокировок, то, возможно, нет преимуществ в использовании с { {X3}}. Некоторые предлагают innodb_file_format=Barracuda , но я думаю, что мы приступаем к тонкой настройке, чтобы выжать последнюю миллисекунду.

Вот действительно отличный Q&A Stackoverflow о файлах ibdata, оптимизации таблиц и управлении innodb . Предостережение: я не знаю оптимального innodb, настроенного для Magento, но когда я читаю подобные статьи, я думаю, что это правильный путь.

max_allowed_packet =  
table_cache =  
sort_buffer_size =   
read_buffer_size =   
read_rnd_buffer_size =   
myisam_sort_buffer_size =   
tmp_table_size =   
max_heap_table_size =  
query_cache_size =  
query_cache_type =  
thread_cache_size =  

innodb_fast_shutdown = 0  
innodb_file_per_table  
innodb_buffer_pool_size =  
innodb_additional_mem_pool_size =  
innodb_log_file_size =  
innodb_log_buffer_size =  
innodb_flush_log_at_trx_commit =  
innodb_lock_wait_timeout =  
innodb_thread_concurrency =  
skip-external-locking  
max_connections =  
read_buffer_size =  
sort_buffer_size =  
key_buffer_size =