Jump to content
  • entries
    38
  • comments
    321
  • views
    8,099

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

Регулярно я вижу это сообщение. "настройте мне сервер, чтобы у меня работали 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 рублей!

  • +1 7


6 Comments


Recommended Comments

Без всякой иронии, вопрос чисто из любопытства: почему с этой шляпой ничего не сделали? Речь о том, что чем глубже страница, тем медленнее отрабатывает запрос выборки товаров. Оффсетная пагинация на таком количестве товаров - это же откровенно гм... не лучшее решение =\ Впрочем, для опенкарта еще никто этот вопрос не решил, по-моему. Во всяком случае в паблике не припомню упоминаний об этом.

 

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

 

[censored]

 

 

Share this comment


Link to comment

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

 

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

 

Все решается, просто всех все устраивает!

 

В целом спасибо за репорт - на момент когда там было 500к ответ и на последней странице был вменяемый.

Share this comment


Link to comment

 

On 7/14/2020 at 12:27 AM, Yoda said:

Но если вы считаете что 66 000 страниц пагинации это там не оптимизировано. Ну простите.

 

On 7/13/2020 at 7:14 PM, 100napb said:

Оффсетная пагинация на таком количестве товаров - это же откровенно гм... не лучшее решение =\

 

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

Spoiler

читать в этом направлении

 

image.png.6ed4ae36606c52278981bdf029535f4d.png

 

image.png.e63248dcff731f676fcfff7b8fd85737.png

 

Share this comment


Link to comment

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

 

Share this comment


Link to comment
12 часов назад, 100napb сказал:

У него есть свои особенности, но скорость...

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

Есть более простая альтернатива

  • +1 2

Share this comment


Link to comment
11 hours ago, SooR said:

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

рад, что Вы что присоединились к обсуждению, спасибо.

поскольку варианты сортировок строго определены списком, который предлагается пользователю во фронте, то кажется логичным использовать виртуальные(хранимые) или предварительно сгенерированные столбцы со значениям в бд. По одной колонке вместо какого-нибудь "order by sort_order, lcase(name)" и содержащие, например, порядковый номер записи согласно того или иного варианта сортировки.

Составные индексы в mysql вкупе с этим так же более-менее успешно работают. Более-менее ввиду того, что составные индексы по-умолчанию сортируются как asc и они не эффективны при выполнении запроса, в котором для второго или последующего поля используется сортировка desc.

 

12 hours ago, SooR said:

Есть более простая альтернатива

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

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.