Перейти к публикации
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...

Помогите ускорить магазин и 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.
Владелец магазина возмущается, ему не достаточно скорости.

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

Ссылка на комментарий
Поделиться на других сайтах


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

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

 

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

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

Ссылка на комментарий
Поделиться на других сайтах


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

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

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

Ссылка на комментарий
Поделиться на других сайтах


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

 

Цитата

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

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

Изменено пользователем n3bo
Ссылка на комментарий
Поделиться на других сайтах


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

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

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

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

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

Ссылка на комментарий
Поделиться на других сайтах

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

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

 

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

 

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

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

 

 

yaya.jpg

Ссылка на комментарий
Поделиться на других сайтах


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

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

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;


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

Ссылка на комментарий
Поделиться на других сайтах


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

UPD. Sphinx третий?

Ссылка на комментарий
Поделиться на других сайтах

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

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

Пускай аргументирует чем не устраивают <= 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 запроса. 

 

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

Ссылка на комментарий
Поделиться на других сайтах


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

 

1. 

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

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

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

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

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

Ссылка на комментарий
Поделиться на других сайтах

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

Ссылка на комментарий
Поделиться на других сайтах

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

При переходе на 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 ...

Ссылка на комментарий
Поделиться на других сайтах


@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

 

Ссылка на комментарий
Поделиться на других сайтах

Только что, 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.

 

Ссылка на комментарий
Поделиться на других сайтах


Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по 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....} Которые достаточно просто уже сгруппировать и рассчитать.

Ссылка на комментарий
Поделиться на других сайтах


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

 

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

 

Ссылка на комментарий
Поделиться на других сайтах


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

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

 

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

 

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

Ссылка на комментарий
Поделиться на других сайтах


Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас
 Поделиться

×
×
  • Создать...

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.