Постоянное решение для общей проблемы индексации

Мы разработали некоторый magento-проект с большой инвентарной записью и всегда сталкиваемся с проблемой индексации, которую мы пробовали в интернете для решения повседневных проблем с индексацией, таких как усечение плоских таблиц и повторное индексирование с помощью CLI, установив cron для индексация, но это наша повседневная головная боль, сталкивающаяся с проблемой индексации.

Мы ищем постоянное решение этой проблемы, в то время как мы работаем над проектами, есть разные сценарии, такие как ежедневное обновление продуктов или ежедневный импорт продуктов из какого-либо другого канала.

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

Важно понимать, какие показатели медленные и почему

Сложность каталога и, в конечном счете, архитектура хранилища будут определять время, которое потребуется для переиндексации в сочетании с базовой инфраструктурой.

• Если у вас есть 50 000 товаров и 10 просмотров магазина, вы можете гарантировать, что несколько миллионов строк catalog_url_rewriteпотребуют времени для обработки.

• Если у вас есть 100 продуктов, но 5000 атрибутов, вы можете гарантировать catalog_attributesили catalog_product_flatтаблица будет возраст , чтобы восстановить или упасть плашмя на его лице

• Если у вас есть 1000 товаров, но 500 доступных для поиска атрибутов, то catalog_fulltext_searchснова потребуется время, чтобы завершить

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

• Добавление внешнего кэширования не поможет вообще
• Бросать больше оборудования в сложившейся ситуации может
• Решение проблемы размера / сложности каталога поможет
• Использование сторонних инструментов индексирования поможет
• Внешние определенные индексы (например, поиск> SOLR) помогут

Есть также случай оценки того, требуются ли определенные индексы. Использование плоского продукта / категории не всегда делает все магазины быстрее; мы видели, что это делает магазины намного медленнее. Таким образом, вы можете обнаружить, что после тестирования производительности до / после - это даже не вопрос.

ТЛ; др

Там нет решения серебряной пули. Я предлагаю несколько обходных путей, Sonassi_Fastsearchindexно это специально для поиска по каталогу.

Возможно, отключение обновлений индекса при сохранении - планирование выполнения в одночасье - даст некоторое облегчение? В сочетании с добавлением дополнительного кэширования - memcached, Redis, APC - и полного кеша страниц, такого как Varnish (если вы используете CE), вы можете начать работу. Если вы планируете использовать Varnish, посмотрите Nexcess_Turpentineна github для быстрого старта.

Больше информации

Вопросы индексации, в частности, catalog_url_rewrites, хорошо известны и задокументированы в сообществе. Magento справился с этим в версии Enterprise, потому что это клиенты, которые пострадали больше всего. Многие клиенты EE имеют более 10 тыс. Продуктов и несколько магазинов, веб-сайты и т. Д.

Однако, если у вас большой каталог и большое количество атрибутов, вы можете оказаться в том положении, в котором индексация займет длительный период времени, в частности, catalog_url_rewrite, product_flat, - в этом случае я не советую исправлять время выполнения индекса длина , а скорее разгрузить часть обработки , чтобы коробка тратить процессорное время индексации , а не публикуют .

Вопросы, которые нужно задать себе:

• Я теряю бизнес из-за проблем с индексацией?
• Я теряю производительность из-за проблем с индексацией?
• Могу ли я потерять конверсии или страдает мой коэффициент конверсии?
• Могут ли мои клиенты покупать товары на складе, что является прямым следствием несовпадения индексов (инвентарь и т. Д.)
• Являются ли правила ценообразования моего каталога частью моего основного бизнеса и
• Является ли мой коэффициент конверсии при поиске на сайте выше нормы (8-10%), и, следовательно, выигрывает от лучшей индексации?

Для этой конкретной проблемы не существует решения «серебряной пули» - как поставщик решений вы должны помочь своему клиенту принять решение, которое будет наилучшим образом улучшать продажи и бизнес при сохранении низких накладных расходов.

альтернативы

Переложить поиск по каталогу и многоуровневую навигацию в Solr.

Масштабировать по горизонтали. Добавьте больше серверов Apache / nginx. Больше серверов = больше параллельной пропускной способности. Это не 1: 1. Nexcess имеет отличный технический документ по производительности и конфигурации Apache здесь: http://www.nexcess.net/magento-best-practices-whitepaper

И, если вы решили пойти с лаком - помните:

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

Я создаю новую копию shell / indexer.php> shell / myindexer.php

Настройте shell / myindexer.php примерно на строку 154

} else if ($this->getArg('reindex') || $this->getArg('reindexall')) {

к

} else if ($this->getArg('reindex') || $this->getArg('reindexall')  || $this->getArg('reindexallrequired') ) {

и добавьте эту проверку вокруг строки 166

//reindex only if required
if( $this->getArg('reindexallrequired') && $process->getStatus() == Mage_Index_Model_Process::STATUS_PENDING )
    continue;

до

$startTime = microtime(true);
$process->reindexEverything();
$resultTime = microtime(true) - $startTime;
Mage::dispatchEvent($process->getIndexerCode() . '_shell_reindex_after');

И затем я добавляю новый скрипт оболочки в cpanel cron, чтобы запускать каждые 5 минут

/home/public_html/shell/indexer.php --reindexallrequired >/dev/null

Поскольку приведенный выше сценарий оболочки запускается каждые 5 минут и выполняет переиндексацию только тех процессов, которые требуют переиндексации, он снижает риск большой нагрузки на процессор сервера, а также весь процесс переиндексации очень быстрый. Если ни один процесс не требует переиндексации, он просто не запустит процесс переиндексации. Кроме того, не забудьте установить режим переиндексации на «Обновить при сохранении» на странице управления индексами. Если вы не знаете, вы можете получить эту опцию в Действия> Изменить режим индекса рядом с кнопкой Отправить.

Было бы проще сказать, если бы вы могли предоставить больше данных (размер инвентаря, посетители, машина), но есть возможность:

• мы используем Sonassi_Fastsearchindexрасширение для индекса поиска по каталогу. Хотя он просто индексирует заголовок, описание и sku (думаю, я заметил), он прекрасно работает и сокращает время индексатора каталога поиска.
• скорее всего, будут некоторые индексаторы, которые вам не нужно запускать, например, для тегов или для атрибутов продукта. Иногда бывает достаточно, если вы делаете регулярно только цены, продукты, категории и каталоги, а другие, возможно, ежедневно.
• мы синхронизируем продукты с внешней системой каждые два часа, а тем временем индексируем с помощью php-скриптов. Итак, у нас есть cronjob для каждого индексатора, который мы хотим запустить до определенного времени, и позволить этому cron выполнить скрипт. Похоже, это лучшее промежуточное звено между тем, что может делать сервер, и последними данными о продукте.

Это работает на Magento CE 1.7.0.2; все еще боль, хотя;)

используя Dnd_Patchindexurl, я смог сократить время переиндексации catalog_url_rewrite почти до 70%

Я думаю, что это хорошее решение, чтобы исключить отключенные продукты или невидимые продукты, чтобы их URL создавались даром!

$ php ./shell/indexer.php -reindexall
Product Attributes index was rebuilt successfully in 00:00:11
Product Prices index was rebuilt successfully in 00:00:22
Catalog URL Rewrites index was rebuilt successfully in 00:08:49
Product Flat Data index was rebuilt successfully in 00:00:51
Category Products index was rebuilt successfully in 00:00:19
Catalog Search Index index was rebuilt successfully in 00:00:12
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00

После:

$ php ./shell/indexer.php -reindexall
Product Attributes index was rebuilt successfully in 00:00:12
Product Prices index was rebuilt successfully in 00:00:24
Catalog URL Rewrites index was rebuilt successfully in 00:02:52
Product Flat Data index was rebuilt successfully in 00:00:57
Category Products index was rebuilt successfully in 00:00:25
Catalog Search Index index was rebuilt successfully in 00:00:13
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00

Я установил его на 1.9.1.1 и работает очень хорошо!

Может быть установлен через Connect слишком http://www.magentocommerce.com/magento-connect/catalog/product/view/id/15074/s/dn-d-patch-index-url-1364/category/12863/

Обновление до EE 1.13. Индексаторы были значительно улучшены в этой версии.