Наверх

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

Архив
Время чтения: 4 минуты
5
Продумка 8. Нагрузочное тестирование – это миф!

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

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

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

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

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

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

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

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

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

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

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 5

Михаил Романов 16 сентября 2015
В качестве вывода я хотел бы сказать, что я не являюсь противником проведения нагрузочного тестирования.

Ну, из вашей статьи, Александр, логически следует вывод, что, как минимум, тестировать нужно не платформу, а конечное решение.

Так?

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

А ведь как красиво все звучит в теории! :)

Елена Питомцева 24 сентября 2015

Александр, Alexey Ardamin - практик, опыта ему не занимать, так что это не теория, а многократно проверенный постулат. Значит лучше обсуждать отличия "правильного" нагрузочного тестирования от "мифического".

Ну написано же правда красиво, хоть в учебники вставляй! (без иронии)

Чтобы прокомментировать, или зарегистрируйтесь