Оценка максимума одновременно работающих в программе 1С пользователей.
Отчет строится, основываясь на данных журнала регистрации.
Может пригодиться для оценки требуемого количества лицензий.
Отчет строится, основываясь на данных журнала регистрации.
Может пригодиться для оценки требуемого количества лицензий.
Внешний отчет, позволяющий оценить по журналу регистрации количество одновременно работающих в 1С пользователей.
Принцип расчета прост: на каждый вход в программу +1, на каждый выход — минус 1. П процессе расчета фиксируются максимумы на каждый шаг периода (день или час).
Из расчета исключаются фоновые задания и т.п. — только толстый, тонкий и веб клиенты.
Для разных дат в настройке разбивка идет по дням. Если отчет формируется за день, разбивка будет почасовая.
Отчет выделяет типы клиентов:
- 1CV8 – толстый клиент,
- 1CV8C – тонкий клиент,
- WebClient – Доступ через веб (посредством браузера или клиента 1С)
Работает как в управляемом режиме, так и в обычном.
P.S. За основу была взята обработка //infostart.ru/public/171729/, показавшая, что задача эта достаточно легко решаема.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Пока не скачивал, т.к. у меня есть аналогичный отчёт. Однако если не трудно, хочу уточнить некоторые вопросы, возникшие по ходу своей разработки:
— «принцип расчёта прост: на каждый вход в программу +1, на каждый выход — минус 1«. Сбрасывается ли когда-нибудь в ноль рассчитанное количество? Если нет, то из-за наличия записей «Start» без записей «Finish» значение количества пользователей будет всё время увеличиваться. Я сбрасываю в 0 в начале каждого дня, и то в течение дня появляются старты без финишей, которые искажают статистику за день. Да и к тому же при таком подходе не учитываются непрерывные переходящие из одного дня в другой сессии… Вы как-то решали эту проблему?
— какой вариант фильтрации событий используется — во время «ВыгрузитьЖурналРегистрации» или уже потом, на уровне СКД? проводились ли тесты быстродействия разных вариантов? у меня в некоторых случаях быстрее было выгрузить журнал без (некоторых) фильтров, а нужный отбор настроить через отбор СКД.
(1) Alias, прошу прощения за задержку — пока проблемы со временем. Чуть позже отпишусь подробно.
(1) Alias, отвечаю:
— «Сбрасывается ли когда-нибудь в ноль рассчитанное количество»
При анализе первого периода игнорируются все выходы, пока не зафиксируется вход. Это с одной стороны создает некоторую погрешность, с другой стороны это защита от ухода в ноль.
При переходе на следующий шаг сбрасывается максимум. Текущее же количество для ьчасовых шагов продолжает отслеживаться. Для дневных же шагов сбрасывается и текущий счетчик.
Учет ведется по каждому из трех видов клиентов. Прочие сессии игнорируются.
Можно поработать над уменьшением погрешности, но не думаю что это сильно изменит общую картину, особенно в долгосрочной перспективе.
Для оценки же потребностей в лицензиях, имхо, этого достаточно, т.к. логично взятьзапас в 10% или более.
— «какой вариант фильтрации событий используется»
Фильрация выполняется сразу же.
Кроме отбора по периоду:
Показать
Быстродействие оказалось удовлетворительным, поэтому вопросом ускорения не озадачивался.
В ЗУП квартал формируется за 30 секунд.
Возможно можно его еще разогнать.
PS: Есть недоработка в обычной форме. Не смог быстро передать даты с форму в СКД так, чтобы в макете в параметрах отобразились именно они, а не текущая дата.
А по времени был ограничен, поэтому решил время на этом не терять.
(3) Спасибо за уточнение… с Вашего позволения, дописал-таки свой вариант, избавленный от необходимости обнулять счётчик.
(3)
А какое среднее количество записей в журнале регистрации за сутки? Отчет подойдет для баз с небольшим количеством активных пользователей.
Универсальный вариант — .