Настройка сервера и производительность магазина. Почему не бывает волшебной настройки сервера.

Регулярно я вижу это сообщение. "настройте мне сервер, чтобы у меня работали 100 000 товаров на моем неплохом впс сервере".

Ну вроде там как бы логично. Хостер заявляет про классные сервера, а фрилансер, который сделал магазин - говорит иди к йоде - он тебе сделает настройку сервера и все полетит задышит.

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

Потому что максимум, что мы можем сделать на сервере, настроить затюнить опкеш, махнуть файловый кеш на хранилище в памяти (не всегда актуально на быстрых впс с NVME), сделать несколько тюнячек для mysql сервера и воткнуть nginx + php-fpm вместо тупорылого апача (не берем во внимание кастомные решения в виде полного нативного кеширования html средствами Nginx, но это опять же кеширование).

Там где у вас есть пару сотен онлайна одновременно, там вот есть настройки сервера. Лимиты, максимальное количество коннектов, воркеры nginx, процесс php-fpm. Но в 99% случаев на магазинах где нет и тысячи живых хостов в день - это высшая ненужная кибениматика.

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

Друзья, настройка сервера - это последняя линия обороны. Важная - но не первичная!

Если вы хотите большой магазин на много товаров, вы должны закрыть вопросы "холодной" генерации страниц.  А не закешированных версий, почему, потому что это важно для поисковых систем. Яндекс и Гугл - они ходят туда куда хотят, и если у вас страницы не было в кеше, а генерация у нее 5-8 секунд, они больше к вам не придут и страницу выбросят из индекса. Поэтому, если хотите, чтобы ваш большой магазин проиндексировался - вам надо иметь время ответа до секунды на всех страницах, чтобы поисковики не ходили мимо.

Как это сделать? В интернете есть масса советов, типа... используйте индексы, используйте кеширование. Но! У нас в опенкарте, нормализованная структура данных, и не нормализованная структура значений для атрибутов. Первая ситуация ограничивает использование индексов при выборке-подсчете товаров  в категориях, вторая при выборке подсчете значений фильтров.

Если бы у нас был один язык, один магазин и вместо текстовых значений атрибутов была бы нормализованная индексированная таблица с набором id->value(значение атрибута), просто банальным построением индексов в базе и минимальными правками запросов мы бы получали нулевую нагрузку на выборку данных товаров из категорий. Все эти getProducts getTotalProducts - выполнялись за тысячные секунды. Равно как и подсчет атрибутов. 

Но нет! У нас опенкарт!.

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

Зачастую, тюнинг магазина - это разгребание авгиевых конюшен от модулепейсайтелей, а не тюнинг в привычном понимании.

Что же делать? 
Ну нет однозначного ответа и решения. Никогда нет.

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

Реально - это единственное решение на всем форуме, от автора, который понимает чем нормализованные данные отличаются от денормализованных, и где и какие структуры надо использовать. Несмотря на то что у меня есть масса вопросов к другим аспектам работы его решения, в целом с точки зрения производительности из коробки - это №1!

Если вы думаете что MegaFilterPro, который индексирует якобы ваш каталог, и чего-то там долго думает дает производительность - не верьте. Сам по себе Mega фильтр - шикарная штука, но вот эта их индексация мертвому припарка, так как там идет попытка использваняи фулл-текст индексов, а они немного про другое, чем тот процесс, который пытаются решить с их помощью авторы! Лучше бы сегментацию по категориями сделали  в выборках всех атрибутов на категорию!

Если у вас нет данных и вы торгуете к примеру автозапчястями и вам нужен быстрый старт с поиском по коду детали - вы можете посмотрреть в сторону бесплатного модуля Sphinx:

https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=18266

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

Но как же так получается у нас запускать магазины на 2-3 миллиона товаров и что вот у них все хорошо.

Ну по секрету скажу - что случайно)

Так получилось, что первый человек с таким запросом - был мой хороший друг, и мы с ним начали работать в формате - ну а давай попробуем, попробовали так и сяк и эдак, стандартными методами не вышло. Те решения, которые работали на 20-30-100к товаров на миллион уже не работали, а тем более на миллион товаров в одной категории.

Нам пришлось очень сильно и глубоко раскурить все загадки сфинкса, который позволяет на сегодня держать 300-500 тысяч генераций страниц  в день, которые создают боты, при этом - и это важно, имея 5-кратный запас мошности и это на магазине в 2.5 миллиона товаров. 

Но после того как мы решили вопросы производительности фронта (категории, товары, фильтр, главная страница), возникли и иные вопросы, а именно: обновление цен, добавление новых товаров, манипуляции с заказами в админке, поиск, и так далее. Да и это получилось решить. При чем, решить таким образом, чтобы не уходить от стандартной структуры таблиц Opencart.

И еще раз подчеркну... Все решения - это не настройка сервера. Это создание комплекса. Да у нас быстрый и хорошо настроенный сервер, но у нас еще более быстрый и грамотный код. У нас перестроенные запросы в админских моделях. Нам пришлось вскрывать csv import от ионкуба, для того чтобы оптимизировать глупые запросы автора. И да мы получили результат.

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

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

А те кто думают по другому - могу дать тестовую базу на пару лямов товаров - покажите мне как вы ее запустите на генерацию полмиллиона страниц в день!
Ну и как всегда пари платное - 100 000 рублей!