Продумка 8. Нагрузочное тестирование – это миф!

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

Сначала начнем с практики, подтверждающей мое утверждение, а потом порассуждаем почему так получилось. Практика моя такова, что в реальной жизни и российские, и зарубежные СЭД становятся неторопливыми при существенно более низких нагрузках (в разы меньших!!!), чем те, которые были радостно преподнесены производителем СЭД после проведения нагрузочного тестирования. И это происходит практически с любой представленной на рынке системой!

Рисунок 1. Индикатор при долгой загрузке данных.

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

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

• Тестирование проводится при монопольном использовании ресурсов серверов и сети. В жизни же в одной сети работает и СЭД, и IP-телефония, и видеоконференция проводится, и другие системы работают - все это включается/выключается неравномерно… Если проводить аналогии, то это как гулять по пустому городу или идти по нему в обычный рабочий день с его пробками, толпами людей.
• Состав тестовых данных в базе при нагрузочном тестировании обычно близок к идеальному – данные очень однородны, все индексы «свежие», нет «мусорных данных» (всякие логи и прочее), очень маленькие или даже пустые сервисные таблицы (таблица секьюрити, таблица пользователей, таблица контрагентов и пр.). В итоге очень высокая консистентность базы данных в десятки раз увеличивает ее производительность по сравнению с реальной базой такого же размера.
• В реальной системе в отличие от искусственно наполненной среди большого количества  активных бизнес-процессов (зачастую десятков или даже сотен тысяч) найдется несколько, которые «лагают» и дополнительно сильно нагружают систему.
• … и… еще множество подобных «случаев», которые мешают работе системы в реальной жизни, но не эмулируются и не воспроизводятся при нагрузочном тестировании.

Так же оценивая скорость работы системы нам важно выявить не столько механистические параметры (загрузка ЦП, нагрузка на сеть и т.п.), сколько понять уровень комфорта для пользователя при работе с системой. Нагрузочное тестирование редко в этом дает объективные данные. Точнее после нагрузочного тестирования мы в общем понимаем, что система выдержала определенные нагрузки (хотя это зачастую и так бывает понятно исходя из архитектуры системы), но оно нам не даст реальной картины комфортности работы с ней пользователей. Эмуляция открытия карточки, файла или вывода на экран списка документов не отражает то как это все будет выглядеть в реальной жизни.

В качестве вывода я хотел бы сказать, что я не являюсь противником проведения нагрузочного тестирования. Однако призываю очень аккуратно относиться к его результатам. Скажем так – система, которая успешно прошла нагрузочное тестирование на 1000 пользователей предпочтительней системы, которая подобного тестирования не проходила. При этом успешный тест на 1000 пользователей не гарантирует, что в реальной работе такого количества пользователей скорость системы будет комфортна для них.

Оригинал статьи расположен по адресу: https://www.idoc.ru/index.php/produmki
Подробнее