Помогите ускорить магазин и MegaFilter Pro

[Yoda]

Подскажите пожалуйста, есть  магазин, 470 000 товаров в одной категории.

На выделенном сервере Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz (8 cores) 16ГБ .
У товара 20 атрибутов, - суммарно выходит порядка 10М значений атрибутов (которые надо считать на-лету). 

Весь каталог работает через промежуточную прокладку в виде Sphinx-демона. 

Файлы индекса сфинкса лежат в RAM диске в оперативной памяти.
(выборка товаров в категории, подсчет количества значений атрибутов в фильтре, все все все, что можно крутится на сфинксе)

После партицирования индекса на 8 частей и перенастройки конфигурации демона для использования всех 8 ядер процессора, удалось снизить время реакции фильтра с 5 до 1-1.2сек.
Среднее время генерации страниц в районе 600мс. При переходе на php7.2 - будет порядка 400-450.
Владелец магазина возмущается, ему не достаточно скорости.

Подскажите, что можно сделать для ускорения магазина?

[PoliteX]

сколько стоит чтобы так же тормозило ?

[Yoda]

6 минут назад, PoliteX сказал:

сколько стоит чтобы так же тормозило ?

 

Бесценно. Леонардо, я думаю тоже цену на Мона-Лизу сложить не мог.

Но реально тупит же, а у меня уже фантазия закончилась что можно еще сделать.

[zlob]

отключить подсчет товаров в категории 

 

[Yoda]

Очень смешно!! Ага. 
Я только что сам перечитал, что написал, звучит как жесткий троллинг, однозначно. 
Но это не троллинг. 

С момента написания поста, мне пришли в голову еще кое-какие мысли, которые мы когда-то обсуждали с маэстро @SooR, можно ведь подсчет значений атрибутов делать не по текстовому полю, а по crc32 хешу. И теоретически это может дать прирост на какие-то 20-30%. 

Также в целом можно отказаться от JSON-атрибутов в индексе и преобразовать все в MVA.
Но мало ли, может кто сталкивался с подобным и есть еще какие умные мысли, как ускорить подсчет по 10 миллионам значений атрибутов.

[n3bo]

а что за категории такие, по 470к? (если не секрет)

 

Цитата

Владелец магазина возмущается, ему не достаточно скорости.

Скорости работы фильтра или сайта?

Змінено 28 грудня 2018 користувачем n3bo

[SooR]

@Yoda , а лучше все на сфинкс перебросить.

А, так уже на сфинксе.

Тогда сделать под фильтр слейв базку.

UPD. Или поэкспериментировать с выгрузкой всех индексов фильтров в память, например, в tmpfs

Ёапта, и это сделали

[Yoda]

9 минут назад, n3bo сказал:

а что за категории такие, по 470к? (если не секрет)

 

Скорости работы фильтра или сайта?

 

Про категории - владелец сам расскажет, если захочет. 
Скорость работы как сайта так и фильтра. 

Так как в магазин скорее всего приедет еще столько же товаров,  владелец опасается подобных писем счастья:

 

 

[SooR]

17 минут назад, n3bo сказал:

а что за категории такие, по 470к? (если не секрет)

 

Да даже шины/диски/обои.. много примеров

[Yoda]

4 минуты назад, SooR сказал:

@Yoda , а лучше все на сфинкс перебросить.

А, так уже на сфинксе.

Тогда сделать под фильтр слейв базку

Умрет mysql от таких вот запросов даже на на паре миллионов записей.

 SELECT COUNT(txt) as qty, attr_data.text as txt FROM main WHERE  category_id = 20 GROUP BY txt  LIMIT 100;

Так что не выход.
 

[SooR]

Может добавить партиций?

UPD. Sphinx третий?

[SooR]

3 часа назад, Yoda сказал:

Владелец магазина возмущается, ему не достаточно скорости.

Пускай аргументирует чем не устраивают <= 500ms, нужно спорить с его возмущениями, т.к. результат адекватный.

[Yoda]

12 минут назад, SooR сказал:

Может добавить партиций?

UPD. Sphinx третий?

Третий. Партиций 8 штук добавлено по количеству ядер.

 Без партиций вот так:

 

MySQL [(none)]> SELECT COUNT(txt).............................................................;
+-------+-------------------------------------+
| qty   | txt                                 |
+-------+-------------------------------------+
| 21440 | txt1         |
| 21440 | txt2         |
| 21440 | txt3        |
| 21440 | txt3        |
| 21440 | txt4                |
| 21440 | Itxt5                 |
| 21440 | txt6              |
| 21440 | txt7         |
| 18480 | txt8         |
| 18640 | txt9         |
| 18640 | txt10         |
| 18640 | txt11        |
| 18640 | txt12         |
| 18640 | txt13         |
|  7640 | txt14      |
| 27040 | txt15         |
|  7640 | txt16        |
|  7640 | txt17        |
|  7640 | txt18         |
|  7640 | txt19        |
| 27040 | txt20         |
| 27040 | txt21         |
| 35200 | txt22        |
| 35200 | txt23         |
+-------+-------------------------------------+

24 rows in set, 1 warning (0.13 sec)

 

C партициями вот так:

 

MySQL [(none)]> SELECT COUNT(txt) ..........................................................................;
+-------+-------------------------------------+
| qty   | txt                                 |
+-------+-------------------------------------+
| 21440 | txt1         |
| 21440 | txt2         |
| 21440 | txt3        |
| 21440 | txt3        |
| 21440 | txt4                |
| 21440 | Itxt5                 |
| 21440 | txt6              |
| 21440 | txt7         |
| 18480 | txt8         |
| 18640 | txt9         |
| 18640 | txt10         |
| 18640 | txt11        |
| 18640 | txt12         |
| 18640 | txt13         |
|  7640 | txt14      |
| 27040 | txt15         |
|  7640 | txt16        |
|  7640 | txt17        |
|  7640 | txt18         |
|  7640 | txt19        |
| 27040 | txt20         |
| 27040 | txt21         |
| 35200 | txt22        |
| 35200 | txt23         |
+-------+-------------------------------------+
24 rows in set, 1 warning (0.03 sec)

 

Также при использовании партиций возникла проблема с работой QSuggest запросов - но она решилась, формированием дополнительного индекса для подсказок.

 

[Yoda]

4 минуты назад, SooR сказал:

Пускай аргументирует чем не устраивают <= 500ms, нужно спорить с его возмущениями, т.к. результат адекватный.

500 мс - это с прогретым родным кешем мегафильтра.

При жмакании на любой параметр фильтра. Получается от 500 мс до 1.2 сек время ответа ajax запроса. 

 

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

[SooR]

У меня несколько вариантов:

 

1. 

3 часа назад, Yoda сказал:

У товара 20 атрибутов

горизонтальная модель с динамическими колонками

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

3. свой фильтр

[SooR]

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

[SooR]

3 часа назад, Yoda сказал:

При переходе на php7.2 - будет порядка 400-450.

А при переходе на 7.3 350-400

[Yoda]

1 минуту назад, SooR сказал:

У меня несколько вариантов:

 

1. 

горизонтальная модель с динамическими колонками

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

3. свой фильтр

1 - не совсем понял

2 - серв тут едва ли загружен на 20% Смысла куда-то уносить фронт и базу никакого.

3 - от Mega фильтра у нас осталась админка и механизм отображения данных. Вся модель выборки собственная. Т.е. мы просто подменили все методы Mega. 

 

Но опять же я выше писал, что скорее всего приведение значений атрибутов к виду crc32(txt) и отказ от использования json модели в пользу плоского multi-value атрибута с набором bigint значений, по идее должен дать некий прирост. Вопрос только в том какой. Если это будет 50% от существующих цифр - видимо стоит и заморочиться.

[Yoda]

4 минуты назад, SooR сказал:

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

 

Вот это здравая мысль.

2 минуты назад, SooR сказал:

А при переходе на 7.3 350-400

Ioncube ...

[SooR]

@Yoda , делай crc32, как самый быстрый способ проверить.

 

1 минуту назад, Yoda сказал:

1 - не совсем понял

 

Не

 

product_id	filter_id	filter_value_id
1	1	1
1	1	2
1	2	3
1	2	4
1	3	5

 

а

 

product_id	filter_id_1	filter_id_2	filter_id_3
1	[1,2]	[3,4]	[5]

 

условно.

 

Если нет мультиатрибутов, то еще быстрее без json

 

[Yoda]

Только что, SooR сказал:

@Yoda , делай crc32, как самый быстрый способ проверить.

 

 

Не

 

product_id	filter_id	filter_value_id
1	1	1
1	1	2
1	2	3
1	2	4
1	3	5

 

а

 

product_id	filter_id_1	filter_id_2	filter_id_3
1	[1,2]	[3,4]	[5]

 

условно.

 

Если нет мультиатрибутов, то еще быстрее без json

 

 

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

 

Так что уже после НГ  заморочусь с crc32, о результатах доложу. Ну и надо посмотреть какое количество файлов мега укладывает своим кешем на одну стрницу и дальше понимать имеет ли смысл, или нет прогревать верхние значения. Можетбыть оно то и надо. Но если получим на выходе 200 * 200 файлов. То лучше уже без кеша. Либо опять садиться вскрывать мегу и перевешивать ее кеш в Redis.

 

[SooR]

Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один:

attribute_id && crc32(text) => [какой-то один id]

 

[Yoda]

29 минут назад, SooR сказал:

Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один:

attribute_id && crc32(text) => [какой-то один id]

 

Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать.

[Guava]

если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты  из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице.

 

Наверное наивный совет да?

 

[Yoda]

11 минут назад, Guava сказал:

если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты  из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице.

 

Наверное наивный совет да?

 

 В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет.