Тестируем IMDBOptimizer для 2000 и 5500 товаров (индексы)

Когда дело заходит об оптимизации или же корректировке базы данных OpenCart, то многих одолевают вполне логичные сомнения. «Не уронит ли модуль интернет-магазин?», «Будет ли какой-то толк?» и так далее. Поэтому в рамках данной статьи, я расскажу вам о том, как я проводил тестирование для 2000 и 5500 товаров (кстати, шаги очень простые и их может повторить каждый) и каких результатов удалось добиться.

Чтобы быть более-менее объективным, при тестировании IMDBOptimizer я использовал сборку от opencart-russia.ru версии 2.1.0.2. Во-первых, именно эту сборку чаще всего используют те, кто впервые знакомятся с опенкартом (банально в поисковиках люди пишут что-то вроде «опенкарт русский» и ищут нечто похожее). Во-вторых, из основных изменений это перевод и вырезанные лишние модули, которые никому не нужны в русскоговорящем сегменте. А если и есть небольшие корректировки, то они скорее декоративного характера (для удобства и качества) и не касаются базы данных. В-третьих, набор индексов от версии к версии практически не менялся, особенно для ключевых таблиц.

Так же, хотел бы сразу отметить, что в ocStore набор индексов не отличается (со всем отсюда вытекающим).

Так же смотрите Тестирование Кэша SQL-запросов с IMDBOptimizer.

Важные моменты тестирования

Что понадобится для тестирования, если вы захотите сами проверить:

1. Возможность создать тестовый домен, хоть на WAMP по типу Denwer, OpenServer и прочие.

2. Сборка OpenCart 2.1.0.2.

3. Доступ к базе данных, так как нужно будет выполнить простые sql-запросы.

4. Браузер, который поддерживает ввод JavaScript в консоль. Я использовал, браузер Google Chrome.

5. Немного времени и терпения.

Какие допущения были сделаны во время тестирования:

1. Никаких дополнительных модулей, кроме IMDBOptimizer не устанавливалось.

2. Проверка влияния SEO URL (ЧПУ) не осуществлялась. Дело в том, что SEO PRO попросту кэширует всю таблицу с ЧПУ. Соответственно, он не использует таблицу, поэтому наличие или отсутствие индекса практически не скажется. А в случае использования стандартного ЧПУ OpenCart, модуль IMDBOptimizer лишь проверяет, что индекс никем не был удален (нужный индекс имеется в базе по умолчанию).

3. Проверялись только основные страницы, которые чаще всего просматривают покупатели интернет-магазина. А именно — главная, категория, производитель, продукт.

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

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

Процесс тестирования или как это можно повторить

Шаг 1. Установил OpenCart 2.1.0.2 стандартным образом

Шаг 2. Для одного из демо-товаров, я добавил несколько атрибутов и две различные опции по 3-4 пункта. Сделано это было для того, что опций и атрибутов практически нет в демо-товарах, а такого в реальных интернет-магазинах не бывает. Но, если вы будете сами тестировать, то советую сделать так хотя бы для нескольких товаров.

Шаг 3. Открыл вкладку «Товары» в браузере, а затем открыл консоль. В браузере гугл хром делается это следующим образом. Нажимаете «Ctrl + Shift + I», внизу появится панель. В этой панели необходимо перейти во вкладку «Console». Кстати, данная комбинация поддерживается другими браузерами (и сама консоль так же есть).

Шаг 4. Скопировал значение «token» из URL. Вот картинка

Шаг 5. Заменил в следующем скрипте «[КЛЮЧ ИЗ TOKEN]» тем, что скопировал из URL (двойные кавычки нужно оставлять). Сразу скажу, данный скрипт предназначен для того, чтобы скопировать 110 раз все имеющиеся товары в базе данных, после чего в интернет-магазине будет около 2100 товаров. Для того, чтобы сделать 5500 товаров, нужно в последней строчке вместо «110» указать «290».

var ad_url = "/admin/index.php?route=catalog/product/cop y&token=",
  ad_token = "[КЛЮЧ ИЗ TOKEN]"
  selectedData = [
    {name: 'selected[]', value: '28'},
    {name: 'selected[]', value: '29'},
    {name: 'selected[]', value: '30'},
    {name: 'selected[]', value: '31'},
    {name: 'selected[]', value: '32'},
    {name: 'selected[]', value: '33'},
    {name: 'selected[]', value: '34'},
    {name: 'selected[]', value: '35'},
    {name: 'selected[]', value: '36'},
    {name: 'selected[]', value: '40'},
    {name: 'selected[]', value: '41'},
    {name: 'selected[]', value: '42'},
    {name: 'selected[]', value: '43'},
    {name: 'selected[]', value: '44'},
    {name: 'selected[]', value: '45'},
    {name: 'selected[]', value: '46'},
    {name: 'selected[]', value: '47'},
    {name: 'selected[]', value: '48'},
    {name: 'selected[]', value: '49'}
  ]
;

function recurCopy(counter, stop)
{
  if (counter >= stop) {
    if (console && typeof(console.log)) {
      console.log('Генерация завершена!');
    }
    return;
  }
  
  if (console && typeof(console.log)) {
    console.log('Item N: ' + (counter + 1));
  }
  
  $.ajax(ad_url + ad_token, {
    type: 'post',
    data: selectedData,
    success: function (data) {
      recurCopy(counter + 1, stop);
    }
  });
  
}

function startMCopy(stop)
{
  recurCopy(0, stop);
}

// ~ 2100 товаров
startMCopy(110);

Шаг 6. Скопировал полученный скрипт. Вставил его в окно консоли и нажал ввод. После этого, можно отойти попить чайку и дождаться, когда в окне консоли появится фраза «Генерация закончена», так как данная процедура может занимать 5-20 минут (в случае 5500 может дольше).

Шаг 7. При копировании есть две проблемы. Во-первых, все полученные копии товаров отключены. Во-вторых, в скопированных товары добавляются сопутствующие (никто не будет указывать 110 товаров в сопутствующих — обычно изначально страница вообще не ссылается на другие товары). Чтобы решить эти проблемы, необходимо выполнить следующие два простых sql-запроса в базе данных тестового сайта.

-- Включаем товары
update `oc_product` set `status` = '1';
-- Очищаем связи
truncate table `oc_product_related`;

Шаг 8. Установил модуль IMDBOptimizer и ввел лицензионный ключ.

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

Полученные результаты тестирования модуля IMDBOptimizer

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

Как производилось тестирование:

1. Вначале я сразу после создания тестового сайта и наполнения его данными (2100 товаров), открыл следующие веб-страницы — главную, категорию, производителя, продукт. И замерил среднее время генерации этих страниц.

2. После этого отключил подсчет товаров и снова проверил среднее время генерации.

3. Открыл модуль IMDBOptimizer, выбрал все таблицы и нажал кнопку «Генерировать». После чего дождался окончания генерации индексов (не более одной минуты), включил подсчет товара для категорий и снова проверил среднее время генерации.

4. Снова отключил подсчет товаров и проверил среднее время генерации при наличии индексов.

5. Затем я проверил все то же самое для 5500 товаров. Для этого я повторил инструкцию и в скрипте Шага 5 заменил последнюю строчку «startMCopy(110);» на строчку «startMCopy(290);». В итоге было в базе около 5500 товаров.

В итоге, получилась следующая таблица результатов:

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

1. Если же OpenCart устанавливает начинающий, то разница в скорости оказывается весьма существенной (с 3-5 секунд до 0,6-1,2 секунд, что составляет в районе 80% для случая с 2000 товаров; с 10-12 секунда до 0,7-2,1 секунд, что составляет в районе 80-90% для случая с 5500 товаров). Все из-за того, что подсчет количества продуктов внутри категорий включен по умолчанию и не оптимизирован.

2. Если же IMDBOptimizer применяется для случая, когда подсчет отключен, то разница в скорости составляет от 6% до 15% для случая 2000 товаров, а для 5500 товаров от 10% до 30%.

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

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