|
| |
Число виртуальных пользователей - сущностный параметр теста производительностиИзо дня в день мы получаем много запросов от заказчиков на тестирование производительности веб-приложения и наша команда тщательно анализирует каждый такой запрос. В процессе работы по таким запросам мы обнаружили, что как правило, менеджеры проекта клиента сокращают расходы на нагрузочное тестирование веб приложений. Эта стратегия основана на сокращении числа виртуальных пользователей, увеличении времени простоя и, стало быть, увеличении объема транзакций на сервере. Хотя, в интересах клиента, мы стараемся сократить издержки по тестированию любым путем, мы отговариваем наших клиентов от подобного подхода к нагрузочному тестированию. При этом мы придерживаемся следующей логики. Каждый авторизованный пользователь потребляет ресурсы сервера. Лучший пример — это статус сессии, связанной с конкретным пользователем. Сведения о состоянии сессии хранится в памяти сервера, и остается там до момента входа пользователя в приложение. Только когда он выходит из системы, его сессия истекает, и сведения о сессии удаляются. Во многих приложениях большой объем потребляемой памяти на сервере объясняется этим и это неизбежно. Если увеличить число транзакций в секунду за счет уменьшения пользовательской нагрузки, будет авторизовано меньшее число пользователей, и, следовательно, объем потребляемой на сервере памяти уменьшится. Есть возможность того, что разработчики не в курсе проблем с потребляемой памятью на стадии тестирования, и начинают осознавать их только, когда клиенты жалуются на плохую производительность. Недооценка числа пользователей приводит к компромиссу по количеству одновременных подключений к серверу. Серверы приложений и веб-серверы могут иметь ограничения на число подключения и проблемы, связанные с этим, могут не проявиться на этапе тестирования. Более того, каждое подключение может потребовать подключения к базе данных, а сервер баз данных может иметь ограничение на число подключений. В идеале, база данных должна обрабатывать определенное количество одновременных операций чтения/записи во время выполнения и это бывает основной причиной многих неудач. В случае моделирования желаемой нагрузки с меньшим числом виртуальных пользователей перегрузки не происходит и значит, проблемы, связанные с этим, остаются не выявленными. На рабочем сервере, пользователи могут ждать дольше, пока пул соединений на разгрузится. Во время подобных тестов останутся также нераскрытыми проблемы связанные с неправильным распределением нагрузки. Под высокой нагрузкой, иногда требуются балансиры, чтобы перемещать сессии с одного сервера на другой. Путем экстраполяции и интерполяции числа виртуальных пользователей ситуацию не смоделировать, и значит, соответствующие вопросы не будут решены до их появления на рабочем сервере. Мы понимаем бюджетные проблемы, с которыми сталкиваются клиенты. Кроме того, другие производители инструментов нагрузочного тестирования берут непомерно много за лицензии, и эти затраты становятся непреодолимыми ограничениями на более высокие уровни нагрузки. Чтобы решить эту проблему, мы предлагаем облачную модель тестирования, когда клиент платят только за реальную нагрузку, и это минимальная цена. Эта модель позволяет варьировать такими наборами требований, которые требует бизнес, и таким образом получаются более значимые результаты. |







