В сентябре-октябре 2020 года мы подготовили и выпустили очередное обновление HighPer, но большинство наших пользователей его не заметило. Между тем это одна из самых масштабных переработок программного продукта за всю историю его существования. Изменены механизмы запуска и работы главных процессов HighPer – расчета выполнения KPI и бонусов/премий.
Предпосылкой для этих изменений стали результаты анализа работы HighPer на больших структурах. В последние годы у нас возросло количество крупных внедрений: ПриоВТБ, KazTransOil, ТДЛ Текстиль, Тульский патронный завод. Все это крупные организации. Количество сотрудников в одной базе часто превышает 500 человек. В целом программа итак справлялась с подобным объемом – она на это и рассчитана. Однако мы заметили некоторое снижение производительности и рост нагрузки на сервера при большом объеме расчетов в базе данных. Это было особенно чувствительно, когда показатели связывались между собой через формулы.
Попытка локальной оптимизации процесса расчетов незаметно привела нас к пересмотру всей внутренней логики работы HighPer. Итак, что же было сделано:
Оптимизирована логика регулярных расчетов. Программа в фоновом режиме с определенной периодичностью производит перерасчет базы данных, чтобы в архиве хранились актуальные введенным данным расчеты. Раньше запуск таких расчетов в фоновом режиме мог заметно снизить производительность сервера и ввести программу в «задумчивость». Теперь HighPer ведет учет изменений, внесенных в базу данных за время, прошедшее с запуска последнего перерасчета. При запуске фоновых процессов теперь программа работает только с теми данными, которые изменились и требуют новых расчетов. Нагрузка на сервер значительно снизилась, а быстродействие возросло.
Добавлены автоматические расчеты после импортов. С появлением API автоматический импорт для многих пользователей стал основным способом ввода данных. Объем ручного ввода данных по KPI непрерывно снижается. При этом по API может разово загружаться большой объем первичных данных. Чтобы база данных сразу содержала актуальные расчеты, теперь сразу после импорта автоматически запускается процедура необходимых расчетов. Все это обычно происходит в периоды низкой загрузки серверов и не заметно пользователям.
Большинство фоновых процессов перенесено в службу Windows. Ранее основную работу с базой данных выполняло веб-приложение, работающее на базе Microsft Internet Information Services (IIS). Это видимая часть программы, с которой работают пользователи. Но из-за некоторых особенностей IIS расписание запуска фоновых процессов могло сбиваться, расчеты могли запускаться в период активной работы пользователей с программой, что приводило к «задумчивости» приложения. Теперь мы перенесли большинство фоновых процессов в службы Windows, которые работают по своему расписанию и никак не зависят от действий пользователей и веб-приложения. В результате мы видим, что фоновые процессы теперь работают, как швейцарские часы. Нагрузка на сервера стала намного более равномерной. Попутно мы столкнулись с тем, что алгоритмы работы программы начали дублироваться в веб-приложении и в службах Windows. Чтобы избежать таких дублирований, мы вынуждены были вынести многие алгоритмы в отдельный модуль, который может запускаться как из одного места, так и из другого. В результате у нас получился отдельный сервис расчетов, который значительно повышает надежность и производительность программы, а также заметно упрощает ее дальнейшее развитие.
Перерасчет теперь не ограничен текущим периодом. Ранее перерасчет в фоновом режиме затрагивал только текущий период времени, чтобы как-то ограничить нагрузку на сервер. При этом часто на практике возникает ситуация, когда пользователи работают с данными прошлых периодов – вносят KPI за прошлый месяц или год. Такие изменения в фоновом режиме не обсчитывались. Теперь благодаря оптимизации логики регулярных расчетов (см. п. 1) мы включили в фоновые процессы пересчета все периоды, в которых внесены изменения. В результате сильно повысилась точность и оперативность расчетов. Особенно это заметно при большом количестве связанных между собой формулами показателях.
Оптимизирована загрузка отчетов. Ранее при запуске любого отчета перед его формированием запускался процесс расчета данных по текущему периоду. Теперь логика изменена и поставлена в зависимость от формируемого отчета. При запуске 4 отчетов процесс пересчета вообще не запускается – он там не нужен. Для остальных отчетов пересчет запускается более точно только для выбранных работников, KPI и периодов. В результате сильно сократилось среднее время формирования отчетов и повышена их точность.
Следствия всех перечисленных выше изменений: HighPer стал работать намного быстрее, стабильнее и точнее. При этом нагрузка на сервер снизилась и стала более равномерной. Теперь база на 1.000 пользователей при самых сложных расчетах работает также плавно и быстро, как и на 10 пользователей. Мы это отчетливо видим по своим серверам, на которых «крутится» несколько десятков экземпляров программы, включая довольно большие. А большинство пользователей ничего не заметило :)
Кроме описанных выше изменений оптимизации реализовано несколько доработок для профессиональной версии:
На очереди еще множество планов! Следите за обновлениями ;)
Предпосылкой для этих изменений стали результаты анализа работы HighPer на больших структурах. В последние годы у нас возросло количество крупных внедрений: ПриоВТБ, KazTransOil, ТДЛ Текстиль, Тульский патронный завод. Все это крупные организации. Количество сотрудников в одной базе часто превышает 500 человек. В целом программа итак справлялась с подобным объемом – она на это и рассчитана. Однако мы заметили некоторое снижение производительности и рост нагрузки на сервера при большом объеме расчетов в базе данных. Это было особенно чувствительно, когда показатели связывались между собой через формулы.
Попытка локальной оптимизации процесса расчетов незаметно привела нас к пересмотру всей внутренней логики работы HighPer. Итак, что же было сделано:
Оптимизирована логика регулярных расчетов. Программа в фоновом режиме с определенной периодичностью производит перерасчет базы данных, чтобы в архиве хранились актуальные введенным данным расчеты. Раньше запуск таких расчетов в фоновом режиме мог заметно снизить производительность сервера и ввести программу в «задумчивость». Теперь HighPer ведет учет изменений, внесенных в базу данных за время, прошедшее с запуска последнего перерасчета. При запуске фоновых процессов теперь программа работает только с теми данными, которые изменились и требуют новых расчетов. Нагрузка на сервер значительно снизилась, а быстродействие возросло.
Добавлены автоматические расчеты после импортов. С появлением API автоматический импорт для многих пользователей стал основным способом ввода данных. Объем ручного ввода данных по KPI непрерывно снижается. При этом по API может разово загружаться большой объем первичных данных. Чтобы база данных сразу содержала актуальные расчеты, теперь сразу после импорта автоматически запускается процедура необходимых расчетов. Все это обычно происходит в периоды низкой загрузки серверов и не заметно пользователям.
Большинство фоновых процессов перенесено в службу Windows. Ранее основную работу с базой данных выполняло веб-приложение, работающее на базе Microsft Internet Information Services (IIS). Это видимая часть программы, с которой работают пользователи. Но из-за некоторых особенностей IIS расписание запуска фоновых процессов могло сбиваться, расчеты могли запускаться в период активной работы пользователей с программой, что приводило к «задумчивости» приложения. Теперь мы перенесли большинство фоновых процессов в службы Windows, которые работают по своему расписанию и никак не зависят от действий пользователей и веб-приложения. В результате мы видим, что фоновые процессы теперь работают, как швейцарские часы. Нагрузка на сервера стала намного более равномерной. Попутно мы столкнулись с тем, что алгоритмы работы программы начали дублироваться в веб-приложении и в службах Windows. Чтобы избежать таких дублирований, мы вынуждены были вынести многие алгоритмы в отдельный модуль, который может запускаться как из одного места, так и из другого. В результате у нас получился отдельный сервис расчетов, который значительно повышает надежность и производительность программы, а также заметно упрощает ее дальнейшее развитие.
Перерасчет теперь не ограничен текущим периодом. Ранее перерасчет в фоновом режиме затрагивал только текущий период времени, чтобы как-то ограничить нагрузку на сервер. При этом часто на практике возникает ситуация, когда пользователи работают с данными прошлых периодов – вносят KPI за прошлый месяц или год. Такие изменения в фоновом режиме не обсчитывались. Теперь благодаря оптимизации логики регулярных расчетов (см. п. 1) мы включили в фоновые процессы пересчета все периоды, в которых внесены изменения. В результате сильно повысилась точность и оперативность расчетов. Особенно это заметно при большом количестве связанных между собой формулами показателях.
Оптимизирована загрузка отчетов. Ранее при запуске любого отчета перед его формированием запускался процесс расчета данных по текущему периоду. Теперь логика изменена и поставлена в зависимость от формируемого отчета. При запуске 4 отчетов процесс пересчета вообще не запускается – он там не нужен. Для остальных отчетов пересчет запускается более точно только для выбранных работников, KPI и периодов. В результате сильно сократилось среднее время формирования отчетов и повышена их точность.
Следствия всех перечисленных выше изменений: HighPer стал работать намного быстрее, стабильнее и точнее. При этом нагрузка на сервер снизилась и стала более равномерной. Теперь база на 1.000 пользователей при самых сложных расчетах работает также плавно и быстро, как и на 10 пользователей. Мы это отчетливо видим по своим серверам, на которых «крутится» несколько десятков экземпляров программы, включая довольно большие. А большинство пользователей ничего не заметило :)
Кроме описанных выше изменений оптимизации реализовано несколько доработок для профессиональной версии:
- В API-коннектор добавлена возможность получения данных в формате JSON. Теперь наш модуль интеграции соответствует всем современным стандартам. На собственной базе мы сразу же интегрировались с API Яндекс.метрики. Теперь наша карта сбалансированных показателей в автоматическом режиме получает абсолютно все данные, включая все элементы воронки продаж: количество посетителей сайта, объемы рекламного трафика, количество конверсий и т.д. Больше никакого ручного ввода данных!
- Оптимизирована экранная форма с выводом и редактированием фактов BSC. При ежедневной загрузке фактов по 40 показателям мы неожиданно столкнулись со снижением производительности приложения при отображении 2.500 записей на одной странице. Да и работать с таким массивом данных, честно говоря, совершенно не возможно. В результате мы перенесли просмотр и редактирование фактов по каждому показателю в отдельное всплывающее окно. Выглядит это примерно так: Факты можно добавлять и редактировать прямо в этом окне, как в обычной электронной таблице. Можно выбрать период отображения фактов, включая весь год. Если нашим пользователям такая форма в BSC понравится, то можно будет ее со временем распространить и на ввод данных по «обычным KPI».
- При формировании задания на загрузку данных в API-коннекторе появилась новая опция – «Загружать только при отсутствии ошибок». Мы привели в API в соответствие с логикой загрузки транспортных файлов CSV. Пользователь теперь сам выбирает, важна ему целостность загружаемой таблицы или можно проигнорировать ошибки в конкретных строках (записав ошибки в лог).
На очереди еще множество планов! Следите за обновлениями ;)
Поделиться этим материалом: