Одни из самых частых вопросов при переходе на «1С» — как помочь системе справиться с высокими нагрузками и не потребуются ли при этом значительные вложения в оборудование? Ответить на них помогает нагрузочное тестирование. Об организации этого процесса рассказывает руководитель проектов по тестированию IBS Елена Маламут.
Сложности при работе с системой «1С» могут быть связаны как с особенностями самого решения, так и с недостатками корпоративной инфраструктуры. В одних случаях для обеспечения стабильной работы недостаточно ресурсов сервера, в других — дело в некоторых ограничениях платформы: например, если нужно проводить операции с более чем 100 тысячами строк.
Нередко о производительности системы задумываются, лишь когда пользователи уже столкнулись со сбоями. Проводится общий анализ ситуации: какие процессы выполнялись, с какими объемами данных, была ли фоновая нагрузка. Для этого используются журналы регистрации «1С» и простые замеры скорости ключевых операций. Далее корректируются тяжелые запросы и отключаются ненужные фоновые задачи. Обычно такие исправления носят точечный характер, поэтому неполадки могут повторно возникнуть при масштабировании решения или росте числа пользователей.
Более профессиональный подход — действовать проактивно и комплексно. Это особенно актуально при крупных внедрениях, а также когда речь идет о критичной для бизнеса системе, например, «1С:ERP», «1С:УХ», «1С:ЗУП» и «1С:Документооборот».
Подготовку к нагрузочным тестам стоит начинать со сбора требований: проанализировать статистику, определить наиболее важные операции и периоды пиковой нагрузки, оценить текущую инфраструктуру. После этого готовится тестовое окружение и проводится тестирование, в ходе которого моделируются реалистичные рабочие нагрузки. При таком подходе обнаруживаются не только причины конкретных сбоев, но и сопутствующие недостатки: блокировки СУБД, утечки памяти и т. д. При выявлении узких мест разрабатываются предложения по оптимизации.
Нагрузочное тестирование часто применяется в ситуации выбора между двумя системами, когда компания нуждается в объективных данных для принятия решения.
Сначала необходимо составить профиль тестирования. В него стоит включить операции, к которым пользователи обращаются регулярно, а также процессы, требующие особого внимания, такие как закрытие месяца. Для каждой операции на основе статистики за прошлый период выбирается интенсивность, при этом важно ориентироваться на пиковые часы, когда система была максимально нагружена. Далее разрабатываются скрипты, которые имитируют действия пользователей, после чего запускается тест с одинаковым профилем для двух систем. Так можно понять, какое из решений лучше выдерживает нагрузку: где оборудование работает с меньшей интенсивностью, а операции выполняются быстрее.
Аналогичным образом тестирование применяется при выборе базы данных. К примеру, оно поможет понять, стоит ли переплачивать за продвинутую версию или будет достаточно базовой.
Кроме того, без проведения нагрузочных тестов сложно рассчитать необходимые мощности оборудования. В нашей практике был кейс, когда пользователи заходили в систему «1С» через терминальный сервер, и нужно было оценить, достаточно ли имеющихся ресурсов для комфортной работы. Первые тесты показали критическую нагрузку на этот сервер: утилизация ресурсов (CPU/RAM) достигала 100%, при этом сервер «1С» не был загружен. После проведения полного цикла тестирования удалось определить достаточные мощности, чтобы предотвратить сбои.
Еще одно направление, где нагрузочное тестирование оказывается полезным, — повышение эффективности самой системы «1С».
Перед командой тестирования стояла задача: проверить проведение амортизации в крупном холдинге. При запуске процесса одновременно для нескольких юридических лиц проявилась одна из особенностей «1С:Предприятие 8.3» — когда число строк превышало 100 тысяч, платформа накладывала блокировку на весь регистр, вызывая ошибки и остановку параллельных процессов.
В качестве решения было предложено выделить организации с большим количеством основных средств в отдельную очередь для изолированного проведения амортизации. Это позволило обойтись без дополнительных доработок.
Работа с биллинговыми данными — сложный и критичный по срокам процесс. Как правило, загрузить их можно только после закрытия месяца, когда уже нужно формировать отчетность.
Тестирование позволяет найти ошибки, влияющие на скорость операции. В одном из проектов для их устранения потребовалась глубокая оптимизация: рефакторинг кода, изменение алгоритмов проверки и внедрение параллельной обработки данных. В результате удалось ускорить загрузку в разы и устранить риск срыва сроков.
Доработки типовой функциональности иногда приводят к непредсказуемому росту нагрузки на систему и значительному замедлению процессов. Например, перепроведение документов станет занимать в два раза больше времени, чем при использовании коробочного решения.
Исправить это можно за счет многопоточного режима обработки, когда большие массивы данных автоматически разбиваются на пакеты для параллельного выполнения. При этом важно найти оптимальное количество потоков. Рекомендуется начинать с небольшого числа и постепенно увеличивать его, отслеживая, как меняется нагрузка на систему и скорость выполнения задачи. Рост нагрузки на центральный процессор до 60–70% говорит о том, что дальше наращивать число потоков не стоит, ведь, помимо тестируемой операции, в системе будет еще стандартная работа пользователей. Также нужно остановиться, если после превышения определенного значения начала падать скорость самой операции.
При нагрузочном тестировании кастомизированной версии «1С:Управление холдингом» в крупной компании выяснилось, что формирование счетов-фактур на авансы происходит слишком медленно — обработка 100 тысяч авансов занимала более 48 часов.
Для ускорения процесса было предложено перевести операцию на многопоточную обработку. В результате удалось сократить время на выставление счетов-фактур в 10 раз по сравнению с изначальной версией.
Во время проведения в «1С» книг НДС возникала блокировка СУБД PostgreSQL, которая вызывала полную остановку системы на час. Примечательно, что сбой происходил только при параллельной работе пользователей в системе; в случае изолированного запуска операция выполнялась корректно.
Решение нашлось простое — выделить временное окно для автономного проведения книг НДС без другой фоновой активности. Весь процесс занимал около получаса, в остальное время пользователи могли спокойно работать без риска остановки всей системы. Этот пример показывает, что не все ситуации требуют доработок.
Нагрузочное тестирование помогает не только выбрать и оптимизировать ИТ-решение, но и настроить взаимодействие между системами.
В одном из проектов команда столкнулась с недостаточной скоростью интеграционного обмена между решениями «1С». Для поиска причины пришлось провести нагрузочное тестирование в двух режимах — работа систем совместно и по отдельности, чтобы оценить предельную пропускную способность каждой из них. Во втором случае применялась специальная заглушка, которая отдавала данные с любой заданной быстротой и не была узким местом. Анализ показал, что одна из систем готова принимать и обрабатывать данные на высокой скорости, а другая не успевает отдавать их так же быстро. С помощью доработок удалось это исправить, производительность обмена выровнялась.
В другом проекте входящая интеграция приводила к блокировке справочника «1С». Нагрузочное тестирование показало крайне низкую производительность системы: в каждый момент времени в справочник записывалось только одно значение, что делало невозможным параллельную обработку информации. Причем на этапе функционального тестирования эта особенность не проявлялась из-за использования небольшого объема данных. Как оказалось, сбой связан с ошибкой в коде. Разработчик прописал блокировку всего справочника при поступлении новой информации вместо блокировки изменяемого элемента. После внесения исправлений скорость операций улучшилась.
Еще один интеграционный кейс касался синхронного и асинхронного обмена данными. В системе «1С» был установлен тайм-аут в пять минут при поступлении большого объема информации, чтобы программа успевала получить и обработать все данные. Однако на практике операция не укладывалась в заданное время, и после ожидания пользователь все равно получал ошибку. Замена синхронной интеграции, при которой приходилось ждать получения всей информации, на асинхронную, а также добавление механизма постраничного вывода для крупных выборок данных помогли решить эту ситуацию. Теперь пользователи могут работать, например, с первыми ста строками, пока постепенно загружаются остальные. Система перестала зависать и завершает операции в срок.
Представленные кейсы доказывают, что нагрузочное тестирование — это гарантия устойчивости и производительности систем «1С» на всех этапах жизненного цикла.