100napb

@SooR

¯\_(ツ)_/¯

могу лишь такое сравнение привести со своей стороны

 а с промежуточной таблицей? хотя это уже почти агрегат... с ней не интересно

1 hour ago, SooR said:

А теперь еще замените

решил посмотреть как изменятся конкретные цифры. Спасибо. Спасибо потому, что

Во-1: я немного ошибся в результатах на живом примере, которые приводил выше. они были приведены для более тяжелого варианта запроса, в котором было отключено уточнение по дате и запрос, по сути, считал вообще все заказы *смущенный смайл*. Ну на коленке же тестируем, ради интереса... Зато! С уточнением по дате, как и было в изначальном условии задачи, запрос работает даже без промежуточных таблиц быстрее: менее 0.1сек. Не так уж и плохо, хотя с агрегатом можно еще быстрее.

Во-2: от варианта записи даты через adddate-interval или явно, результат 0.1сек прям заметно не меняется. хотя я согласен - должно быть быстрее, если указывать дату явно, как Вы и уточнили.

Quote

Если что, мы с 6 сек на этом реализации, получили 0.18 мс. 

подобное время возможно при использовании предварительно вычисленных агрегатов, например. Как заметили выше - это самое очевидное и простое решение. При работе с ними, весь этот запрос превращается во что-то вроде select product_id as popular from agregate_table where category_id\path_id = ?.

Как альтернативный вариант - использование иных хранилищ, взамен mysql (на мой взгляд сложнее + так же требует синхронизации данных, как и агрегаты - пересоздания)

ради спортивного интереса чуть переписал этот кривенький запрос:

а) вычисление популярных товаров из секции select можно вынести в отдельный джоин

б) подсчет количества заказов для каждого товара категории - это не совсем корректный признак его популярности, в то время как сумма купленного количества товара должна быть более точной характеристикой. Потому Count(op.order_id) AS popular заменил на SUM(op.quantity) AS popular. На скорость это не влияет.

SELECT SQL_NO_CACHE
  p.product_id
FROM oc_category_path cp
  JOIN oc_product_to_category p2c
    ON (cp.category_id = p2c.category_id)
  JOIN oc_product p
    ON (p2c.product_id = p.product_id)
  JOIN oc_product_description pd
    ON (p.product_id = pd.product_id)
  JOIN oc_product_to_store p2s
    ON (p.product_id = p2s.product_id)
  JOIN (SELECT
      op.product_id,
      SUM(op.quantity) AS popular
    FROM oc_order_product op
      JOIN `oc_order` o
        ON (op.order_id = o.order_id)
    WHERE o.order_status_id > '0' AND Adddate(o.date_added, INTERVAL 30 day) < Now()
    GROUP BY op.product_id) popular
    ON p.product_id = popular.product_id
WHERE pd.language_id = '1'
AND p.status = '1'
AND p2s.store_id = '0'
-- подставить свои значения или выполнить так, типа, для вообще всех товаров, что бы посложнее 
-- AND p2c.category_id = ?
-- AND cp.path_id = ?
GROUP BY p.product_id
ORDER BY (p.quantity > 0) DESC,
popular.popular DESC,
LCASE(pd.name) DESC,
p.date_added DESC
LIMIT 0, 3;

Результаты на живом примере:

при 380к активных и включенных товаров в oc_products и 40к+ заказов в oc_order время выполнения этого запроса без привязки к какой-либо категории чуть менее 0.4сек.

С уточнением категории, разумеется, будет быстрее: с потенциальным минимумом, равным времени выполнения запроса из джоина с вычислением популярных товаров (на моих данных около 0.2сек). Если же этот джоин с вычислением popular заменить предварительно посчитанной таблицей, то итоговое время выполнения запроса будет еще меньше: ~0.01сек для категории с 1к товаров, например или около 0.2сек для определения топ3 среди всех 380к товаров.

Спасибо.

Quote

Если вы мне покажите хоть кто-то, подобную динамику роста трафика от ваших решений:

График, безусловно, выглядит очень вкусно. Позвольте спросить, на какую дату(ы) приходились Ваши работы - что брать за точку отсчета?

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

Я потому так думаю, что у меня есть немало примеров и наблюдений, так сказать, "до ускорения \ после ускорения". В том числе на достаточно крупных проектах. Определенно, почти сразу улучшаются поведенческие факторы, количество ботов \ генераций страниц и прочее (особенно визиты ботов - если ранее им не хватало "бюджета" ходить по медленному сайту, то после того как сайт начинает отвечать быстро, они прям яростно индексируют). Но что бы такой рост чистого трафика... может я недостаточный интервал времени брал для наблюдений, конечно. Но впечатляет, да.

25 minutes ago, satt said:

Есть какие-то бенчмарки для VPSов/хостингов?

как вариант.

11 hours ago, SooR said:

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

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

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

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

12 hours ago, SooR said:

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

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

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

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

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

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

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

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

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

[censored]