Рекомендации по тестам производительности веб-приложений

Чтобы протестировать интерфейс, YSlow отлично подходит для получения статистики о том, как долго ваши страницы загружаются с точки зрения пользователя. Он разбивается на статистику для каждого конкретного HTTP-запроса, времени, которое он потребовал, и т. д. Получите его по адресу http://developer.yahoo.com/yslow/

Firebug, конечно, тоже необходим. Вы можете профилировать свой JS явно или в режиме реального времени, нажав кнопку профиля. Оптимизация там, где это необходимо, и просмотр времени выполнения всех ваших функций. Это изменило способ измерения производительности своего JS-кода. http://getfirebug.com/js.html

Используйте какой-нибудь инструмент для стресс-тестирования и нагрузочного тестирования. Если вы используете Java, обратите внимание на JMeter. Он предоставляет различные методы для проверки производительности вашего приложения. Вам следует сосредоточиться на:

• Время отклика: насколько быстро ваше приложение работает для обычных запросов. Протестируйте пример использования чтения / записи
• Нагрузочный тест: как ваше приложение ведет себя в периоды высокого трафика. Инструмент отправит несколько запросов (вы можете правильно настроить это) в течение определенного периода времени.
• Стресс тест: Ваше приложение может работать в течение длительного периода времени? Этот тест подтолкнет ваше приложение к пределу возможностей

Начните с этого, если вам интересно, есть и другие виды тестов.

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

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

Вы также, вероятно, захотите взглянуть на концепцию под названием HEAT (тестирование приложений во враждебной среде). На самом деле это показывает, что происходит, когда какая-то часть системы отключается. Система успешно деградирует? Это должен быть ключевой стандарт.

Мое одно действительно важное предложение - установить, что система должна делать, прежде чем проводить тестирование. Основная причина - подотчетность. Уговорите людей признать, что система должна что-то делать, а затем проверьте, верно ли это. Это ключевой момент, потому что люди сразу же увидят результаты, и это будет базовым критерием приемлемости.

«В частности, я должен определить производительность приложения ....»

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

1. Общее время отклика: «Под нагрузкой .... Общее время отклика сайта должно составлять менее x, y% времени ...»
2. Конкретное время отклика: «Под нагрузкой .... Обработка кредитной карты занимает менее z секунд, в% от времени ...»
3. Элементы емкости системы: "Под нагрузкой .... ЦП | Сеть | ОЗУ | ДИСК не должен превышать n% емкости ...."
4. Профиль нагрузки, который представляет собой сочетание количества пользователей и транзакций, в рамках которого собираются конкретные объективные показатели для определения производительности системы.

Вы заметите, что время отклика и другие показатели не являются абсолютными. Если взять страницу от руководителей производства «Шесть сигм», то стоимость перехода от 1 исключения на миллион к 1 исключению на миллиард является экстраординарной, а стоимость перехода к нулевому исключению обычно является непосильной стоимостью для средней организации. То, что считается приемлемым временем отклика для уникального приложения для вашей организации, скорее всего, будет полностью отличаться от высокопроизводительного предложения, которое представляет собой общедоступное приложение с выходом в Интернет. Для высококонкурентных решений ожидаемое время отклика в Интернете имеет тенденцию к диапазону 2-3 секунд, когда резко возрастает количество отказов пользователей. За последнее десятилетие этот показатель снизился с 8 секунд до 4 секунд, а теперь составляет 2-3 секунды. Некоторые приложения, такие как Facebook, из соображений конкуренции обеспечивают практически незаметное время отклика в диапазоне менее одной секунды. Если вы ищете жесткие стандарты, их просто не существует.

Что-то, что поможет вам понять, - это прочитать несколько отраслевых тестов стиля, формы, функции.

• Документ с эталонным тестом базы данных TPC-C
• Проектный документ для тестирования производительности SpecWeb2009

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

Выбирая инструмент, убедитесь, что у вас есть тот, который может

• Тренируйте свой интерфейс
• Сообщите о соответствии вашим требованиям
• У вас или вашей команды есть навыки, которые нужно использовать
• Вы можете пройти обучение и примете участие с благословения руководства

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

Удачи!