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

[che02]

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

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

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

А у вас какая версия Presta ?
у меня 1.7.1.2

 

[sergiykhd]

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

 

[che02]

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

хммм , наверно тут дело в версии Presta
Попробую поставить 1.6 - проверю на ней

но на 1.7 все пока грустно.

 

[ajrengen]

Вот как пример
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 сек на страницу. Ожидание генерации страницы отбивает у клиента желание продолжать браузинг.

 

[sergiykhd]

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

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


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

это где вы видели интернет-магазин у которого загрузка страницы 0.1 сек ? Дайте пример...

 

[ajrengen]

это где вы видели интернет-магазин у которого загрузка страницы 0.1 сек ? Дайте пример...

Генерация, а не загрузка.

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

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

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

 

[_sashok]

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

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

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

 

[sergiykhd]

чет не въеду, тот же пингдом показывает время отдачи


магазин vans из топ 20 eCommerce - страница товара, время ожидания 205 мс

 

[ajrengen]

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

Отличная система и относительно других систем быстрая.

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

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

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


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



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


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

 

[_sashok]

Отличная система и относительно других систем быстрая.


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

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

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

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

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

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

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






















обычная преста 1.6 на варехаузе:






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







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


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

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

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