Тонкая настройка пурпурного

Ответ 1

Magento - чрезвычайно гибкая инфраструктура электронной коммерции, но эта гибкость имеет цену: производительность. Этот ответ представляет собой набор указателей и некоторые подробности кэширования (особенно для блоков).

Одна вещь, которую следует учитывать, - это среда Magento, например. настройка php, веб-сервера (поддержка nginx поверх Apache) и MySQL. Кроме того, настройте хорошее кэширование для Magento. Все они покрыты, например. в Magento Performance Whitepaper, который также относится к CE.

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

Вы также не можете сократить время, затрачиваемое на создание блоков, кроме как путем настройки среды (APC, памяти, CPU). Как и другие комментаторы, ваш лучший выбор заключается в использовании функций кэширования, которые Magento встроил.

Масштабирование блочного кэширования

Поскольку вы конкретно упомянули блоки в вопросе, я подробно рассмотрю кэширование блоков. Кэширование блоков определяется тремя свойствами:

• cache_lifetime
• cache_key
• cache_tags

Все эти свойства могут быть установлены в методе _construct() для блока с помощью setData() или магов-установщиков или путем реализации связанных методов getter (getCacheLifetime(), getCacheKey(), getCacheTags()).

cache_lifetime указывается в (целых) секундах. Если он установлен на false (boolean), блок будет кэширован навсегда (без истечения срока действия). Если он установлен в null, блок не будет кэшироваться (это значение по умолчанию указано в Mage_Core_Block_Abstract).

cache_key - это уникальная строка, которая используется для идентификации записи кэша в пуле кеша. По умолчанию он построен из массива, возвращаемого методом getCacheKeyInfo().

// Mage_Core_Block_Abstract
public function getCacheKeyInfo()
{
    return array(
        $this->getNameInLayout()
    );
}

public function getCacheKey()
{
    if ($this->hasData('cache_key')) {
        return $this->getData('cache_key');
    }
    /**
     * don't prevent recalculation by saving generated cache key
     * because of ability to render single block instance with different data
     */
    $key = $this->getCacheKeyInfo();
    //ksort($key);  // ignore order
    $key = array_values($key);  // ignore array keys
    $key = implode('|', $key);
    $key = sha1($key);
    return $key;
}

Лучший способ настроить кеш-ключ в пользовательских блоках - переопределить метод getCacheKeyInfo() и добавить данные, которые необходимы для уникальной идентификации кэшированного блока по мере необходимости.

Например, чтобы кэшировать другую версию блока в зависимости от группы клиентов, вы могли бы сделать:

public function getCacheKeyInfo()
{
    $info = parent::getCacheKeyInfo();
    $info[] = Mage::getSingleton('customer/session')->getCustomerGroupId()
    return $info;
}

cache_tags - это массив, который разрешает сегментацию кеша. Вы можете удалить разделы кэша, соответствующие только одному или нескольким тегам.
В интерфейсе администратора в разделе "Система" > "Управление кешем" вы можете увидеть пару доступных кеш-кетов по умолчанию (например, BLOCK_HTML, CONFIG,...). Вы также можете использовать пользовательские кеш-теги, просто указав их.
Это часть реализации Zend_Cache, и ее нужно настраивать гораздо реже по сравнению с cache_lifetime и cache_key.

Другое кэширование

Помимо блоков Magento кэширует много других вещей (данные коллекции, конфигурация,...).
Вы можете кэшировать свои собственные данные с помощью Mage::app()->saveCache(), Mage::app()->loadCache(), Mage::app()->cleanCache() и Mage::app()->removeCache(). Подробнее об этих методах смотрите в разделе Mage_Core_Model_App, они довольно прямолинейны.

Вы также захотите использовать модуль полнотекстового кэша. Если вы используете Magento EE, у вас уже есть один. В противном случае поиск Magento Connect - есть много вариантов (коммерческих).
Некоторые из этих модулей также настраивают различные части Magento для вас за рамки полного кеширования страницы, например. Nitrogento (коммерческий).

Использование обратного прокси, такого как Varnish, также очень полезно.

На эту тему довольно много сообщений в блогах. Здесь одно сообщение издателями расширения Nitrogento.
Если вы используете Magento в более низкой среде, проверьте мой пост на оптимизацию бэкэнда файлового кэша на magebase.com.

Ответ 2

Этот поток старый, но очень полезный. Я добавляю дополнительные комментарии для скорости:

• Вместо использования Apache используйте nginx или litespeed.
• Убедитесь, что используется плоский каталог.
• Если возможно, используйте FPC.
• для режима компилятора.
• Объединить css и js (Fooman Speedster).
• Используйте спрайты изображений, чтобы уменьшить количество запросов.
• Используйте кеш запросов, но не превышайте размер более 64 МБ.
• Удалите все модули, которые не используются, удалив там xml. Простое отключение не будет.
• Сессия должна быть в Раме.
• Рекомендуется использовать APC.
• Ваш cron должен работать в автономном режиме.
• Удалите дополнительные магазины, если они не используются.
• Удалить правила корзины, если они не используются.
• оптимизировать изображение для размера.
• Используйте Ajax, где это возможно.
• Блоки CMS занимают больше времени, чем блок magento, поэтому, если вы не хотите, чтобы блок был изменен, не используйте блоки CMS.
• Не используйте коллекцию использования count count getSize, чтобы получить размер коллекции.
• Свести к минимуму количество доступных для поиска атрибутов, поскольку они приводят к столбцам в таблице плоских каталогов и замедляют поиск.
• Рекомендуется использовать поиск Solr. Он поставляется с версией EE, но он также может быть установлен с CE.
• Свернуть группу клиентов, как указано в комментарии.
• Включить сжатие в .htaccess(mod_gzip для Apache 1.3, mod_deflate для Apache 2)
• Удаление промежуточных хранилищ, если на EE.
• Используйте Apache mod_expires и не забудьте указать, сколько файлов нужно кэшировать. Если вы находитесь на сервере Apache.
• Используйте сеть доставки контента (CDN).
• Включить Apache KeepAlives.
• Сделайте свой выход совместимым с W3C
• Рекомендуется использовать getChildHtml ('childName'), поскольку это будет блокировать кеш от прямого использования блочного кода в файле .phtml.
• Убедитесь, что cron запущен, чтобы очистить журналы, хранящиеся в базе данных.
• Количество журналов дней должно быть минимизировано в соответствии с требованиями.
• Загрузите кеш в ОЗУ, если позволяет память.
• Уменьшение количества файлов на жестком диске и чтение прошивок из ram, так как это быстрее.
• Обновление версии PHP до версии 5.3
• Если на EE убедитесь, что большинство страниц доставлено без инициализации приложения. Даже если одному контейнеру требуется инициализация приложения, он собирается выполнить скорость выполнения, так как отдельный URL-адрес переписывает большую часть другого кода, будет выполнен.
• Отметьте XML для блоков, помещенных в дескриптор по умолчанию, и если эти блоки не на определенной странице, переместите эти значения XML из дескриптора по умолчанию в определенные дескрипторы. Было отмечено, что выполняется множество блоков, которые не отображаются.
• Если вы используете FPC, убедитесь, что ваши контейнеры кэшированы, а запрос повторного запроса для контейнера доставлен с помощью cache.Improper определение определения места в кеше контейнера не используется, но каждый раз, когда создается новый контент контейнера.
• Анализ блоков страниц и переменных и, если возможно, добавьте эти переменные/блоки в кеш.
• Отключить записи в Magento.
• Удалить модуль уведомлений администратора.
• Использование спрайтов изображений.
• Используйте несколько инструментов веб-тестирования для анализа количества запросов и других связанных с html-параметров, ответственных за время загрузки, и действуйте соответственно.
• Удалите атрибуты, если они не нужны. При правильном уходе мы можем даже удалить системные атрибуты, если они не используются. 42: Если на предприятии убедитесь, что частичное индексирование эффективно используется.
• Напишите свой собственный поиск solr для обхода индексации поиска Magento.
• Очистить таблицы _cl или уменьшить строки таблицы _cl.
• Я бы добавил в список: старайтесь избегать кеша файлов, если это возможно, замените его на apc/redis/memcache (как было предложено Jaro)
• Удалить системные атрибуты, которые не используются (будьте осторожны, выполните тщательную проверку перед удалением).
• Есть несколько заданий заготовки cron, которые не применимы ко всем магазинам, поэтому в зависимости от ваших свойств магазина они могут быть удалены.
• Оптимизация с помощью правильного управления атрибутами, например установка обязательного атрибута, да или поиск или необходимость в листинге и т.д.
• Некоторые наблюдатели не требуются для всех магазинов, поэтому, если эти наблюдатели не применимы к конкретному сайту Magento, их следует удалить.
• Убедитесь, что FPC применим к большинству страниц сайта. Специально, когда вы добавили некоторые новые контроллеры для доставки страницы.
• Magento имеет множество функций. Для этого у него много событий и связанных наблюдателей. Есть несколько функций, которые не используются в магазине, поэтому любой наблюдатель, связанный с этой функцией, должен быть удален. ru: Если вы проверяете версию предприятия, которая, если не используется, затем рекомендует, чтобы при сохранении после удаления разрешения наблюдатели, связанные с разрешением, были удалены.
• Если конкретный атрибут должен быть сохранен для продукта, тогда вместо вызова $product- > save вызовите функцию, которая сохранит определенный атрибут.
• В версии EE, которая имеет частичную индексацию и триггеры, модифицирует триггеры, чтобы избежать нескольких записей в таблицах to_cl.
• Файлы nophtml обходят блоки и напрямую используют модули или ресурсы. Поскольку это не приведет к кешированию, что в свою очередь означает больше работы для Magento.
• Передача изображений в зависимости от используемого устройства.
• Некоторые из рекомендованных FPC для сообщества: Lesti (бесплатно по состоянию на дату), Amasty (коммерческий), расширитель (коммерческий) и Bolt (коммерческий).
• Кэш утечки.
• Управление ботами на .htaccess в пиковые часы.
• Предварительно заполнение значений в пользовательской таблице для многоуровневой навигации через пользовательский script, выполняемый ежедневно cron.
• Обязательно избегайте нежелательных ключей для уменьшения размера кэша.
• Использование более высокой версии PHP 5.4 +
• Использование более высокой версии Mysql (5.5 +)
• Уменьшить количество элементов Dom.
• Переместите все js из html-страниц.
• Удалить комментарий html.
• Измените триггеры, если на корпоративной версии (1.13 или выше), чтобы восстановить элементы таблицы _cl. Поскольку эти записи приводят к промывке кеша, что, в свою очередь, приводит к более низкому попаданию в кэш, следовательно, больше времени TTFB.
• Используйте Magmi для импорта продуктов.
• Некоторые важные ссылки: - http://www.oscprofessionals.com/blog/understanding-full-page-cache-concept-magento/ и - http://dionbeetson.blogspot.com.au/2014/11/magento-performance-tips-for-scalability.html

Ответ 3

Как сказал Винай, Magento все о расширяемости, а сырая производительность вторична, но исправлена ​​такими вещами, как индексирование и кеширование. Значительно улучшить производительность без кеширования будет очень сложно. Недостаточно полностраничного кэширования, включение блочного кэширования - хороший метод повышения производительности, но ключевое значение имеет недействительность кэша. Многие блоки кэшируемые, но не настроенные для кэширования по умолчанию, поэтому идентифицируйте самые медленные, используя профилирование, используя руководство Vinai для включения кэширования. Вот несколько дополнительных вещей, которые следует учитывать при кэшировании блоков:

• В любом блоке, в котором содержится информация о продукте, должен быть тег продукта 'catalog_product_'.$productId. Аналогичным образом используйте категории 'catalog_category_'.$categoryId для категорий. Это гарантирует, что кэш недействителен при сохранении продукта или категории (отредактирован в бэкэнд). Не устанавливайте их в конструкторе, устанавливайте их в переопределенном getCacheTags(), чтобы они собирались только тогда, когда блок был сохранен, а не когда он загружен из кеша (так как это победит цель его кеширования).
• Если вы используете https, и блок может отображаться на странице https и включает статические ресурсы, убедитесь, что кэш-ключ содержит Mage::app()->getRequest()->isSecure(), иначе вы получите http-urls на https-страницах и наоборот.
• Убедитесь, что ваш сервер кэша имеет большую емкость и избегает ненужных сбросов кешей.
• Не кэшируйте дочерние блоки блока, который сам кэшируется, если родительский элемент не изменяется гораздо чаще, чем дочерние блоки, иначе вы просто загромождаете свой кеш-сервер.
• Если вы правильно помечаете кэширование, вы сможете безопасно использовать очень длительный срок службы кеша по умолчанию. Я считаю, что установка "false", поскольку время жизни фактически использует значение по умолчанию, а не бесконечно. По умолчанию используется 7200 секунд, но может быть настроено в local.xml.
• Использование redis backend в большинстве случаев даст вам лучшую и наиболее стабильную производительность. При использовании Redis вы можете контролировать используемый размер памяти, используя этот плагин munin.

Ответ 4

Просто для продолжения работы с Mark... большинство таблиц в базе Magento - InnoDB. В то время как кеш запросов может использоваться в нескольких конкретных местах, следующие более непосредственно релевантные...

innodb_buffer_pool_size
innodb_thread_concurrency
innodb_flush_method
innodb_flush_log_at_trx_commit

Я также использую

innodb_file_per_table

поскольку это может быть полезно при реорганизации определенных таблиц.

Если вы даете базе данных достаточный ресурс (в пределах разумного), объем трафика действительно не загружает сервер вообще, так как большинство запросов повторяется в любом случае и доставляются из кеша базы данных.

Другими словами, вы, вероятно, ничего не беспокоитесь...

Ответ 5

Убедитесь, что кеш запросов mysql включен. И установите эти переменные в mysql (возможно, вам нужно настроить в зависимости от вашей установки).

query_cache_type=1
query_cache_size=64M

Ответ 6

Я нашел очень интересное сообщение в блоге о оптимизации производительности Magento, есть много настроек конфигурации для вашего сервера и вашего магазина magento, было очень полезно для меня.

http://www.mgt-commerce.com/blog/magento-on-steroids-best-practice-for-highest-performance/

Ответ 7

Сначала вам нужно провести аудит и оптимизировать время до первого байта (TTFB).

Magento имеет встроенный профилировщик, который поможет вам идентифицировать неоптимизированные блоки кода.

Изучите ваши файлы шаблонов и убедитесь, что вы НЕ загружаете модели продукта внутри цикла (общий хог производительности):

foreach($collection as $_product){
   $_product = Mage::getModel('catalog/product')->load($_product->getId()

Я часто вижу этот код в файле /list.phtml

Я написал пошаговую статью о как оптимизировать TTFB

Отказ от ответственности: ссылка указывает на мой собственный сайт