Постійне рішення загальної проблеми індексації

Ми розробили проект magento з великим записом інвентаризації і завжди стикаємося з проблемою індексації. Ми намагалися вирішити все, що знайдеться в Інтернеті, для вирішення питання щоденного індексування, наприклад, обрізання плоских таблиць та переіндексація за допомогою CLI, встановлення крона для індексація, але це наш щоденний головний біль, що стикається з проблемою індексації.

Ми шукаємо постійне рішення цієї проблеми, коли ми працюємо над проектами, існують різні сценарії, такі як оновлення продуктів на щоденній основі або імпорт продуктів з інших джерел щодня.

Кожен, хто має кращі практики з цим чи іншим способом вирішення, будь ласка, поділіться ними, які будуть дуже вдячні.

Важливо зрозуміти, які індекси повільні і чому

Складність каталогу та архітектура магазину в кінцевому підсумку визначатимуть тривалість повторного індексу - у поєднанні з базовою інфраструктурою.

• Якщо у вас є 50 000 продуктів і 10 переглядів магазинів, ви можете гарантувати, що catalog_url_rewriteна обробку знадобиться кілька мільйонів рядків .

• Якщо у вас є 100 продуктів, але 5000 атрибутів, ви можете гарантувати catalog_attributesабо catalog_product_flatтаблиця буде вік , щоб відновити або впасти плазом на його обличчі

• Якщо у вас 1000 продуктів, але 500 атрибутів для пошуку, вам catalog_fulltext_searchзнову знадобиться вік

Вирішення кожної проблеми, з якою ви стикаєтеся, не на 1 розмір, а на те, щоб правильно сконструювати ваш магазин; наявність належної інфраструктури для її підтримки та використання частоти / стратегії переіндексації, яка підтримує доступність контенту та ефективність.

• Додавання кешування переднього типу взагалі не допоможе
• Викидання більшої кількості обладнання в ситуації може
• Допомога щодо розміру / складності каталогу допоможе
• Використання сторонніх інструментів індексації допоможе
• Екстерналізація певних індексів (наприклад, пошук> SOLR) допоможе

Існує також випадок оцінки того, чи потрібні певні індекси навіть. Використання плоских товарів / категорій не завжди робить всі магазини швидшими; ми бачили, що це робить магазини набагато повільніше. Тож ви можете виявити, що після тестування продуктивності до / після - вони навіть не враховують.

тл; д-р

Розчини срібної кулі немає. Я пропоную кілька вирішень, Sonassi_Fastsearchindexале це спеціально для пошуку в каталозі.

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

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

Питання індексації - зокрема каталог_url_rewrites - добре відомі та задокументовані у громаді. Magento вирішив це у версії Enterprise, оскільки саме такі клієнти зазнають найбільшого впливу. Багато клієнтів EE мають 10k + продуктів та кілька переглядів магазинів, веб-сайтів тощо.

Однак якщо у вас великий каталог і велика кількість атрибутів, ви можете опинитися в положенні, що індексація займе тривалий період часу - зокрема каталог_url_rewrite, product_flat - у цьому випадку моя пропозиція не фіксувати час виконання індексу довжина, а не для завантаження деякої обробки, щоб поле могло проводити індексацію циклів процесора, а не подавати вміст .

Питання, які слід задати собі:

• Чи я втрачаю бізнес через проблеми індексації?
• Чи втрачаю я продуктивність через проблеми індексації?
• Чи загрожую я втраті конверсій чи страждає мій показник конверсії?
• Чи ризикують мої клієнти придбати товари на складі, що є прямим результатом того, що індекси не синхронізуються (інвентар та ін.)
• Чи є правилами мого ціноутворення в каталозі частиною мого основного бізнесу та
• Чи мій показник конверсії на сайті за результатами пошуку вище норми (8-10%), таким чином, виграю кращу індексацію?

У цьому конкретному питанні немає вирішення срібних куль - як постачальник рішень, ви повинні допомогти своєму клієнту прийняти рішення, яке найкраще покращить продажі та бізнес, зберігаючи низькі накладні витрати.

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

Завантажте пошук у каталозі та багатошаровий навичок на Solr.

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

І якщо ви вирішите перейти з лаком - пам’ятайте:

У більшості важких веб-магазинів Magento в основному було так важко змусити роботу Magento Backkend Index Index. У мене часто виникало це питання. Запуск сценарію оболонки весь час розробником часто буває неспокійним. Зазвичай я вирішую цю проблему постійно так.

Я створюю нову копію shell / indexer.php> shell / myindexer.php

Налаштуйте оболонку / 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 я зміг скоротити час перевстановлення каталога_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. У цій версії індексатори значно покращилися.