Оптимизация движка под 120 000 товаров

[pashast]

Пролистав пару тем на форуме, где обсуждалась возможность использовать opencart для большого количества товара, захотелось попробовать все самому. :-)

Тем более подвернулся халявный VPS.

Вот что вышло: http://demo5.demo.pl.ua/

Что делал:

- софт на VPS: NGINX без apache, php-fpm, APC

- установил opencart 1.5.5.1

- сразу отключил счетчик товаров в админке, на 10 000 товарах помогло, далее стало бесполезно.

- от стандартного модуля категорий пришлось отказатся, страницы генерились по 2-3 минуты

- использовал этот модуль от toporchilo http://opencartforum...B8%D0%BE%D0%BD/

- категории в верхнем меню пришлось отрубить по той же причине, можно использовать http://www.opencart....tension_id=6074

- оптимизировал таблицы в mysql

Страницы стали открываться быстро, кроме категорий верхнего уровня, независимо от того есть ли в верхней категории товары или нет.

Пришлось закоментировать запрос в контролере категории.

Верхние категории открываются быстро, но стоит только добавть товар в 2 категории , все - хана, тормоза опять начинаются.

  $this->data['categories'] = array();

  $results = $this->model_catalog_category->getCategories($category_id);

  foreach ($results as $result) {
$data = array(
 'filter_category_id'  => $result['category_id'],
 'filter_sub_category' => true
);

/*$product_total = $this->model_catalog_product->getTotalProducts($data); */  

$this->data['categories'][] = array(
 'name'  => $result['name'] . ($this->config->get('config_product_count') ? ' (' . $product_total . ')' : ''),
 'href'  => $this->url->link('product/category', 'path=' . $this->request->get['path'] . '_' . $result['category_id'] . $url)
);
  }

Итог:

Мой способ подойдет тем, у кого строгая иерархия категорий и товаров.

И в каждой категории последнего уровня не буде лежать очень много товаров.

Поиск все-равно тормозит

Еще наблюденя:

Построение индексов таблиц ничего в плане производительности не дало.

Платный модуль кэширования с opencart.com сделал только хуже. :-)

Просьба потестить: http://demo5.demo.pl.ua/

[sv2109]

Спасибо за отчет

Не хватает параметров вашего халявного VPS и информации как именно вы оптимизировали таблицы в бд.

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

Поиск я немного оптимизировал в своем модуле поиска. Но понятно что для большого к-ва товаров идеально использовать отдельный поисковый движок а не искать все средствами mysql через джойн нескольких таблиц с сотнями тысяч записей.. причем если использовать "LIKE '%" то там даже индексы не будут работать.

Если под платным модулем кеширования емелся ввиду вот этот модуль то этот модуль это развод на деньги. Толку с него почти никакого.

[pashast]

Параметры VPS: 12 ядер; 1ГБ оперативы, загрузить ее по полной так и не получилось, максимум 290МБ.

Оптимизация - стандартная, средствами phpmyadmin (пункт: оптимизировать таблицы)

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

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

[EVMedvedev]

Кэширование при такой номенклатуре точно не поможет. Количество файлов в кэше будет гарантировано в разы больше чем номенклатура и тогда на уровне работы операционки с файлами начнутся проблемы. С кэшами в оперативке тоже пробовать бесполезно. Там проблемы будут возникать еще быстрее, причем там могут сбоя проявляться так, что не сразу обнаружишь. А демо базу как делали? Можете архив выложить для общего пользования?

На счет VPS тут желательно бы прикинуть, сколько будет стоить в месяц аренда такого чуда :-) (20, 30, 50 тыс руб). Там ведь и дисковая система наверное такая что ... RAID 5 с кэшом на весь объем диска и 4-5 кратным распараллеливанием чтения записи.

В общем, можно ли тут говорить об оптимизации?

[sv2109]

На счет VPS тут желательно бы прикинуть, сколько будет стоить в месяц аренда такого чуда :-) (20, 30, 50 тыс руб).

Вот например цены http://unihost.com/vps/

[pashast]

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

[pashast]

На счет VPS тут желательно бы прикинуть, сколько будет стоить в месяц аренда такого чуда :-) (20, 30, 50 тыс руб). Там ведь и дисковая система

350 - 600 рублей в месяц, дешевле некоторых хостингов ))

[Гість brk]

350 - 600 рублей в месяц, дешевле некоторых хостингов ))

тссс! :ph34r:

[EVMedvedev]

350 - 600 рублей в месяц, дешевле некоторых хостингов ))

12-ти ядерный?! Во первых я подумал что вы просто ошиблись, поскольку для VPS ядер не существует. Ядра можно считать у дедика (у арендованной физической железки). VPS это виртуальный сервер. Теперь получается что вы не ошиблись, а просто не понимаете о чем идет речь. За 350-600 рублей в месяц действительно можно получить только VPS.

sv2109, с расценками на хостинг и на дедики я знаком :-). И вопрос по цене у меня возник в связи с тем, что аренда 4-х ядерного сервера обходится в среднем во столько http://www.jino.ru/s...es/servers.html, а товарищ заявляет о 12-ти ядрах! И при этом утверждается что это стоит 350 рублей. Да не смешите мои подметки :-).

[EVMedvedev]

А вообще же мое представление о способности движка работать с номенклатурой в 100 и более тысяч товаров основывается на этом, а сама постановка вопроса кажется не совсем корректной.

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

Вообще говоря, кэшируются либо запросе к БД, либо уже фрагменты HTML кода (ну или целые страницы). Что вы понимаете под кэшированием стандартных модулей?

[afwollis]

Оптимизация - стандартная, средствами phpmyadmin (пункт: оптимизировать таблицы)

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

[pashast]

12-ти ядерный?! Во первых я подумал что вы просто ошиблись, поскольку для VPS ядер не существует. Ядра можно считать у дедика (у арендованной физической железки).

Виртуальные ядра, как бы, общепринятый показатель производительности VPS.

Даже в дедике на core-i7, половина ядер -виртуальные, так что это все условности и маркетинговые уловки.

И да, нормальный впс может быть производительней дедика за такую же цену.

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

Помогает же, хоть и баловство. :-)

[Гість brk]

12-ти ядерный?! Во первых я подумал что вы просто ошиблись, поскольку для VPS ядер не существует. Ядра можно считать у дедика (у арендованной физической железки). VPS это виртуальный сервер. Теперь получается что вы не ошиблись, а просто не понимаете о чем идет речь. За 350-600 рублей в месяц действительно можно получить только VPS.

sv2109, с расценками на хостинг и на дедики я знаком :-). И вопрос по цене у меня возник в связи с тем, что аренда 4-х ядерного сервера обходится в среднем во столько http://www.jino.ru/s...es/servers.html, а товарищ заявляет о 12-ти ядрах! И при этом утверждается что это стоит 350 рублей. Да не смешите мои подметки :-).

:) до 14 ядер и это тоже не предел

Я давно говорил что Вы теоретик.

этот скрин другого серванта и он не относится к топику Паши

[EVMedvedev]

:) до 14 ядер и это тоже не предел

Я давно говорил что Вы теоретик.

этот скрин другого серванта и он не относится к топику Паши

Да, теоретически у вас красивые картинки. Виртуально нарисовать можно все что угодно. Если каждое виртуальное ядро считать эквивалентом 386-го, то и 140 можно нарисовать, и на гигагенцовом целероне, как маркетинговую уловку.

[tommy982]

а как быть с нагрузкой? тестировали? что если завтра на сайт придет 10 000 человек. как себя тогда будет вести магазин? посещаемость на мой взгляд это очень важный показатель.

[Yoda]

Какой ты кешер юзал ?

Тот на который я наводку дал ?

[pashast]

а как быть с нагрузкой? тестировали? что если завтра на сайт придет 10 000 человек. как себя тогда будет вести магазин? посещаемость на мой взгляд это очень важный показатель.

Посоветуете, где можно бесплатно взять хотя-бы 5 000 посетителей - потестирую.

Какой ты кешер юзал ?

Тот на который я наводку дал ?

не помню, что ты мне там советовал, если честно )

[freelancer]

ab -c 100 -n 5000 http://site.com/

[pashast]

ab -c 100 -n 5000 http://site.com/

Да это только морду проверит, выдержит.

Если-бы по страницам какой-то сервис полазил.

[Yoda]

Спасибо Паше, за дамп его монстр базы...

Веду тестирование у себя на сервантусе и буду апдейтить результаты экспериментов с замерами.

Может получится шпаргалка по оптимизации движка.

Итак.. Имеем сервант, стоящий практически в ногах, на котором хостится штук 5 проектов по 500 хостов в день.. Сейчас ночь, нагрузки на нем практически нет (параметров сервантуса не знаю, завтра скажу)

чистый свежеустановленный оф опенкарт 1,5,4,1 И подключенную базу

Все завелось. Работает... морда загрузилась сразу без проблем....

В верхнее меню вывел всего одну категорию, чтобы было куда клацнуть, чтобы протестить.

После публикации модуля категорий в категории. Я запарился ждать генерацию страницы и полез ковырятся. Вобщем из коробки не завелось.

Впилил в индекс файл замер времени...

1. Отключил подсчет количества товаров в катеории в контроллере модуля...

Страница сгенерирована за 52.657795 секунд

Что же делать дальше,... Попробую выкинуть мультиязычность и мультимагазин.. Посмотрим что даст.

Выпил мультиязычности решил отложить по причине мультиязычного описания товаров. Закончу гонять первичные тесты, прибью все описания для второго языка и посмотрим.

2. Отключил подсчет количества для блока на странице категорий. Прирост не ощутимый - всего секунда.. что можно списать на погрешность.

.Страница сгенерирована за 51.879392 секунд

3. Недоотключил я подсчет общего количества для категорий как оказалось в модуле категорий... Доправил. Получил уже вполне вменяемое значение. (но здесь был выпилен подсчет общего количества товаров для пагинации). Закешировал в модели getCategories.

Страница сгенерирована за 1.263737 секунд

4. Страница категории с 20 товарами и включенным модулем категорий... при первом заходе с 20 товарами на странице

Страница сгенерирована за 2.571835 секунд

Повторный заход

Страница сгенерирована за 0.086185 секунд

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

5. Посмотел модуль ТОПОРЧИЛО.. Имеет право на жизнь, как замена модуля категорий. Но по тому же принципу верхнее меню не реализуешь, (а я сторонник горизонтальной навигации) будет в минус юзаюбильности, пока оно будет подгружаться..

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

6. Совершенно непонятно как поведет себя это монстро с сеоурлами. Так как база под оф версию, в ней нет майн категорий, соответсвенно кешированное сео про не прикрутишь. Хотя я думаю что выборка из одной таблицы в три столбца и в 120 000 записей, пусть даже 50 полей, не сильно подгрузит производительность. А с кешированным допилом фрилансера, будет летать.

7. Валяется у меня где то модель продукта от Yesvik, оптимизированная до безумия, которую он пытался протащить в сборку, но она по моему под 0.2.0, поэтому перепиливать ее под новую версию и ставить на ней опыты нет желания и времени, хотя подозреваю, что толк был бы.

8. Теперь перейдем к тяжелой артиллерии.. Прикрутим кешер. Кешер у меня использует VQMOD, ща заодно посмотрим как меняется производительность с кешированным скриптом вкумода, хотя при том что вкумодов особо у меня нету вряд ли что то увидим. Но при использовании VQMOD на продакшн версии, все такие надо поменять скрипт самой библиотеки на модификацию с кешированием.

Вот такие вот результаты имеем для главной страницы:

Without Caching: 0.072319984436035 With Caching: 0.000507831573486339.

Для страницы категории без товаров с включенным модулем категорий вот такие:

1.3437700271606 With Caching: 0.0025069713592529И

Для страницы категории с товарами с включенным модулем категорий вот такие:

0.1599178314209 With Caching: 0.0027790069580078

Страница товара:

0.26726293563843 With Caching: 0.00058984756469727

Прошу заметить, это 120 тысяч товаров!!!!

9. Возникает логичный вопрос, как поведет себя этот колхоз, когда нагенерит кеша, а вот сейчас и проверим, запущу минут на 10 XENU, пусть походит, а там и посмотрим.

Пока работает, 20 одновременных потоков, ничего не отваливается, нагенерило уже тыщи 1,5 страниц, При это все остальные проекты хостящиеся на сервере, летают.

Я думаю пора останавливать.

Получаем на некешированном сайте производительность в 2000 страниц за 10 минут в 20 подключений.

При средней глубине просмотра в 5 страниц на посетителя... Получаем ресурс в 40 посетителей в минуту, и среднестатистический дневной ресурс в 57 к хостов в день.

При 100 одновременных тредах, потихонечку кое какие страницы начинают отваливаться....

Сейчас посмотрим что будет, если запустить процесс опять, у нас же есть кеш страниц....!

те же 2к страниц отдались уже за 2 минуты 50 секунд. Кешер дал прирост более чем в три раза...

Ну что ж. можно подводить итоги...

Однозначно есть вариант научить опенкарт работать с большой базой товаров.

1. Без железяки не обойдешься - факт. ни на дешевом VPS, а уж тем более на каких нить базовых хостинг пакетах такое поднять не удастся.

2. Кеширование результатов запросов на уровне моделей, отключение подсчета количества товаров - уже дают значительный эффект.

3. Для проектов с 1 языком и с 1 магазином, выжигаем напалмом всю мультиязычность и мультимагазинность - тоже получим профит однозначно (замахался я по 20 раз перезагружать одну и ту же страницу полночи). Может тест с обрезанием мультиязычности сделаю позже.

Но все это все равно не приводит к вменяемым результатам, потому что все остальные процессы генерации страниц, все равно пожирают моск остаются ресурсоемкими.

4. Все редко изменяемые куски кода, типа меню или например, раздела с информацией в футере, которые можно запихнуть по живому в тплку, надо туда впихнуть и убрать, соответственно из их контроллеров.

Контроллер футра в идеале надо оставить пустым, а в хедере оставить формирование метатегов и заголовка.

5. Все языковые переменные убираем из контроллеров и вживляем в тплки.

7. Использовали VQMOD? Закончили проект ? в идеале перелейте и переименуйте из его кеша все файлы на место оригинальных. Лень - поменяйте библиотеку на кешированный вариант.

8. Про автогенератор сайтмапа, или фид для яндексмаркета, придется забыть, либо же применить к ним суровый напильник. В коробочном варианте - они уложат вам любой сервант, на таком количестве товаров.

9. Но все же для полного HighLoada выход один, - кешировать страницу на уровне HTML. Для чего на офсайте хватает модулей. Которые вместо динамического контента отдают данные из кеша, пока посетитель не зарегался, или не положил чего нить в корзину. Чтобы не нагиналась файловая система, это кеширование нужно оптимизировать, раскладывая кеш страниц с товарами и подкатегориями в

соответсвующие родительские папки. Если потребуется реализация какого нить динамического контента, - AJAX в помощь, те же последние просмотренные можно легко реализовать через кукисы.

По такому принципу работает Lenta.ru. У них практически все страницы - статичные, а при добавлении новости - происходит автообновление кешированных данных.

В итоге получаем достаточно живенькую зверюжку, которая в состоянии обработать беспроблемно тыщ 10 хостов в день с 100к+ товарами, при средней глубине просмотра 10-15 страниц.

А ежели надабна будет поднять увеличится под количество посетителей, то потанцевав с бубном можно собрать интересное решение из, кеш-сервера и контент-сервера.

На проекте с 10к+ посетителей в день, даже если мы будем пирожки по 2 рубля продавать, затраты на такие изыски окажутся просто незаметными.

И базе свой сервантик. И картинкам отдельный хост. Хотя это уже я про научную фантастику...

UPD. Ссылку на подопытного не дам, так как там несколько продакшн-проектов, и не хотелось бы чтобы они завтра умерли, изза того что например BRK начнет тесты на пиковые нагрузки))), но все цифры, может подтвердить Pashast, которому еще раз спасибо за дамп.

[Гість brk]

Да это только морду проверит, выдержит.

Если-бы по страницам какой-то сервис полазил.

UPD - оптимальный

[pashast]

UPD. Ссылку на подопытного не дам, так как там несколько продакшн-проектов, и не хотелось бы чтобы они завтра умерли, изза того что например BRK начнет тесты на пиковые нагрузки))), но все цифры, может подтвердить Pashast, которому еще раз спасибо за дамп.

Подверждаю, все работает быстро со стандартными модулями категории.

Спасибо за развернутый ответ.

С BRK я все согласовал ))), спасибо ему за тесты, с их помощью удалось подкрутить настройки сервера.

[pashast]

68000+ товаров. Самый дешевый невыделенный хостинг. Движок 1.5.5.1, сделана оптимизация медленных SQL-запросов. Дополнительное кэширование не используется.

http://toporchillo.jino.ru/oc1551opt/ - с небольшой оптимизацией

http://toporchillo.jino.ru/oc1551/ - OpenCart 1.5.5.1 из Git-репозитория.

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

Резюме: OpenCart для большого количества товаров подходит

Есть товары в двух категориях?

Или у каждого товара только одна категория?

[Yoda]

Каких именно ?

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

[Yoda]

Я когда ковырял базу, выводил же всего один пункт в меню, и он существенно не влиял на производительность. Только что столкнулся с черепашьим хостингом, пришлось закешировать меню а уровне контроллера...

Полет пошел на главной сразу нормальный....

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

$data=array('menu');

 $menu = $this->cache->get('menu.' . (int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id'));

 $this->data['categories']= $menu;

 if (!$menu) {

 $categories = $this->model_catalog_category->getCategories(0);

 foreach ($categories as $category) {
  if ($category['top']) {
$children_data = array();

$children = $this->model_catalog_category->getCategories($category['category_id']);

foreach ($children as $child) {
 $data = array(
  'filter_category_id'  => $child['category_id'],
  'filter_sub_category' => true
 );

 if ($this->config->get('config_product_count')) {
  //$product_total = $this->model_catalog_product->getTotalProducts($data);
  $product_total='';
  $child['name'] .= ' (' . $product_total . ')';
 }

 $children_data[] = array(
  'name'  => $child['name'],
  'href'  => $this->url->link('product/category', 'path=' . $category['category_id'] . '_' . $child['category_id'])
 );	
}

// Level 1
$this->data['categories'][] = array(
 'name'	 => $category['name'],
 'children' => $children_data,
 'column'   => $category['column'] ? $category['column'] : 1,
 'href'	 => $this->url->link('product/category', 'path=' . $category['category_id']),
 'active'   => in_array($category['category_id'], $parts)
);
  }
 }

 $menu = $this->data['categories'];

 $this->cache->set('menu.' . (int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') , $menu);


 }

Единственное, выпилил из кеширования группы пользователей, но если надо, их добавить - не проблема.