Рекомендации по тестам производительности веб-приложений - PullRequest
7 голосов
/ 03 сентября 2008

Я собираюсь начать тестирование веб-приложения для интрасети. В частности, я должен определить производительность приложения.

Пожалуйста, кто-нибудь может предложить формальные / неформальные стандарты того, как я могу оценивать производительность приложения.

Ответы [ 4 ]

8 голосов
/ 03 сентября 2008

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

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

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

3 голосов
/ 29 сентября 2011

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

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

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

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

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

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

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

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

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

Удачи!

3 голосов
/ 03 сентября 2008

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

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

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

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

3 голосов
/ 03 сентября 2008

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

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

...