[15665] Работа с отчетами в версии 3.59 значительно замедлилась

Заметил, что последние версии 3.58 и 3.59 стали медленнее работать с отчётами – как с формированием, так и в редакторе шаблонов.

Поэтому провел тест. Сравнил время исполнения типичных операций в +/-похожих системах разных версий ЛЭРС Учёт. Результат подтвердил мои ощущения: некоторые операции стали выполняться на два порядка медленнее.

Подробности. Сравнил три системы:

Первая: ЛЭРС Учёт 3.56.3
• Объектов: 192
• Размер базы: 6457 Мб
• Возраст системы: более 10 лет
• Сеансов опроса за 29.01: 2671. Большая часть объектов опрашивается 1 раз в час.


Средняя загрузка памяти во время работы ЛЭРСа

Вторая: 3.59.7
• Объектов: 554
• Размер базы: 750 Мб
• Возраст системы: новая, растёт. База данных на другом сервере.
• Сеансов опроса за 29.01: 507. Большая часть – 1 раз в сутки.


Средняя загрузка памяти во время работы ЛЭРСа

Третья 3.59.7
Третья: 3.59.7
• Объектов: 332
• Размер базы: 4145 Мб
• Возраст системы: более 3 лет
• Сеансов опроса за 29.01: 6887. Четверть объектов опрашивается 1 раз в 15 минут, половина – 1 раз в час, остальные (CSD) – 1 раз в сутки, но в случае ошибок – повторные опросы каждый час.


Средняя загрузка памяти во время работы ЛЭРСа

Сравнивал копию системного отчёта для объекта без изменений: “Ведомости параметров для систем: теплоснабжение, ГВС, ХВС, электроснабжение, газоснабжение”.

Результаты сравнения:

Параметр для сравнения Первая Вторая Третья
Версия ЛЭРС Учет 3.56.3 3.59.7 3.59.7
Открытие шаблона отчета на редактирование 3 сек 1 мин 38 сек 1 мин 45 сек
Фильтрация доступных полей данных по слову “Serail” 5 сек 2 мин 15 сек 3 мин 30 сек
Формирование отчета 2 сек 16 сек 23 сек

Хочу увидеть комментарии результатов и может есть способ вернуть прежную скорость работы с отчетами и системам с 3.59.7

Это не совсем точное сравнение. Например, у вас на двух Серверах с 3.5.7 может быть задан расчет данных по точкам, а на Сервере с 3.56.3 нет. Также могут быть другие отличия, которые существенно влияют на производительность вне зависимости от версии.
Уточните хотя бы характеристики компьютера в каждом случае из описанных.

Я не понимаю, что именно это значит.

Я провёл тестирование, скорее для себя, чтобы подтвердить свои ощущения. Редактирование шаблонов — вещь нечастая, и я не сразу понял, что меня начало раздражать медленная работа с отчётами.

Я не буду спорить, что не совсем корректное сравнение для определения размера изменения быстродействия работы с отчётами. Это не более чем индикатор — изменилось ли быстродействие.

И теперь я уверен — изменилось, и сильно. В цифрах различие составляет два порядка. На третьем сервере десятки отчётов, сделанных на нём же, в терминальном режиме, при изготовлении шаблона активно используется фильтрация полей по маске (3 строчка в сревнении). Сейчас её использование на тех шаблонах, которые реально используются, занимает более 5 минут.

Мне пришлось вернуться к практике редактирования шаблонов на серверах с версиями 3.54-3.56, так как на более новых версиях это не работает: открытие шаблона дольше минуты — это не работа. А формирование отчётов всё больше перекладывается на автоматические рассылки.

Сегодня обновил ещё один сервер с версии 3.55 до 3.59. Все тесты не проводил. Но до обновления шаблон открывался 3-5 секунд, а после обновления — 29 секунд.

Основные параметры компьютеров приведены на скриншотах.

Если вам зачем-то нужны характеристики серверов — пришлю, отчеты. Но мне кажется, вы ищете не там. Не нужно искать недостатки в моих тестах, как я уже указал, — это не более чем индикатор. У меня нет времени проводить корректные тесты. Такие тесты вы можете провести сами и более строго.

Ну, или дайте рекомендации, как настроить сервера с 58-й и 59-й версиями чтобы редактирование и формирование отчётов заработало быстрее.

Речь идет о настройках Расчёт и хранение точки учета.

Мы так же провели у себя ряд тестов, основываясь на вашем комментарии. К сожалению не можем подтвердить описываемую вами ситуацию. Мы протестировали скорость выполнения по каждому из описанных пунктов на локальном тестовом Сервере с маленькой БД и на боевом Сервере my.lers.ru с БД более 36Гб. Во всех случаях открытие шаблона и формирование отчета при первоначальном выполнении после запуска Рабочего места оператора занимало не более 10 секунд, при повторных открытие занимало 2-3 секунды, формирование примерно 1 секунду (отчет за месяц). Поиск указанной фразы в списке полей после окончания ввода всегда примерно 1-2 секунды.

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

В целом приложенные вами результаты сложно оценивать, так как это разные Сервера, у которых разные настройки. Такой анализ нельзя назвать объективным.
Приложите, пожалуйста, БД от Сервера с версией 3.56.3 по первой системе из представленных вами. Попробуем провести ряд тестов на этой БД с поочередно в версиях непосредственно 3.56.3 и в 3.59.7, и сравним результаты.

А почему не вторую или третью? Раз вы не видите ухудшения быстродействия в версии 3.59.7 у себя, то первая тоже не покажет ухудшения. Может, всё-таки вторую или третью?

Мы хотим проверить работу базы сначала в версии 3.56.3, чтобы проверить скорость выполнения указанных вами действий в ней на вашей БД, после чего обновиться до версии 3.59.7 и проверить скорость выполнения в ней, сравнив между собой результаты. Вторая и третья системы уже обновлены до версии 3.59.7 и их работу в версии 3.56.3 проверить не получится. Если у вас есть резервная копия базы по второй или третьей системе с версией 3.56.3, можете предоставить ее.

ссылку на базу отправил на support@lers.ru

Мы проанализировали ситуацию на тестовом Сервере. Непосредственно описываемые вами задержки в 2-3 минуты не подтвердились. Приведу результаты наших наблюдений:

Выполняемая операция Версия 3.56.3 Версия 3.60.0
Формирование отчета (первый запуск / последующие запуски) 15 сек / 3 сек 21 сек / 7 сек
Открытие отчетной формы в редакторе 10 сек 23 сек
Фильтрация в списке полей Редактора отчетных форм по слову “Serial” (первый запуск / последующие запуски) 5 сек / 2 сек 7 сек / 4 сек

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

Стоит отметить, что время выполнения все таки несколько увеличилось, но в первую очередь это связано с работой внешних компонентов, на основе которых разработаны и Редактор отчетов ЛЭРС УЧЕТ, и в целом их формирование. На данные компоненты мы повлиять никак не можем, так как не являемся их разработчиками.

Т.к. я то писал про 3.59.7, то выводов пока сделать нельзя. Видимо подожду, а потом снова задам вопрос.

Настройки тестовой машины самые стандартные. Никаких “особенных” настроек у нее нет. Мы установили на чистую машину версию 3.56.3, протестировали выполнение рассматриваемых операций в ней, после чего обновили до версии 3.60.0 и также протестировали.
Версия 3.59.7 содержит явно меньше изменений по сравнению с 3.60.0, поэтому нагрузка от 3.60.0 теоретически выше. При этом даже в этой версии выполнение рассматриваемых операций занимает значительно меньше времени, чем заявлено вами.

Отлично. Тогда опустим версии и вопрос все равно актуальный

Что влияет на скорость, работы с отчетами?

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

т.е. вам прислать одну из баз, где медленная работа с отчами. Так?

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

Не так часто приходится пользоваться редактором отчётов, но вот вчера нужно было изменить одно вычисляемое поле в отчётной форме и это стало ужасно медленно работать.
На ввод одного символа в редактор выражений требуется от 3 до 5 секунд.
Я не уверен что проблема связана с этой темой, но я готов предоставить необходимую информацию для диагностики.
Версия: 3.59.7

Причина этой темы именно такое поведение.

Описываемая вами ситуация обсуждалась в другой теме [15494] Отчетная форма - долгий отклик и зависание. Как видно из нее, ошибка была исправлена в 3.60.0. Попробуйте обновиться до текущей версии и проверьте возникновение задержек при редактировании в ней.

Сообщение:

не соответствует действительности. В текущей теме проблема задержек при вводе символов в редакторе выражений не обсуждалась.

Я отправил на support@lers.ru архив с базой третьего сервера.

Для проверки быстродействия, в том числе, стоит взять отчёты не системные, которые редактировались последними.

Повеселили :rofl:

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

Вы меня сильно подловили :rofl:

А если серьёзно, то задержка в 2-5 секунд при вводе/выделении в окне настройки вычисляемого поля, а также при открытии списка, была одной из причин.

Но для тестирования было проще взять системный отчёт и проверять с ним на разных серверах. В отчёте на базе системного задержки меньше. Их сложнее измерять. Я вам показал только те параметры, которые, на мой взгляд, хорошо иллюстрировали картину и были легко воспроизводимы.

Мы проанализировали ситуацию по последней присланной БД в версии. Ситуация в той мере, в какой описали ее вы, у нас не воспроизводится. Показатели практически идентичны предыдущим замерам.

Сами задержки возникают только в отчете ведомости именно по объекту, так как в нем очень большое количество полей. Например, в отчетной форме ведомости полей по точке учета полей в 20 раз меньше.

Все, что в данном случае можно сделать с нашей стороны, это уменьшить количество полей. Единственное, де это возможно сделать это поля по секциям. В отчет ведомости по объекту грузятся поля сразу по 10 секциям, но из них используется чаще всего 1-2.

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

Все проблемы были именно с пользовательскими отчетами - ведомостями параметров…

Что именно вы называете “полями”?

Чтобы мне не экспериментировать, что именно влияет на быстродействие работы с отчетом: количество вычисляемых полей; количество точек учета, доступных для данного отчета или какие-то другие параметры?