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

[******]

Подскажите пожалуйси, есть  магазин, 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]

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

[******]

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

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

 

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

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

[zlob]

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

 

[******]

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

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

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

[n3bo]

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

 

Циии

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

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

Edited December 28, 2018 by n3bo

[SooR]

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

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

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

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

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

[******]

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

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

 

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

 

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

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

 

 

[SooR]

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

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

 

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

[******]

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

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

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

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

Умрет 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 часа назад, ****** сказал:

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

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

[******]

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 запросов - но она решилась, формированием дополнительного ингдекса для подсказок.

 

[******]

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

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

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

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

 

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

[SooR]

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

 

1. 

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

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

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

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

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

[SooR]

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

[SooR]

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

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

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

[******]

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

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

 

1. 

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

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

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

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

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

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

 

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

[******]

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

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

 

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

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

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

Ioncube ...

[SooR]

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

 

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

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

 

[******]

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

@****** , гделай 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]

 

[******]

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

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

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

 

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

[Guava]

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

 

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

 

[******]

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

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

 

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

 

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