Медленный — быстрый сайт?

Question

[i_want_to_know_everything]

По тестам, на все оптимизированно по самое не балуйся



Но все равно сайт еле ползает, как можно поддать ему скорости.
Wordpress + WooCommerce + 60k товаров на которые приходится 10k терминов и 1.5kk ( 1 500 000 ) метаполей

кэширование запросов в базу + кэширование статики включены

Comments

[Сергей Горностаев]

Не использовать Wordpress :)

[АртемЪ]

Вы трассировку делали? Сколько времени нужно скрипту для отработки стандартных действий пользователя?
Кэширование запросов в базу и кэширование статики тут вообще никаким боком.

[i_want_to_know_everything]

АртемЪ: А вот этого я не знать, подскажите мануал, как такое сделать.

[АртемЪ]

i_want_to_know_everything: Да какой там мануал? В код отладочную информацию добавляете, чтобы писал время начала и конца выполнения операции и смотрите, по самым востребованным и ресурсоемким операциям, что больше всего занимает времени, а уж потом думаете и оптимизируете.

[i_want_to_know_everything]

АртемЪ: ну спс, я так и понял, немного подумав)

Answer 1

[Дмитрий]

Не слушайте вы всякие "Под это уже надо серьезный магазин, скорее всего с доработкой" и прочее.
Это вас либо развести на дополнительные деньги хотят, либо не совсем понимают)

Все у вас с сервером хорошо. По тестам жеж видно - страницу сервер отдает первый байт через 0.3 секунды. Куда еще его оптимизировать?
А все остальные почти 20 секунд у вас фронтенд грузится/рендерится.
(кстати, повторный визит почему-то у вас начинает отдавать страницу через почти 2 секунды, что странно. С сервером все-таки что-то не так)

Скорее всего у вас там стоит платный шаблон, а они особо о скорости работы не заморачиваются.
Оптимизировать вам его и нужно.

Самое простое, что можете сделать, перенести всю статику на CDN, может этого достаточно будет. Если не поможет, тогда уже более серьезные работы нужны дубут.

Comments

[i_want_to_know_everything]

Да, именно так, разогнал пока до таких показателей
dl2.joxi.net/drive/2016/11/27/0006/1021/394237/37/...
Чуток переписал логику фильтра товаров, он жрал отчаянно ресурсы

[Дмитрий]

i_want_to_know_everything:
прогоните сайт через гугл инсайтс, если подходить к тем советам без фанатизма, поможет

[i_want_to_know_everything]

Дмитрий: то, что он (PageSpeed Insights) может рассказать, ИМХО не сущщественно

хотя его рекомендации выполнены давно
joxi.ru/Vm6vGGgSxg88om

[Дмитрий]

i_want_to_know_everything: тогда смотрите, что у вас скрипты делают.
на втором скриншоте - 1 http запрос, на 17 кб, и все равно время до загрузки сайта 20 секунд.

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

Answer 2

[Игорь Воротнёв]

Если у вас именно фильтры / поиск / аггрегация товаров жрут много времени (в том числе аякс-запросы, в виджетах и тд) - смотрите в сторону Elastic Search. WP_Query и его расширенная версия от WooCommerce не особо предназначены для такого объема данных. Будут ли они работать? О да, если железо с большим запасом. Но лучше перенести это все на Elastic Search, и сервер сильно выдохнет.

Впрочем, по скринам у вас бекенд в принципе шустрый. Вопрос скорее во фронте. И вот тут надо смотреть, что именно его так насилует. Предположение Дмитрий по поводу тяжелой темы скорее всего верное. Попробуйте http/2, должно облегчить (а по хорошему это уже должно быть стандартом). Темку надо тестить и искать узкие места. Явно тонны javascript. Если много аякс-запросов шлет тема, смотрите можно ли запрашиваемые данные отдавать без ajax или хотя бы сделать fragment caching для этих данных и возвращать из сразу сгенерированными в конечный результат из памяти. В общем, в таких случаях надо дебажить на всех уровнях, искать узкие места и устранять их на корню.

Comments

[i_want_to_know_everything]

переписал логику фильтра добился такого

[Игорь Воротнёв]

i_want_to_know_everything: уже другое дело :)

Answer 3

[АртемЪ]

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

60k товаров на которые приходится 10k терминов и 1.5kk ( 1 500 000 ) метаполей

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

Comments

[i_want_to_know_everything]

я знаю, но вот сами Woo говорят, что такое оно должно тянуть достаточно прилично

[АртемЪ]

i_want_to_know_everything: А я говорю что инопланетяне существуют.
Верите?

[i_want_to_know_everything]

АртемЪ: Ну я лично знаю магазины на которых крутится 25к товров на woocommerce

[АртемЪ]

i_want_to_know_everything: 60k товаров на которые приходится 10k терминов и 1.5kk ( 1 500 000 ) метаполей
Я так понимаю метаданные вы не просто ради интереса добавляете?
А для поиска, сортировки и сравнения?

[Игорь Воротнёв]

я лично знаю и принимал участие в разработке магазинов на WP+WC, в которых объем данных превышал озвученный раз в 5. И все прекрасно работает. Не уметее готовить - не беритесь и не говорите другим ерунды.

[АртемЪ]

Игорь Воротнёв: Объем по количеству или по свойствам? И какая нагрузка?
Само по себе количество номенклатуры не показатель, шустро будет и пара миллионов номенклатуры.
Но вот устройте подбор по свойствам - и уже возникнут проблемы на гораздо меньших числах.

[Игорь Воротнёв]

АртемЪ: таблица wp_postmeta содержит почти 12 млн строк. Товаров под 200к. Терминов правда меньше, но это как раз не столь важно. Нагрузка высокая (северная Америка, популярный магазин), в распродажи - адская. Ситуация с запросами по postmeta путем перебора всех строк это конечно тормоза, в силу архитектуры данной таблицы. Решается на ура с помощью Elastic Search, который ищет мгновенно и возвращает ID конкретных товаров которые надо отобразить базовым WP_Query без какого-либо перебора метаданных.

[АртемЪ]

Игорь Воротнёв: Характеристик номенклатуры сколько?

[Игорь Воротнёв]

АртемЪ: разделите 12млн на 200к

[i_want_to_know_everything]

АртемЪ: nobody:
переписал логику фильтра добился такого