Настройка magento для производительности - PullRequest
14 голосов
/ 09 февраля 2012

Я смотрю на производительность (время загрузки сервера) сайта magento и пытаюсь настроить страницы результатов поиска. Я понял, что когда я отключил все тяжелые вещи, такие как верхняя навигация, многоуровневая навигация и список продуктов, и очистил весь кэш, то после того, как это ядро ​​magento выполнит 60 запросов SQL к базе данных. У кого-нибудь есть какие-либо процедуры, как избавиться от них или как уменьшить их до приемлемого уровня?

Также можно ли как-то сократить время, затрачиваемое на создание блоков?

Большое спасибо, Яро.

Ответы [ 7 ]

28 голосов
/ 10 февраля 2012

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

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

После настройки среды другой стороной является код.
Для некоторых страниц возможно уменьшение количества запросов путем включения каталога плоских таблиц ( Система> Конфигурация> Каталог> Интерфейс ), но у вас всегда будет большое количество запросов.

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

Кэширование блоков Magento

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

  1. cache_lifetime
  2. cache_key
  3. cache_tags

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

cache_lifetime указывается в (целых) секундах.Если установлено значение false (логическое значение), блок будет кэширован навсегда (без истечения срока действия).Если установлено значение 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 подробности об этих методах, они довольно просты.

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

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

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

11 голосов
/ 17 марта 2013

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

  1. Вместо использования Apache используйте nginx или litespeed.
  2. Убедитесь, что используется плоский каталог.
  3. Если возможно, используйте FPC.
  4. режим компилятора, который будет включен.
  5. Объединение CSS и JS (Fooman Speedster).
  6. Использование спрайтов изображений для уменьшения количества запросов.
  7. Использованиекеш запросов, но избегайте размера, превышающего 64 МБ.
  8. Удалите все неиспользуемые модули, удалив туда xml. Просто отключение не будет.
  9. Сеанс на Ram.
  10. Рекомендуется использование APC.
  11. Ваш cron должен работать в нерабочее время.
  12. Удалите дополнительные магазины, если они не используются.
  13. Удалите правила корзины, если они не используются.
  14. оптимизация изображения под размер.
  15. Используйте Ajax везде, где это возможно.
  16. Блоки CMS занимают больше времени, чем блок magento, поэтому, если вы не хотите, чтобы блок был изменен, не используйте CMSблоки.
  17. Не используйте счетчик коллекций. Используйте коллекцию getSize, чтобы получить значениеection size.
  18. Минимизируйте количество доступных для поиска атрибутов, так как они приводят к появлению столбцов в плоской таблице каталога и замедляют поиск.
  19. Рекомендуется использовать поиск Solr.Он поставляется с версией EE, но также может быть установлен вместе с CE.
  20. Минимизировать группу клиентов, как указано в комментарии.
  21. Включить сжатие в .htaccess (mod_gzip для Apache 1.3, mod_deflate для Apache 2)
  22. Удалите промежуточные хранилища, если в EE.
  23. Используйте Apache mod_expires и обязательно укажите, как долго файлы должны кэшироваться. В случае, если вы находитесь на сервере Apache.
  24. ИспользованиеСеть доставки контента (CDN).
  25. Включить Apache KeepAlives.
  26. Сделать вывод W3C-совместимым
  27. Рекомендуется использовать getChildHtml ('childName'), поскольку это приведет к кешированию блокапротив прямого использования кода блока в файле .phtml.
  28. Убедитесь, что cron запущен для очистки журналов, хранящихся в базе данных.
  29. Количество дней, которое журнал должен быть минимизирован согласно требованию.
  30. Загрузка кэша в ОЗУ, если позволяет память.
  31. Уменьшите чтение файлов с жесткого диска и попробуйте чтения из оперативной памяти, поскольку это быстрее.
  32. Обновите версию PHP до версии выше 5.3
  33. Если в EE убедиться, что большинство страниц доставляются без инициализации приложения. Даже если одному контейнеру требуется инициализация приложения, это повлияет на скорость выполнения, так как отдельно переписанный URL-адрес формы переписывает большую часть другого кода.
  34. Проверьте XML на наличие блоков, помещенных в дескриптор по умолчанию, и, если эти блоки отсутствуют на конкретной странице, переместите эти значения XML из дескриптора по умолчанию в определенные дескрипторы. Было замечено, что выполняется много блоков, которые не отображаются.
  35. Еслииспользуя FPC, убедитесь, что ваши контейнеры кэшируются, и повторный запрос для контейнера доставляется через кеш. Неправильное определение заполнителя приводит к тому, что кеш контейнера не используется, но каждый раз при создании нового содержимого контейнера.
  36. Анализ блоков страницы и переменных, и еслиможно добавить эти вариантыумеет / блокирует кеширование.
  37. Отключение записи логов в Magento.
  38. Удаление модуля уведомлений администратора.
  39. Использование спрайтов изображений.
  40. Использование некоторых вебинструмент тестирования для анализа количества запросов и других html-параметров, отвечающих за время загрузки и соответствующих действий.
  41. Удаляйте атрибуты, если они не нужны. При должном внимании мы можем даже удалить системные атрибуты, если они не используются.42: Если на предприятии убедитесь, что частичная индексация эффективно используется.
  42. Напишите свой собственный поиск по запросу, чтобы обойти индексацию поиска Magento.
  43. Очистите таблицы _cl или уменьшите строки таблицы _cl.
  44. Я бы добавил в список: старайтесь по возможности избегать кеширования файлов, замените его на apc / redis / memcache (как предложено Jaro)
  45. Удалите системные атрибуты, которые не используются (будьте осторожны, тщательно проверьтеперед снятием).
  46. Существуют некоторые задания с вкладками cron, которые не применимы ко всем магазинам, поэтому в зависимости от функций вашего магазина их можно удалить.
  47. Оптимизация путем правильного управления атрибутами, например, установка для обязательного атрибута значения yes или для поиска или для обязательного поиска всписок и т. д.
  48. Некоторые наблюдатели требуются не для всех магазинов, поэтому в случае, если эти наблюдатели не применимы к конкретному сайту Magento, их следует удалить.
  49. Убедитесь, что FPC применима к большинствустраницы сайта.Особенно, когда вы добавили несколько новых контроллеров для доставки страницы.
  50. Magento имеет множество функций. Для этого у него много событий и связанных наблюдателей. Есть несколько функций, которые не используются магазином, поэтому любой наблюдатель, связанный сэта функция должна быть удалена. Например: если вы проверяете корпоративную версию, существует концепция разрешения категории, которая, если она не используется, рекомендуется удалить при сохранении после событий связанных с разрешением наблюдателей.
  51. Если указан определенный атрибутсохраните для продукта, затем вместо вызова $ product-> save вызовите функцию, которая сохранит определенный атрибут.
  52. В версии EE с частичной индексацией и триггерами изменяются триггеры, чтобы избежать нескольких записей в таблицах to_cl.
  53. .phtml-файлы обходят блоки и напрямую используют модули или ресурсы. Так как это приведет к отсутствию кэширования, что, в свою очередь, означает больше работы для Magento.
  54. Доставка изображений в зависимости от используемого устройства.
  55. Некоторые из FPC рекомендованы для сообщества:Lesti (бесплатно по состоянию на дату), Amasty (коммерческий), extender (коммерческий) и Bolt (коммерческий).
  56. Wash Cache.
  57. Управление ботами с помощью .htaccess в часы пик.
  58. Предварительное заполнение значений в настраиваемой таблице для многоуровневой навигации с помощью настраиваемого сценария, который ежедневно выполняется cron.
  59. Обеспечение избежания нежелательных ключей для уменьшения размера кэша.
  60. Использование более высокого уровняВерсия PHP 5.4 +
  61. Использование более высокой версии Mysql (5.5 +)
  62. Уменьшить количество элементов Dom.
  63. Переместить все js из html-страниц.
  64. Удалить закомментированный html.
  65. Изменить триггеры, если на корпоративной версии (1.13 или выше), чтобы уменьшить количество записей в таблице _cl. Поскольку эти записи приводят к очистке кеша, что, в свою очередь, приводит к меньшему обращению к кешу, следовательно, к увеличению времени TTFB.
  66. Используйте Magmi для импорта товаров.
  67. Некоторые важные ссылки: - 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 голосов
/ 11 февраля 2012

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

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

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

innodb_buffer_pool_size
innodb_thread_concurrency
innodb_flush_method
innodb_flush_log_at_trx_commit

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

innodb_file_per_table

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

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

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

1 голос
/ 13 сентября 2012

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

http://www.mgt -commerce.com/ блог / Magento-на-стероидах-передовой практики по вопросам всевышнего производительности /

1 голос
/ 10 февраля 2012

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

query_cache_type=1
query_cache_size=64M
0 голосов
/ 11 октября 2016

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

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

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

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

Я часто вижу этот код в product / list.phtml

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...