[miniShop2] Первый тест на скорость
Провел первый тест скорости выборки товаров, на скорую руку. Просто раскопировал 10000 товаров, со всеми свойствами в одной категории и почистил кэш.
Первая загрузка после очистки кэша, limit 10
Вторая загрузка, limit 10
Первая загрузка после очистки, limit 100
Вторая загрузка, limit 100
Первая загрузка после очистки, limit 1000
Вторая загрузка, limit 1000
Важное уточнение, friendly urls отключены, потому что система ругается на одинаковые алиасы. Позже протестирую и с ними, только нужно переписать копирование, для генерации уникальных алиасов.
В любом случае, первый тест очень порадовал. В админке тормозов вообще нет, ни при создании товаров, ни при переходе по страницам, ни при очистке кэша.
Если интересно — могу записать видео.
Первая загрузка после очистки кэша, limit 10
Вторая загрузка, limit 10
Первая загрузка после очистки, limit 100
Вторая загрузка, limit 100
Первая загрузка после очистки, limit 1000
Вторая загрузка, limit 1000
Важное уточнение, friendly urls отключены, потому что система ругается на одинаковые алиасы. Позже протестирую и с ними, только нужно переписать копирование, для генерации уникальных алиасов.
В любом случае, первый тест очень порадовал. В админке тормозов вообще нет, ни при создании товаров, ни при переходе по страницам, ни при очистке кэша.
Если интересно — могу записать видео.
21 февраля 2013, 07:15
Комментарии: 46
Примерно так:
file.modx.pro/files/486/b/d/8/bd81d2e97e38678d541f34e0d082a499.png
Были бы ещё данные о работе через getResources и miniShop при тех же входных данных.
file.modx.pro/files/486/b/d/8/bd81d2e97e38678d541f34e0d082a499.png
Были бы ещё данные о работе через getResources и miniShop при тех же входных данных.
Не имеет смысла, ибо getRetsources не понимает половину тегов и наворотов, например, не разбираются опции товаров в JSON.
Но если даже без всего этого, цифры генерации страницы примерно такие.
10 товаров: 1й запуск — 0,97 сек, 2й запуск — 0,75 сек
100 товаров: 1й запуск — 4,9 сек, 2й запуск — 4,2 сек.
1000 товаров: не осилил
При 10 товарах, разница вроде не особо заметна, но затем pdoTools просто уходит в точку.
Но если даже без всего этого, цифры генерации страницы примерно такие.
10 товаров: 1й запуск — 0,97 сек, 2й запуск — 0,75 сек
100 товаров: 1й запуск — 4,9 сек, 2й запуск — 4,2 сек.
1000 товаров: не осилил
При 10 товарах, разница вроде не особо заметна, но затем pdoTools просто уходит в точку.
Репозиторий вот тут.
Держи текущую сборку, вроде работает.
Еще не готово оформление заказа и раздел для их управления в админке.
Держи текущую сборку, вроде работает.
Еще не готово оформление заказа и раздел для их управления в админке.
Лично я ТВ не планирую использовать вообще. Но, при грамотном запросе, от лишних ТВ тормозов не будет.
Пробовал джойнить около 10 таблиц в один запрос — никакого замедления.
Вот, что я буду использовать вместо ТВ — modx.pro/development/742/
Пробовал джойнить около 10 таблиц в один запрос — никакого замедления.
Вот, что я буду использовать вместо ТВ — modx.pro/development/742/
0.4 — после очистки кэша на 10000 ресурсах — не быстро?
Ну я не знаю… Там 0,22 — это только выборка из базы. А приготовление и вывод на экран, выходит 0,18. На мой взгляд, весьма неплохо.
Опять же, погляди на скорость при повторной загрузке страницы (а это основной режим работы сайта) — 0,15 сек.
Ну я не знаю… Там 0,22 — это только выборка из базы. А приготовление и вывод на экран, выходит 0,18. На мой взгляд, весьма неплохо.
Опять же, погляди на скорость при повторной загрузке страницы (а это основной режим работы сайта) — 0,15 сек.
Как выйдет первая бета, я потестирую обязательно. Еще такой вопрос, почему решили использовать CRC?
Отдельная база была бы отличным решением, а ресурс как контейнер для категории. На мой взгляд только свои таблицы могут дать высокую скорость. Т.к. в ресурсах происходит много действий не нужных товарам
Отдельная база была бы отличным решением, а ресурс как контейнер для категории. На мой взгляд только свои таблицы могут дать высокую скорость. Т.к. в ресурсах происходит много действий не нужных товарам
А ты попробуй на досуге научить работать Wayfinder и другие сниппеты с отдельной таблицей.
А потом напиши свой обработчик friendly urls.
А потом еще много чего вылезет.
Проще не использовать MODX вообще, и писать сразу свой магазин. Только зачем, когда вокруг есть толпа уже готовых?
miniShop2 — бесплатное расширение для движка MODX, и максимально его задействует.
А потом напиши свой обработчик friendly urls.
А потом еще много чего вылезет.
Проще не использовать MODX вообще, и писать сразу свой магазин. Только зачем, когда вокруг есть толпа уже готовых?
miniShop2 — бесплатное расширение для движка MODX, и максимально его задействует.
Полез искать самое тормозное место в работе сниппета, и нашел!
Это функция getChildIds, которая рекурсивно ищет потомков ресурса, из которого выводится каталог.
Немного уточнил лог и выходит вот это (смотрим на строчку «Query parameters are prepared.»)
Глубина выборки 10
Глубина выборки 1
Глубина 0, функция отключена
Очевидно, тормоза оттого, что в категории 10000 потомков. Но всегда можно указать параметр &depth=`1` и перечислить нужных родителей через запятую — так будет быстрее.
Очистка кэша как раз и влияет на построение дерева ресурсов, с которым работает getChildIds(). Поэтому с depth=1 сниппет отрабатывает за 0,12 сразу после очистки, а потом уже — 0,09.
Вот такие пироги. Куда еще убыстрить — не знаю.
Это функция getChildIds, которая рекурсивно ищет потомков ресурса, из которого выводится каталог.
Немного уточнил лог и выходит вот это (смотрим на строчку «Query parameters are prepared.»)
Глубина выборки 10
Глубина выборки 1
Глубина 0, функция отключена
Очевидно, тормоза оттого, что в категории 10000 потомков. Но всегда можно указать параметр &depth=`1` и перечислить нужных родителей через запятую — так будет быстрее.
Очистка кэша как раз и влияет на построение дерева ресурсов, с которым работает getChildIds(). Поэтому с depth=1 сниппет отрабатывает за 0,12 сразу после очистки, а потом уже — 0,09.
Вот такие пироги. Куда еще убыстрить — не знаю.
Окей, показывай свой сайт с такими скоростями, чтобы работал на MODX Revolution и выводил внизу плейсхолдер [^t^]. Желательно, с таким же функционалом, но можно и без.
Тебе же есть, что показать, или мы будем обсуждать сферических «любых оптимизаторов»?
Я не заявляю, что мой сайт или MS2 самый быстрый на свете. Но одни из самых быстрых на Revolution — факт. Если ты готов с этим поспорить — давай свои реальные аргументы.
Тебе же есть, что показать, или мы будем обсуждать сферических «любых оптимизаторов»?
Я не заявляю, что мой сайт или MS2 самый быстрый на свете. Но одни из самых быстрых на Revolution — факт. Если ты готов с этим поспорить — давай свои реальные аргументы.
Не занимайтесь хуйней — как я заметил на практике render time не всегда показывает объективные данные, +очистки кеша и перегенерация страницы могут действительно привести к результату в 1.5-2 секунды.Это не критично и не влияет на обывателя, т.к при следующем рендере сработает Cache и скорость будет оптимальной.
Хорош ересь молоть, господа. И VC и FC, порой, «часами» отзываются. А «средняя температура по больнице», действительно 0.3-0.8 — тут нечего сусолить.
П.С.
Иногда, для ускорения сайта, помогает «пересаживание с калькулятора на компьютер», подключенный к Интернет, а не «черепашьим лапкам».
П.С.
Иногда, для ускорения сайта, помогает «пересаживание с калькулятора на компьютер», подключенный к Интернет, а не «черепашьим лапкам».
Как то плавно обсуждение скорости выборки из 10000 товаров перешло на скорость моего сайта.
Причем, на предложение продемонстрировать «как надо» гражданин слился. Видимо, просто скучающий тролль забрёл.
Причем, на предложение продемонстрировать «как надо» гражданин слился. Видимо, просто скучающий тролль забрёл.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Здесь упомянуты:
| Компонент | Текущая версия | Закачки |
| miniShop2 | 4.4.0-pl от 06.08.2024 | 26 104 |
| pdoTools | 2.13.2-pl от 02.09.2021 | 54 173 |
| MinifyX | 1.7.1-pl от 25.03.2019 | 14 300 |
Вчера в 08:53
если правильно понял то так
{set $rows = json_decode($_modx->resource.constructor_block, true)}
{foreach $r...
