Prestashop из коробки, ужас летящий на крыльях ночи и оптимизация.

ну так это нормально, отключите дебаг, включите кеш и проверяйте, вот пример на одном из моих работ:
стр. категории, на странице 48 тов, фильтр
Requests - 63
Load time - 1.26 s

Хмммм... отключил дебаг включил кеш
Оставил _PS_DEBUG_PROFILING_ = true ( а вы включаете _PS_DEBUG_PROFILING_ или смотрите запросы как то по другому ? )

Запросов теперь 251 queries

А у вас какая версия Presta ?
у меня 1.7.1.2
 
Вот как пример
14 запросов вида
SELECT image_shop.`cover`, i.`id_image`, il.`legend`, i.`position`
FROM `ps_image` i
INNER JOIN ps_image_shop image_shop
ON (image_shop.id_image = i.id_image AND image_shop.id_shop = XX)
LEFT JOIN `ps_image_lang` il ON (i.`id_image` = il.`id_image` AND il.`id_lang` = XX)
WHERE i.`id_product` = XX
ORDER BY `position`

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

SELECT image_shop.`cover`, i.`id_image`, il.`legend`, i.`position`
FROM `ps_image` i
INNER JOIN ps_image_shop image_shop
ON (image_shop.id_image = i.id_image AND image_shop.id_shop = XX)
LEFT JOIN `ps_image_lang` il ON (i.`id_image` = il.`id_image` AND il.`id_lang` = XX)
WHERE i.`id_product` in (x1,x2,x3 .....)
ORDER BY `position`
Извините, сильно не вникал, но даже так, это не очень быстро.
Правильно было бы 2 запроса: первый запрос выбирает продукты, потом в ПХП проходим циклом все продукты и складываем в массив одновременно формируя запрос за картинками по id с известным limit, второй запрос забирает картинки и складывает в тот же массив, что и данные о товаре. Потом проходим циклом по массиву и публикуем товары с картинками.
Всякие INNER JOIN, LEFT JOIN и ORDER BY отдыхают перед SELECT * WHERE id=X1 or id=X2 or ... LIMIT Y
А также значительно разгружается память на кешировании запросов.

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

ну так это нормально, отключите дебаг, включите кеш и проверяйте, вот пример на одном из моих работ:
стр. категории, на странице 48 тов, фильтр
Requests - 63
Load time - 1.26 s
На мой взгляд это медленно. Оптимально 0.1 сек на страницу. Ожидание генерации страницы отбивает у клиента желание продолжать браузинг.
 
Извините, сильно не вникал, но даже так, это не очень быстро.
Правильно было бы 2 запроса: первый запрос выбирает продукты, потом в ПХП проходим циклом все продукты и складываем в массив одновременно формируя запрос за картинками по id с известным limit, второй запрос забирает картинки и складывает в тот же массив, что и данные о товаре. Потом проходим циклом по массиву и публикуем товары с картинками.
Всякие INNER JOIN, LEFT JOIN и ORDER BY отдыхают перед SELECT * WHERE id=X1 or id=X2 or ... LIMIT Y
А также значительно разгружается память на кешировании запросов.

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


На мой взгляд это медленно. Оптимально 0.1 сек на страницу. Ожидание генерации страницы отбивает у клиента желание продолжать браузинг.
это где вы видели интернет-магазин у которого загрузка страницы 0.1 сек ? Дайте пример...
 
это где вы видели интернет-магазин у которого загрузка страницы 0.1 сек ? Дайте пример...
Генерация, а не загрузка.

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

Когда пишу код, ориентируюсь на такие цифры - до 0.1 сек на генерацию страницы и до 0.4 сек на загрузку и отображение. То есть страницы должны быть маленькими и "несложными" для отбражения в браузере.

вКонтакте раньше публиковал статистику, у них на генерацию страницы уходило в среднем 0,058 сек и это не считается мега-быстрым сайтом.
 
для мелких-средних магазинов (1к-10к товаров) преста вполне нормальная система, особенно учитывая открытый исходный код и доступность модулей и специалистов на ней

на 1.6 для достаточно сложной страницы с фильтрами, атрибутами, характеристиками, несколькими картинками, внешними скриптами и т.д.
вполне оптимальная картина

Для просмотра ссылки Войди или Зарегистрируйся

upload_2017-7-25_11-46-17.png
 
чет не въеду, тот же пингдом показывает время отдачи
NoName.jpg

магазин vans из топ 20 eCommerce - страница товара, время ожидания 205 мс
 
для мелких-средних магазинов (1к-10к товаров) преста вполне нормальная система, особенно учитывая открытый исходный код и доступность модулей и специалистов на ней
Отличная система и относительно других систем быстрая.

на 1.6 для достаточно сложной страницы с фильтрами, атрибутами, характеристиками, несколькими картинками, внешними скриптами и т.д.
вполне оптимальная картина
Этот тест только показывает насколько быстро ваш сайт скачивается на сервер в Швеции. Хорошо скачивается и относительно быстро отображается в браузере, всё хорошо, хоть и не идеально.

А этот скриншот показывает сколько времени сервер тратит на создание страницы + пинг, кстати, перед скрином пять раз обновил страницу, должно было закэшироваться всё что могло, это средний показатель.
screen.jpg

А это скрин работы второго по популярности в Украине ИМ
Для просмотра ссылки Войди или Зарегистрируйся

screen2.jpg

И всем известная Розетка, обратите внимание, размер несжатой страницы 930кб. Про количество товаров и онлайна, думаю, можно не говорить.
Для просмотра ссылки Войди или Зарегистрируйся
screen3.jpg

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


Этот тест только показывает насколько быстро ваш сайт скачивается на сервер в Швеции. Хорошо скачивается и относительно быстро отображается в браузере, всё хорошо, хоть и не идеально.

А этот скриншот показывает сколько времени сервер тратит на создание страницы + пинг, кстати, перед скрином пять раз обновил страницу, должно было закэшироваться всё что могло, это средний показатель.
Посмотреть вложение 87092

А это скрин работы второго по популярности в Украине ИМ
Для просмотра ссылки Войди или Зарегистрируйся

Посмотреть вложение 87093

И всем известная Розетка, обратите внимание, размер несжатой страницы 930кб. Про количество товаров и онлайна, думаю, можно не говорить.
Для просмотра ссылки Войди или Зарегистрируйся
Посмотреть вложение 87094

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

спор ни о чём, но что новый фотос, что розетка часто ужасно тормозят, хоть и стоимости овоксовой программной части от 10к USD



upload_2017-7-25_23-21-54.png

upload_2017-7-25_23-22-27.png








upload_2017-7-25_23-23-40.png


upload_2017-7-25_23-38-24.png




обычная преста 1.6 на варехаузе:
upload_2017-7-25_23-25-43.png

upload_2017-7-25_23-34-55.png



в то же время обычный каталог на престе:

upload_2017-7-25_23-32-54.png
upload_2017-7-25_23-33-57.png




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


к тому же нет никаких обязаловок и ограничений, разве что объём целесообразных инвестиций в проект, направленный на окупаемость

в этом мире всё возможно!

главное - действовать
 

Вложения

  • upload_2017-7-25_23-24-1.png
    upload_2017-7-25_23-24-1.png
    5 KB · Просмотры: 8
  • upload_2017-7-25_23-26-7.png
    upload_2017-7-25_23-26-7.png
    4,7 KB · Просмотры: 7
Назад
Сверху