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

23

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

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

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

ravisoni
источник
Я потратил год на Magento и его расширения, а также на его чрезвычайно неэффективную и идиотскую архитектуру данных, которая делает сайт электронной коммерции всего с 10 тысячами продуктов плюс. Все эти предупреждения должны были быть даны любому, кто начинает видеть Magento CE. Представители Magento должны быть привлечены к суду за то, что потратили тысячи человеко-часов. Просто дайте базе данных выполнить индексацию, не выполняйте работу базы данных. Я советую вместо того, чтобы тратить деньги на выделенный сервер, а затем на тонны ночной бессонной работы, лучше перейти на хостинговую платформу электронной коммерции или с открытым исходным кодом, использующим сервер MS SQL.
semiprecious.com
Вы когда-нибудь думали, что, возможно, вы не нашли правильное расширение или правильную конфигурацию сервера? Если какое-то программное обеспечение не соответствует вашим потребностям, это не обязательно означает, что оно бесполезно. Последние 5 с лишним лет я зарабатывал свой хлеб (и пиво) в Magento, и у меня тоже было много довольных клиентов. Некоторые с более чем 10 тыс. Каталогов.
Мариус
Они верны, потому что CE работает с данными - это проблема от 10 до 100 тысяч тысяч скусов. EE лучше благодаря обновлениям индексации, которые они сделали, но это для компаний с многомиллионным доходом. Вы можете бросить хостинг на это, но вы превратите свою рентабельность в минус. Используемое нами решение - это очень специализированные и разностные загрузки, аналогичные решениям, таким как использование SAP и Walmart, в сочетании со специальным решением по ценообразованию (ATG-esque), которое обходит проблему индексации (fx & inline margin / attribute recalcs) в сочетании с кластером. хостинг. Простой ответ: нет, Magento не был разработан оптимально.

Ответы:

31

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

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

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

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

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

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

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

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

Бен Лессани - Сонасси
источник
8

ТЛ; др

Там нет решения серебряной пули. Я предлагаю несколько обходных путей, 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

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

введите описание изображения здесь

philwinkle
источник
Мы ценим реквизиты, но переиндексация не имеет ничего общего с внешним кэшированием; это полностью бэкэнд-операция. Облегчение внешней нагрузки предотвратит повторное индексирование, которое займет больше времени, но, безусловно, не сделает его быстрее
Бен Лессани - Сонасси
То, к чему я стремлюсь, - это уменьшение трафика, приходящего на ящик. Главной проблемой здесь является то, что сайт становится недоступным во время индексации или блокируется в течение неизвестного периода времени во время выполнения заданий. В конце концов, если индексирование не оказывает негативного влияния на интерфейс, не имеет значения, как долго выполняется задание. Нет никакого исправления или улучшения индексации времени загрузки. Никто не хочет получить ответ «Обновление до платной версии», поэтому я предлагаю улучшить доступность внешнего интерфейса и запланировать запуск индекса в непиковое время.
Philwinkle
Абсолютно, я понял это, но хотя доступность важна для веб-сайта; его недостаточно для сайта электронной коммерции. Если вы не можете совершить покупку из-за блокировки индексов, сайт может быть отключен.
Бен Лессани - Сонасси
у нас всего несколько сотен продуктов, и все еще требуется несколько минут, чтобы сохранить простой продукт на Magento 1.7, и я плачу более 500 долларов в месяц за выделенный сервер Rackspace. Я не уверен, с чего начать, но подозреваю, что какой-то индекс, возможно, поврежден. Кто-нибудь может порекомендовать хорошего консультанта magento?
Макс Ходжес
5

В большинстве крупных интернет-магазинов 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 минут и выполняет переиндексацию только тех процессов, которые требуют переиндексации, он снижает риск большой нагрузки на процессор сервера, а также весь процесс переиндексации очень быстрый. Если ни один процесс не требует переиндексации, он просто не запустит процесс переиндексации. Кроме того, не забудьте установить режим переиндексации на «Обновить при сохранении» на странице управления индексами. Если вы не знаете, вы можете получить эту опцию в Действия> Изменить режим индекса рядом с кнопкой Отправить.

rbncha
источник
@ changeling, пожалуйста. Я рад, что оно того стоит.
рбнча
Я включил это в свой сценарий, на случай, если кто-нибудь найдет его полезным: gist.github.com/steverobbins/…
Стив Роббинс
4

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

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

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

simonthesorcerer
источник
Мы обычно сталкиваемся с проблемой с товаром, все остальные индексы в порядке.
ravisoni
3

используя 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/

веб-сайт maurisource
источник
1

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

Пол Григорута
источник
2
Но большинство клиентов предпочитают версию сообщества.
ravisoni
1
Согласовано. 1.8 выйдет через пару недель, но, скорее всего, он не будет включать оптимизацию индексатора. Мне это тоже не нравится, но это самый простой, безопасный и, возможно, самый дешевый способ заставить ваши индексаторы работать.
Павел Григорута
Это невозможно найти постоянное решение.
ravisoni
В большинстве случаев, когда у кого-то так много SKU, что он действительно сталкивается с кирпичной стеной с существующими индексаторами CE 1.7, он должен использовать EE 1.13. Существует множество хорошо работающих сайтов с этими индексаторами CE 1.7 и EE 1.12, имеющими 10-25 тыс. SKU. Ключ заключается в том, чтобы управлять ими прямо на уровне рабочего процесса и иметь правильную инфраструктуру.
Давидгер
CE - это совершенно адекватный выбор. В особенности в EE 1.13 являются исправления ошибок - что сообщество загнан в СЕ в любом случае. Независимо от этого и независимо от того, используете ли вы CE или EE, время индексации всегда будет полностью зависеть от сложности каталога, конфигурации сервера, параллелизма посетителей и частоты повторного индексирования. EE не волшебная палочка и, конечно, не является подходящим решением для любой проблемы, связанной с архитектурой.
Бен Лессани - Сонасси