Я запускаю magento на 3 экземплярах Amazon EC2. Один из них настроен для доступа непосредственно для панели администратора, остальные два сидят за балансиром нагрузки.
Все прошло гладко, пока мы не импортировали наши данные с продуктами 20k +, каждый из которых настраивается с ~ 4 простыми продуктами (для разных размеров, цветов и т. Д.),
Единственное, что работает медленным, похоже, – это то, что зацикливается на продуктах – как админ, так и интерфейсные каталожные страницы занимают 5-10 + секунд, чтобы получить ответ от сервера. Статические / CMS-страницы загружаются штрафом.
Все они подключены к одной базе данных RDS MySQL, которая работает нормально – я могу делать запросы и быстро их возвращать.
У нас есть все кеширование (включая полноэкранный кеш) и включены плоские каталоги без реальных изменений скорости.
lsyncd являются независимыми для каждого сервера, за исключением media/ dir, который хранится в синхронизации с lsyncd . Сервер администрирования ведет себя как главный, а два сбалансированных по внешнему фронту серверов являются подчиненными.
Давайте сломаем это:
Допущения, которые я сделаю (пожалуйста, проверьте их)
Странная вещь в вашем вопросе заключается в том, что вы говорите, что у вас есть полный кеш страниц, но передние страницы продукта занимают 5-10 секунд, прежде чем сервер отправит их в браузер.
По-моему, это означает, что полный кеш страниц не работает. Mage.php кеш при правильной реализации будет обслуживать страницу из Apache напрямую, не запуская приложение Magento ( Mage.php ), поэтому он так быстр. Это означает, что при запросе кэшированной страницы нет накладных расходов, поэтому система полного кэша страниц должна иметь «запрашивающие» время менее 0,25 секунды, а иногда и менее 0,1 секунды.
Я предлагаю вам отключить кеш полной страницы и посмотреть, какая разница. Проверьте свою тему и свою документацию по кешу, чтобы узнать, как они обрабатывают контент, не относящийся к кешированию, например, сводку корзины и отображаемое имя пользователя, – но любой кеш должен кэшировать все блоки продукта в любом случае, поэтому страница с интерфейсом конечного продукта должна обращаться к кешу и не обращаться к нему база данных.
Конечно, если у вас есть 20000 продуктов (или 100 000? = 20 000 настроенных + 4 * 20 000 штук), то каждую страницу нужно посещать один раз, чтобы заполнить ваши кеши, чтобы вы могли настроить проверку ссылок на всю ночь, чтобы поразить все ваши URL-адреса и простое полноэкранный кеш для каждой категории и / или страницы продукта.
Mage::getModel(catalog/product)->load($_product->getId())
эта строка сильно ударяет по вашей базе данных, и если вы делаете это для каждого продукта на странице категории, то это вызовет проблемы. Если ваша тема использует ->load() то поговорите с разработчиками темы о создании коллекций с помощью только тех атрибутов, которые им нужны. НО, если у вас есть кэш страниц, это не обязательно имеет значение (поэтому, я думаю, ваш кеш не работает).
core_url_rewrite Скорее всего, эта таблица огромна из-за всех продуктов, которые у вас есть. Это может помочь сделать ваши простые продукты невидимыми и сделать только видимые в каталоге каталоги и поиск. Посмотрите, сколько строк у таблицы есть, усекайте его, затем перейдите в Magento Admin и переиндексируйте перезаписи – это приведет к созданию таблицы, и вы увидите, имеет ли она меньше строк (Magento, похоже, удваивает количество перезаписи время). Также вы получите полный набор перезаписи для каждого магазина в Magento, чтобы удалить все магазины, которые вы не используете.
Теперь еще одна заметка о кэшах. Я нахожу core_url_rewrite одну из шеек бутылки, поэтому я кладу кеш вокруг .phtml который генерирует меню магазина, потому что меню не сильно меняется, и это экономит много времени базы данных. НО, если у вас уже есть кеш, это не будет проблемой, если ваш кеш не работает или не настроен должным образом.
Чтобы вы могли видеть, что так долго держит magento. Я думаю, вам нужно будет отключить кеши, чтобы он работал. Это полезный инструмент для профилирования скорости , но существуют и другие бесплатные инструменты, и на самом деле вы можете просто использовать профилировщик Varien без инструмента. Инструмент даст вам представление о том, что требуется долгое время для создания страницы (но если ваш кеш работает правильно, тогда он выиграл, не важно, как долго сказывается страница, потому что страница будет обслуживаться из кеша, который поэтому я думаю, что ваш кеш не работает).
Но это не проверка того, работает ли ваша база данных нормально или нет. Возможно, вы знаете все это, но вы можете использовать phpmyadmin, чтобы проверить, оптимизированы ли настройки my.cnf. phpmyadmin-> status-> advisor даст вам подсказки для innodb_buffer_pool и key_buffer_size и table_cache . Что бы вы ни делали, Magento не имеет оптимизированных индексов, поэтому mysql всегда будет иметь много работы. Возможно, вам захочется посмотреть ваши файлы innodb, как здесь, здесь (и мне это тоже нужно прочитать ), но если ваш файл ibdata1 и файлы журнала innodb не слишком большие, и у вас ничего нет в медленном запросе журналы, и вы не страдаете слишком большим количеством блокировок, тогда, возможно, нет преимущества для работы с 'innodb_file_per_table' . Некоторые люди предлагают innodb_file_format=Barracuda , но я думаю, что мы входим в тонкую настройку, чтобы выжать последнюю миллисекунду.
Вот поистине превосходный Q & A Stackoverflow о файлах ibdata, оптимизации таблиц и управлении innodb . Предостережение: я не знаю, какой оптимальный innodb настроен для Magento, но когда я читаю статьи, подобные этому, я думаю, что это похоже на правильный путь.
В любом случае вы должны убедиться, что ваш my.cnf настроен на использование доступной для него памяти оптимальным образом (нет никакой магии, я не могу вам сказать, но изучите эти параметры:).
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 =
и запустите « top », чтобы наблюдать за загрузкой памяти и процессора с помощью http-демона и сервера mysql. Иногда я делаю это при запуске моей проверки ссылок, чтобы я мог видеть систему под по меньшей мере небольшой нагрузкой. Если загрузки очень мало, возможно, ваш httpd.conf и my.cnf не будут использовать доступ к CPU и памяти. Если ваш процессор и память получают максимальную отдачу, возможно, вам нужны большие боксы, но если ваш полнофункциональный кеш-файл работает правильно …
Использование top также покажет, был ли скомпрометирован ваш сервер, а все циклы CPU забиты каким-то биткойн-шахтером.
Пойдите в M3 Экстренные коробки, телефон Percona и возьмите все свои советы, получите тонну ОЗУ и запустите свою базу данных в ramdisk, наняйте кого-нибудь из Facebook, чтобы запустить Magento на HHVM, или скажите «вкрутите его» и заплатите эксперту Magento хостинговой компании, чтобы сделать все это за вас. Но если ваш полноэкранный кеш работает …
В любом случае, я надеюсь, вам понравится. Мне нравится, когда Magento работает быстрее. Есть тонна кнопок для настройки, и очень полезно видеть, что время загрузки страницы постепенно уменьшается.
О, я думаю, что медленной области администрирования не поможет полное кэширование страниц, но есть некоторые модули, которые упрощают управление большими каталогами продуктов.
Ваше magento работает медленно, потому что у вас много настраиваемого продукта.
Пожалуйста, проверьте эти статьи
https://github.com/magento/bugathon_march_2013/issues/148
http://turnkeye.com/blog/magento-perfomance-optimization-of-configurable-products/
Моя рекомендация:
благодаря
Попробуйте расширение полной страницы Brim's Cache . Это очень хорошо