Журнал о системах электронного документооборота (СЭД)
Технологии проектирования и построения СЭД

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

  6 комментариев Добавить в закладки

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

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

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

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

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

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

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

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

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

Ещё материалы автора
Похожие записи
Комментарии (6)
Михаил Романов 16 сентября 2015 г. 16:20  
В качестве вывода я хотел бы сказать, что я не являюсь противником проведения нагрузочного тестирования.

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

Так?

Александр Сидоренков 16 сентября 2015 г. 16:41  

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

Alexey Ardamin 23 сентября 2015 г. 09:30  
Александр Сидоренков 16 сентября 2015 16:41
Михаил, не совсем так. Ваш вывод скорей дополняет мою статью. Я смотрел с одного ракурса - искусственные тесты далеки от жизни. Вы же предложили с другого и на мой взгляд очень правильно, т.к. тесты платформы, а не конечных решений нас еще более удаляют от реальной жизни.

Нагрузочное тестирование - это необходимость! Вопрос качества его подготовки. Проводить его необходимо в зависимости от масштаба задачи (новое решение, новое оборудование, смена версии системы, внедрение новой функциональности) с разной степенью подготовки и затрат и погрешности. К примеру если решение новое, необходимо провести нагрузочное даже на базовой версии с целью определиться с достаточность оборудования на планированный объем пользователей, погрешность будет большой, желательно учесть в сторону более мощного оборудования, так же может способствовать пониманию разработчика оптимизации стандарта. Следующим нагрузочным может быть на соответствующем продуктивном оборудовании с конечным софтом - цель оптимизация и проверка отказоустойчивости софта. И уже по возможности заключительное, затратное но максимально приближенного к реальности, после старта эксплуатации но до основного тиража - используя профайлы операций 10 - 20% пользователей симулировать нагрузку на весь объем тиража. (для того что бы не останавливать эксплуатацию системы, можно использовать оборудование кластера, или выходные дни). Таким образом есть все шансы приблизить результаты нагрузочного тестирования к максимально реальным.

 

 

Елена Питомцева 24 сентября 2015 г. 08:40  

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

Александр Сидоренков 24 сентября 2015 г. 16:08  

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

Сейчас обсуждают
Больше комментариев