Рациональность работы OKAY с данными

[korshunov]

Открываю демо сайт сразу после свежей установки (в 00 или 30 минут).
Сайт работает шустренько, переходы быстрые, в коде страницы показатели примерно
memory peak usage: 12 МБ
page generation time: 0.2 seconds

Провожу импорт файла в приложении.
Файл всего 100К, содержит 800 товаров, данные очень короткие, без длинных текстов, свойств файле нет.
Что в нем примечательно, что каждый товар содержится в категории 5-го уровня, так что категорий всего примерно 2 тысячи.

Импорт длится примерно 2 минуты, что весьма долго для такого файла.

После импорта сайт работает заметно медленнее даже на глазок. Показатели теперь примерно такие
memory peak usage: 19 МБ
page generation time: 0.3 seconds
то есть и используемая память и время выполнения запросов увеличились в полтора раза.

По-моему, для такого объема данных замедление работы сайта недопустимо.

Причины досконально не исследовал. Подозреваю, что такая картина есть следствие как общей нерациональности CMS в плане экономичности ресурсов, о чем на форуме уже говорилось, так и нерациональности работы с категориями, которые в значительной части пришли из Simpla...

Сопоставьте масштабы - файл импорта в 0.1M дает прибавку используемой памяти в 8M. И прибавку во времени выполнения запроса 0.1 сек - это еще хуже. Думаю, это не нормально.

А файл в примере - далеко не самый сложный из того, что встречается в реальных магазинах...

[zyxer]

Импорт длится примерно 2 минуты, что весьма долго для такого файла.

Какое время для данного файла "не долго"?

После импорта сайт работает заметно медленнее даже на глазок. Показатели теперь примерно такие
memory peak usage: 19 МБ
page generation time: 0.3 seconds
то есть и используемая память и время выполнения запросов увеличились в полтора раза.

Для экономии времени выполнения и задумываются всякие средства по типу кэширования и точечная оптимизация конкретных мест, которые являются не оптимальными.

Подозреваю, что такая картина есть следствие как общей нерациональности CMS в плане экономичности ресурсов, о чем на форуме уже говорилось

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

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

И здесь тоже, поясните пожалуйста, что именно вы имеете ввиду?

[Vladzimir]

Ок. Вы как специалист, можете мне обьснить почему 70% времени генерации страницы занимает роутинг?

[zyxer]

Откуда эта цифра (как её замеряли)? И что именно вы считаете роутингом?

[korshunov]

Импорт длится примерно 2 минуты, что весьма долго для такого файла.

Какое время для данного файла "не долго"?

Сравниваю
И1. Импорт данного файла
И2. Импорт файла экспорта по умолчанию.

И1. файл объемом 100К содержит 800 товаров
И2. файл объемом 600К содержит 227 товаров

И1. идет примерно 2 минуты
И2. идет примерно 5 секунд.

И1. скорость обработки 7 товаров в секунду
И2. скорость обработки 40 товаров в секунду

То есть скорость работы И1 примерно в 6 раза ниже, чем в И2.
Это при том, что объем данных на один товар в И1 существенно меньше, чем в И2: товары в И1 не имеют ни картинок, ни свойств. И объем информации на один товар в И1 на порядок ниже, чем в И2: 0,1К против 3К.

Можете Вы ТОЧНО определить-объяснить причину столь существенной разницы?

Пока вы не скажите о каких нерациональностях вы говорите, мы их не сможем пофиксить. Сможем пофиксить только те, которые видим мы (что и делается практически в каждой версии).

В первом посте сказано:

Сопоставьте масштабы - файл импорта в 0.1M дает прибавку используемой памяти в 8M. И прибавку во времени выполнения запроса 0.1 сек - это еще хуже. Думаю, это не нормально.

Это главное в поднятой теме. А Вы на это никак не реагируете, предпочитая препираться по более мелким вопросам.
Можете Вы ТОЧНО определить причины столь неадекватных масштабов ?

[zyxer]

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

Можете Вы ТОЧНО определить-объяснить причину столь существенной разницы?

На данный момент нет, не исследовал досконально данный вопрос.

Добавлено спустя 9 минут 39 секунд:
Под фразой "укажите на нерациональность" я имею ввиду показать приблизительно так http://prntscr.com/ueygcc, где есть нерациональный кусок кода, и его более рациональный вариант (некоторые форумчане так делают и это приятно). Не, то что делаете вы, вообще обращая внимания на проблемы тоже хорошо, но было бы более продуктивно предлагать еще и их решение. Тем самым вы бы помогли проекту, но можно и обращать наше внимание на проблемы ожидая их решения.

[korshunov]

если у вас есть идеи улучшения, с удовольствием выслушаю.

В соседней теме сегодня выдвигал для Вас идею общую:

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

И там же намек на идею более частную и более конкретную:

поставлен вопрос о замере времени исполнения SQL запросов. Ответ ведущего разработчика: по умолчанию в окае такой ф-ции нет.
Как можно что-то делать по оптимизации запросов, если не владеть текущей статистикой их выполнения?

Если намек не понятен, то выскажу более прямо:
Просто НЕОБХОДИМО сначала создать инструмент (а может, и не один), для замеров времени выполнения SQL-запросов, чтобы на КАЖДОЙ странице, например, при добавлении спец параметра выводились все SQL-запросы с указанием потребленного ими времени.
А вот когда у Вас будет такой инструмент, тогда уже анализировать, где тормоза - в SQL-запросах или в другом месте...

Под фразой "укажите на нерациональность" я имею ввиду показать приблизительно так http://prntscr.com/ueygcc, где есть нерациональный кусок кода, и его более рациональный вариант

Это конечно, хорошо, когда Вам преподнесут на блюдечке с голубой каемочкой готовое решение, но обсуждаемая проблема не сводится к 5-10 строкам, она куда сложнее и масштабнее...

На данный момент нет, не исследовал досконально данный вопрос.

Еще могу подкинуть идею - исследовать его незамедлительно и написать тут о результатах.
Это же жуткое дело - импортировали файл 0.1M и получили прирост используемой памяти в 8M...

Добавлено спустя 13 часов 17 минут:

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

И здесь тоже, поясните пожалуйста, что именно вы имеете ввиду?

Пояснял уже:
viewtopic.php?p=4584#p4584

А потом было еще напоминание. Здесь
viewtopic.php?p=7165#p7165
было сказано

Еще один вопрос время от времени всплывает - нерациональная работа с категориями:
viewtopic.php?p=4582#p4582
поддержка заявила "но если предложите лучше - мы это рассмотрим". Тут же было предложен вариант, на который оная поддержка просто никак не среагировала. Это за почти полтора года..
В теории все у Вас идеально, а на практике - далеко не всегда даже ответа дождешься...

С момента напоминания прошло более полугода, а с начального сообщения подробностей о нерациональности - уже ДВА года. Какой-либо реакции на то и другое до сих пор не видно...

А по прошествии столь большого времени, Вы опять задаете тот же вопрос.
Похоже, это тактика такая - взять оппонента измором, повтором и забалтыванием темы, чтоб скорее отстал...

[zyxer]

соседней теме сегодня выдвигал для Вас идею общую:

korshunov писал(а):
я бы рекомендовал проанализировать причины текущих замедлений в работе, иначе это будет случайное тыкание, как у слепых котят.

И там же намек на идею более частную и более конкретную:

korshunov писал(а):
поставлен вопрос о замере времени исполнения SQL запросов. Ответ ведущего разработчика: по умолчанию в окае такой ф-ции нет.
Как можно что-то делать по оптимизации запросов, если не владеть текущей статистикой их выполнения?

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

Это конечно, хорошо, когда Вам преподнесут на блюдечке с голубой каемочкой готовое решение, но обсуждаемая проблема не сводится к 5-10 строкам, она куда сложнее и масштабнее...

Если вы не хотите/не можете предлагать решение, тогда ждите когда его решим мы или предложат другие...

Если намек не понятен, то выскажу более прямо:
Просто НЕОБХОДИМО сначала создать инструмент (а может, и не один), для замеров времени выполнения SQL-запросов, чтобы на КАЖДОЙ странице, например, при добавлении спец параметра выводились все SQL-запросы с указанием потребленного ими времени.
А вот когда у Вас будет такой инструмент, тогда уже анализировать, где тормоза - в SQL-запросах или в другом месте...

Нет НЕ НЕОБХОДИМО, зачем делать еще какие-то инструменты? Я же привел список инструментов, которые использую, можете их использовать и вы. По ним есть отличная документация, думаю сложности с ней не будет. Можете также поискать другие инструменты, которые уже готовы и их не нужно пилить.

Где "тормоза" (запросы которые нуждаются в дополнительных ускорениях) мы тоже знаем, только вот решения как их красиво исправить пока нет. Определённо это должен решать кэш (это не отменяет оптимизацию самих запросов, но оптимизация в определённый момент доходит до предела).

По поводу категорий, я ранее смотрел и мне по некоторым причинам этот вариант фикса не очень нравился. Если вы так настаиваете, я посмотрю еще раз, можно ли красиво сделать так, чтобы на фронт доставались только активные категории но ожидать что от этого будет какой-то заметный профит не стоит (хотя не исключаю что найдется проект у которого 100500 выключенных категорий, там возможно профит будет).

По категориям вы писали уже много раз "большие нерациональности" и подобное, проблема только в том что достаются выключенные категории на фронт или есть ещё что-то?

[Vladzimir]

Откуда эта цифра (как её замеряли)? И что именно вы считаете роутингом?

Xdebug. 75% Okay\Core\Router->run

[zyxer]

дело в том, что в это время входит и работа по созданию экземпляра контроллера, отработка всего что написано в контроллере и т.д. по сути при вызове run() отрабатывает весь этот код http://prntscr.com/uffm18, описанный в Okay\Core\Router. Эта ф-ция практически полностью сопровождает работу системы на фронте.

[Vladzimir]

дело в том, что в это время входит и работа по созданию экземпляра контроллера, отработка всего что написано в контроллере и т.д. по сути при вызове run() отрабатывает весь этот код http://prntscr.com/uffm18, описанный в Okay\Core\Router. Эта ф-ция практически полностью сопровождает работу системы на фронте.

Но что тогда в Okay\Core\Router->run делает 96% Bramus\Router\Router->run ?

[zyxer]

вы чуть не правильно смотрите стек вызовов. Вот как все происходит на самом деле http://prntscr.com/ufga6m. Видно что index.php работал 99%, далее видим что Core\Router работал 90% затем видим что далее на каждый метод процентов все меньше и меньше. Но все время работы дочерних методов прибавляется к родительскому.

[korshunov]

И "не владеть текущей статистикой их выполнения" это придумали вы, я же писал как мы их анализируем.

Вот в этом и вопрос.
Кому интересные Ваши общие фразы, что Вы используете такой-то инструмент?
Я-то предлагал дать ИНСТРУМЕНТ для анализа для ПОЛЬЗОВАТЕЛЯ. Чтоб он просто на кнопочку нажал, и получил результат.
А потом импортировал много товаров, еще раз нажал, и получил другие сведения. Чтоб мог сравнить и т.д.

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

По категориям вы писали уже много раз "большие нерациональности" и подобное, проблема только в том что достаются выключенные категории на фронт или есть ещё что-то?

Если импортировали файл 0.1M и получили прирост используемой памяти в 8M - Вам этой нерациональности мало?

Есть и еще. Хотите их узнать - посмотрите на SQL-запрос, которым добываются данные по категориям. По-моему, там нерациональности прямо в глаза бросаются.

можно ли красиво сделать так, чтобы на фронт доставались только активные категории

Не понимаю Ваших затруднений. По моему, в CMS сплошь и рядом в разных фильтрах формируются запросы по добавочным условиям. И если очень трудно добавить для фильтрации условие активности, то это скорее всего означает, что изначально что-то в системе спроектировано нерационально...

[zyxer]

И "не владеть текущей статистикой их выполнения" это придумали вы, я же писал как мы их анализируем.

Вот в этом и вопрос.
Кому интересные Ваши общие фразы, что Вы используете такой-то инструмент?
Я-то предлагал дать ИНСТРУМЕНТ для анализа для ПОЛЬЗОВАТЕЛЯ. Чтоб он просто на кнопочку нажал, и получил результат.
А потом импортировал много товаров, еще раз нажал, и получил другие сведения. Чтоб мог сравнить и т.д.

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

images.jpeg (9.26 КБ) 298 просмотров

я же написал что использую https://blackfire.io :) даже не знаю что вам еще сказать... Пользователю (менеджеру магазина) не нужен инструмент для анализа SQL запросов, а разработчику стыдно называть blackfire "такой-то инструмент", это достаточно мощный и известный инструмент. Посмотрите на него, вам может понравиться. И кстати на счет "Чтоб мог сравнить и т.д." там какраз есть возможность сравнения метрики )

Не понимаю Ваших затруднений. По моему, в CMS сплошь и рядом в разных фильтрах формируются запросы по добавочным условиям. И если очень трудно добавить для фильтрации условие активности, то это скорее всего означает, что изначально что-то в системе спроектировано нерационально...

Я же и говорю, что здесь основная проблема не в том, чтобы закешировать что-то, а в том, чтобы вовремя инвалидировать этот кэш.

[korshunov]

я же написал что использую https://blackfire.io :) даже не знаю что вам еще сказать...

Сказать хорошо бы что-то КОНКРЕТНОЕ, а не общие фразы.

Вот Я Вам конкретно в теме несколько раз задавал вопрос по поводу того, что при импорте файла 0.1M получился прирост используемой памяти в 8M.
Мое представление - это говорит о большой нерациональности CMS.
А Ваше точное мнение пока по конкретному факту пока не услышал.
Вот написали бы КОНКРЕТНО, что полезного дает "мощный и известный инструмент" по этому вопросу и может ли он как-то помочь устранить это безобразие...

[Vladzimir]

вы чуть не правильно смотрите стек вызовов. Вот как все происходит на самом деле http://prntscr.com/ufga6m. Видно что index.php работал 99%, далее видим что Core\Router работал 90% затем видим что далее на каждый метод процентов все меньше и меньше. Но все время работы дочерних методов прибавляется к родительскому.

Если смотреть абсолютные значения, ситуация кардинально не меняется.
Роутинг съедает большую часть времени.

[zyxer]

Вот написали бы КОНКРЕТНО, что полезного дает "мощный и известный инструмент" по этому вопросу и может ли он как-то помочь устранить это безобразие...

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

Если смотреть абсолютные значения, ситуация кардинально не меняется.
Роутинг съедает большую часть времени.

Что значит "абсолютные значения"? Говорю еще раз, если вы видите что метод Okay\Core\Router::run() работает 75% времени, это не значит что роутер работал 75% времени и остальная система работала 25%. Это означает что в замер времени метода Okay\Core\Router::run() входит все, что внутри него работает от первой до последней строчки метода (что логично). Но внутри этого метода располагается создание экземпляра контроллера вызов его метода (указанного в роуте) после вызова метода контроллера этот метод же должен отработать :) на что тоже тратиться время (не малый процент времени) но всё это время также и засчитывается как время отработки метода Okay\Core\Router::run(). Я же вам показал как процент времени делиться между методами в стеке вызовов https://prnt.sc/ufga6m.

[korshunov]

Вот написали бы КОНКРЕТНО, что полезного дает "мощный и известный инструмент" по этому вопросу и может ли он как-то помочь устранить это безобразие...

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

Ваше "Пока не почитаете" - некорректное.
Во-первых, сначала надо убедиться, что не прочитал.
Во-вторых, если прочитать все доки, то там вряд ли будет ответ на вопрос, что и как пользователь zyxer нашел полезного с помощью этого инструмента.
И вопросы никак не отпадут.

[Vladzimir]

Что значит "абсолютные значения"?

Вы сейчас на полном серьезе не понимаете значение слова "абсолютные значения"? Ок. Переведу - значния не в процентах, а в секундах.
И ваши картинки из какого-то там блекчтототам, тоже подтверждают что роутинг - основной потребитель времени выполнения.
Почему в список "тормозов" не попадает мускуль? Да потому что роутинг "доминирует".

[M@riwwwwww@]

Вы сейчас на полном серьезе не понимаете значение слова "абсолютные значения"? Ок. Переведу - значния не в процентах, а в секундах.
И ваши картинки из какого-то там блекчтототам, тоже подтверждают что роутинг - основной потребитель времени выполнения.
Почему в список "тормозов" не попадает мускуль? Да потому что роутинг "доминирует".

Разговор похож на переливание из пустого в порожнее.
Подскажите, что вы называете роутингом в данном случае.
- Процесс, который отвечает за определение обработчика для конкретной запрашиваемой страницы.
Или все таки
- Организация перехода по ссылкам и вызова в зависимости от url разных действий, отрисовка контента и пр.

Такое ощущение что говорите о первом а меряете второе...