Полезные советы или как увеличить скорость загрузки сайта с 25000 категориями и больше.

alexpimnev,
18
да и забыл упомянуть при экспорте через админку в csv всех категорий с товарами nginx падает 502 ошибка

На данный момент залито 110.000 категорий и 17.000 товаров
Время выполнения: 0.235 с, из них
время загрузки модулей: 0.000 с
время генерации содержания страницы: 0.220 с
время соединения с СУБД: 0.000 с
время выбора БД: 0.000 с
время выполнения запросов: 0.013 с
время обработки XML: 0.020 с
Использовано памяти: 9.10 Мб.
Количество запросов: 49.
Компрессия: Отключено.
Кэширование: Отключено.
Выявленные косяки. Ajax parser error при пересчете магазина ... Попробую написать в тех.поддержку Может чего насоветуют.

alexpimnev писал(а):

avtozakup,
сколько товаров выводите на страницу?

avtozakup писал(а):

alexpimnev,
18

Вот, собственно, и яркий показатель бессмысленности ваших тестов

Давайте разберемся, что вы измеряете.

Есть субъективная "скорость загрузки"? Это, в общем-то, очень обобщенный показатель суммарного времени, за которое происходят все процессы, нужные отображения страницы, а именно:
1. Передача запроса на сервер;
2. Анализ запроса и генерация html-страницы;
3. Передача html-ответа в браузер;
4. Передача на сервер запрос стилей и скриптов, связанных со страницей;
5. Анализ запросов стилей и скриптов на сервере и передача из в браузер;
6. Запрос остального связанного контента (картинки, флеш и т.п.) и параллельно отрисовка страницы в браузере.

То есть вот тут мы видим что в скорость загрузки у нас укладываются и всевозможные сетевые задержки, и дозапрос свзанного содержимого, и особенности алгоритмов рендеринга страниц в разных браузерах, и подгрузка всяких сторонних ресурсов (лайки соц.сетей, партнерки рекламных сетей и т.п.).
То есть куча всяких дополнительных факторов, которые никак не зависят от самой CMS и от числа товаров в базе.
Кстати сказать, на предыдущей странице ваш пример про Firebug и ошибку 404 - как раз тот случай, когда на скорость работы сайта влияет чисто сетевая составляющая. CMS не виновата в том, файла /templates/template14/style.css не существует, отдает этот файл веб-сервер своими средствами, и до php тут дело не доходит и не должно.
(Да, это косяк разработчика шаблона, который не создал нужный файл. Но это никак не связано с конкретной CMS, и точно также будет справедливо и для сайта сделанного вручную на html-файлах)

Если мы возьмем для измерения не браузер конечного пользователя, а всякие сервисы вроде loadimpact (кстати, неплохой сервис, но им нельзя адекватно измерить эффективность самой cms, он немного для другого предназначен), то из вышеперечисленного списка у нас уйдут пункты 4-6, но 1 и 3 останутся, и будут вносить некую случайную погрешность. Кроме того, пункт 2 тоже не является характеристикой cms в чистом виде - на получаемый в нем результат сильно влияют настройки сервера. Например, если на сервере хорошо настроено кеширование страниц, то при первом обращении к странице отработает php, а при всех последующих веб-сервер будет просто мгновенно отдавать вам копию страницы из кеша.

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


С точки зрения эффективности работы CMS измерять надо только одно - время работы php-скрипта, то есть сколько времени проходит с момента вызова php до окончания его работы.
Все что было до вызова php - все сеть и веб-сервер, все что после - это тоже сеть и пользовательское устройство, в общем случае ни то ни другое нам неподвластно.
А вот на то что происходит внутри php мы можем влиять. Но засекать врем работы скрипта самому - достаточно сложно. Поэтому разработчики системы о нас уже позаботились.
Таким образом, единственно верной характеристикой эффективности работы самой HostCMS являются данные из окна "Отладочная информация" которое доступно на всплывающей панели в клиентской части сайта, если вы при этом залогинены в админке.
Там есть честные данные про общее время выполнения и кол-во запросов. Вот на них и нужно ориентироваться. Но этого вам никакой loadimpact не покажет.

Теперь еще про бессмысленность
Умница alexpimnev зрит в корень! При генерации страницы, при условии, что у вас грамотно сделана интеграция, совершенно никакого значения не имеет то, сколько всего у вас товаров в базе.
Имеет значение только то, сколько товаров на страницу вы выводите, и сколько у выводимых товаров доп.свойств, модификаций, сопутствующих товаров и отзывов. Ну и еще количество подгрупп в текущей группе.
Если вы выводите 18 товаров на страницу, то сколько бы товаров не было в базе, время генерации страницы от этого не изменится почти* никак. Потому что из базы выбираются данные только для 18 товаров.
А база данных гораздо более устойчива к большим объемам данных, чем php. Попробуйте, например, не меняя количество товаров в базе, увеличить число товаров на странцу в 2 раза, в 5 раз, в 10 раз, и почувствуйте разницу
Или, как вариант, оставив те же 18 товаров на страницу, создайте и заполните для них 10 доп.свойств, 20 доп.свойств, 50 доп.свойств и тоже сравните время генерации.

А те результаты измерений, которые вы тут с такой радостью публикуете, вызывают у меня примерно такую ассоциацию:
Представьте себе, автоцистерну. Например, с водой - ездят летом такие машинки-поливалки, вот самое оно.
У цистерны есть люк сверху - это админка, через которую вы заливаете товары, и есть краник сзади внизу, возле которого стоит ведро на 18 литров (это аналог страницы, на которой грузится 18 товаров). Первый ваш пост про то, что краник-то, оказывается, можно открыть пошире, и тогда ведро будет наполняться не за 7 секунд, а за 5!
А все остальные посты про то, что вы наливаете все больше воды в цистеру, а ведро наполняется по-прежнему за 5 секунд! Круто же!
А вот alexpimnev знает, что если вместо 18-тилитрового ведра подставить под струю 54-тилитровую канистру, то она будет наполняться целых 15 секунд, а не 5. Потому что краник еще шире не открывается, и для сохранения прежнего времени надо менять уже весь патрубок

Вот как-то так.
И ничего личного. Я рад что вы пытаетесь разобраться в системе, хоть и не с той стороны ) Зато для вас это, наверное, увлекательно.


---
* Примечание про слово "почти". Некоторые изменения будут, но они связаны с погрешностями из-за неравномерной загрузки самого сервера. На нем же крутится одновременно много процессов, поэтому в разные моменты времени одни задачи слегка "зажимают" другие. Если вы просто, без всяких изменений, пообновляете одну и ту же страницу несколько раз, то вы увидите, что время генерации каждый раз немного отличается. Поэтому правильнее делать несколько измерений, скажем, штук 10, и вычислять среднее время генерации. Вот на основании среднего времени уже можно делать какие-то выводы о влиянии числа товаров на скорость генерации страницы.
И еще обращайте внимание на общее время выполнения запросов. При увеличении числа товаров, в какой-то момент вы можете столкнуться с тем, что размеры таблиц в базе данных станут превышать тот оптимум, для которого заданы текущие настройки движка БД (MySQL) и сама БД начнет работать неэффективно. Но это не имеет отношения к производительности самой CMS, и лечится тюнингом настроек движка БД и/или сменой сервера, если тюнинг уже не помогает.




P.S. Какой-то неравномерный у меня получился ответ - у вас про субъективную скорость загрузки только в первом посте речь идет, а я половину проста про это накатал )) Впрочем, лишний раз повторить теорию никогда не вредно и возможно в этом для вас тоже было что-то интересное

Kotoff,
Да я вкурсе что доп.свойства товара и колво отображения товаров влияют на общее число запросов к бд. Я поэтому и вывожу по 18 на страницу а не по 50 или 100. И в каждом сообщении есть отладочная информация. Я честно вообще не понял о чем ваш пост . Вдобавок почему я начал данный тест. Я ставил разные CMS и при правильной интеграции они не тянули 50.000 категорий не говоря уже о товарах.
Но вообще всплыла огромная для меня проблема которая весь тест рушит на корню так что эксперимент можно закрывать. При таком колве категорий и товаров как у меня админка жутко тормозит , в тех. поддержке написали из за селекта , вот его бы оптимизировать и тогда было бы все супер. Что интересно в 5й версии админка при похожем кол-ве товаров и категорий так не тормозила.

Магазин с 7000000 товаров.
Оптимизация времени загрузки