Как выполнить тестирование производительности и масштабируемости без четких требований?

Question

Есть идеи, как провести тестирование производительности и масштабируемости, если не определены четкие требования к производительности?

Подробнее о моей заявке.

Приложение состоит из 3 компонентов. Один компонент может работать только в Linux, два других компонента являются программами Java, поэтому они могут работать в Linux / Windows / Mac ... 3 компонента могут быть развернуты в одном блоке, или каждый компонент может быть развернут в одном блоке. Развертывание очень гибкое. Компонент только для Linux будет захватывать необработанные пакеты TCP / IP по сети, затем один Java-компонент получит эти необработанные данные и соберет их в данные, которые потребуются конечным пользователям, и выведет их на жесткий диск в виде файлов данных. Последний компонент Java будет загружать данные из файлов данных в мою базу данных в пакетном режиме.

Answer 1

В отсутствие требований типа «должен иметь возможность выполнять X итераций в течение Y секунд ...», как насчет таких вещей:

• Требуется ли вдвое больше времени, чтобы удвоить размер набора данных? (да = хорошо)
• Требуется ли в 10 раз больше времени, в два раза превышающего размер набора данных? (да = плохо)
• Связан ли он с процессором?
• Связано ли оно с ОЗУ (например, много операций обмена виртуальной памятью)?
• Связан ли он с диском?
• Существует ли определенный размер набора данных, при котором производительность внезапно падает с обрыва?

Answer 2

Удивительно, но именно так начинается большинство тестов производительности и масштабируемости.

Вы можете четко выполнять тестирование без критериев, вы просто определяете тесты и измеряете результаты. Я думаю, что ваш вопрос больше в строках «как я могу установить критерии прохождения теста без требований к производительности». На самом деле это вовсе не редкость. Многие новые проекты не имеют четких критериев. Неофициально это было бы что-то вроде «если он не может сделать X в секунду, мы потерпели неудачу». Но как только вы прошли X в секунду (и вам лучше сделать!), X является критерием «прохождения»? Обычно нет, что происходит, когда вы устанавливаете новую базовую линию, и ваши тесты производительности защищают от регрессии: вы сравниваете свои текущие числа с лучшими, которые вы получили, и решаете, является ли новая сборка «приемлемой» в качестве этапа проверки сборки (обычно orgs соглашается) при допустимых значениях 70-80%, откройте ошибки перфорирования и убедитесь, что к моменту поставки вы вернетесь к 90-95% или 100% +. Таким образом, в основном тесты производительности сами становятся их собственным требованием.

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

Answer 3

Некоторые определения / предположения:

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

Масштабируемость = сколько пиковых одновременных пользователей может обработать приложение.

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

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

1. Хорошие модели использования того, как пользователи будут использовать ваш сайт и / или приложение. Это может быть легко, если приложение уже используется, но это может быть чрезвычайно сложно, если вы запускаете что-то новое, например, приложение Facebook.

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

2. Инструменты. У вас должны быть скрипты и инструменты тестирования производительности, которые могут оправдать сценарии, определенные на шаге 1, с числом ожидаемых пользователей на шаге 1. (Это может быть довольно дорого)

3. Окружающая среда. Вам понадобится производственная среда, которая изолирована, чтобы ваши тесты могли давать воспроизводимые результаты. (Это также может быть очень дорого.)

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

Как правило, в большинстве проектов есть поле для «тестирования производительности», которое им необходимо отметить из-за какого-то прошлого сбоя, однако они никогда не планируют и не планируют делать это правильно. Обычно я рекомендую делать бюджет для проверки масштабируемости или экономить свои деньги и вообще не делать этого. Попытка сделать это наполовину дешево - пустая трата времени.

Однако любой хороший разработчик должен иметь возможность проводить тестирование производительности на своей локальной машине и получать некоторые хорошие преимущества.

Answer 4

Если «требования к производительности не определены», то зачем вы это тестируете?

Если определено требование к производительности, но оно «расплывчато», можете ли вы указать, каким образом оно расплывчато, чтобы мы могли лучше вам помочь?

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

Answer 5

Определите свои собственные. Возьмите инициативу в свои руки и опишите цели производительности.

Чтобы ответить лучше, нам нужно больше узнать о вашем проекте.

Answer 6

Хотя четкие цели производительности и масштабируемости не определены, мы можем использовать общее описание трех компонентов, которые вы упомянули, для достижения общих целей производительности / масштабируемости.

1. Компонент 1: кажется, что он связан с сетевым вводом / выводом, поэтому вы можете использовать любые доступные имитаторы сетевой нагрузки для генерации различной рабочей нагрузки для насыщения канала. Масштабируемость может быть измерена путем изменения рабочей нагрузки (10 МБ, 100 МБ, 1000 МБ линии связи) и измерения времени отклика или, более точно, задержки, связанной с получением необработанных данных. Вы также можете измерить рабочий набор поля ссылок, чтобы получить реалистичное представление о ваших требованиях к серверу (сколько дополнительной памяти необходимо для получения X дополнительной рабочей нагрузки пакетов, и т. Д.)

2. Компонент 2: Этот компонент состоит из 2 частей: части, связанной с вводом / выводом (получение данных от компонента 1), и части, связанной с процессором (сборка пакетов), вы можете посмотреть на проблему в целом, убедитесь, что ваша ссылка насыщена, когда вы хотите измерить часть, связанную с процессором, если это многопоточный компонент, вы можете искать способы улучшить внешний вид, если вы не получаете 100% загрузки процессора, и вы можете измерить время, необходимое для Сообщения сборки X, из этого вы можете рассчитать среднее время ожидания для обработки сообщения, которое можно использовать позже для определения общей характеристики производительности вашей системы и предоставления SLA для ваших пользователей (вы гарантируете время ответа в течение X миллисекунд например).

3. Компонент 3: полностью привязан к вводу / выводу и зависит как от пропускной способности вашего жесткого диска, так и от используемого вами сервера баз данных, однако вы можете измерить, насколько насыщен дисковый ввод / вывод для оптимизации пропускной способности сколько подсчетов ввода / вывода требуется для чтения X МБ данных и улучшения этих параметров.

Надеюсь, это поможет. Спасибо

Answer 7

Способ, которым я обычно подхожу к таким проблемам, заключается в том, чтобы просто получить реальную или смоделированную реалистичную нагрузку и заставить программу работать как можно быстрее и в разумных пределах. Затем, если он не справляется с нагрузкой, мне нужно подумать о более быстром оборудовании, параллельном выполнении части работы и т. Д.

Настройка производительности состоит из двух частей.

Часть 1 - это синхронная часть, где я настраиваю каждый «поток» под реалистичной нагрузкой, пока в действительно не останется места для улучшения .

Часть 2 - это асинхронная часть, и это тяжелая работа, но ее необходимо выполнить. Для каждого «потока» я извлекаю файл журнала с отметкой времени, когда каждое отправленное сообщение, каждое полученное сообщение и когда обрабатывается каждое полученное сообщение. Я объединяю эти журналы в общий график событий. Затем я прохожу все это или случайно выбранные части и отслеживаю поток сообщений между процессами. Я хочу определить для каждой последовательности сообщений, какова ее цель (т. Е. Действительно ли это необходимо), и есть ли задержки между временем получения и временем обработки, и если да, то почему.

Я обнаружил, что таким образом я могу «вырезать жир», и асинхронные процессы могут выполняться очень быстро.

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

Answer 8

Краткий ответ: не делай этого!

Чтобы получить (лучшее) определение, напишите концепцию теста производительности, которую вы можете обсудить с экспертами, которые должны определить требования.

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

Для всех тех, кто читал последнюю книгу Тома ДеМаркоса («Адреналин наркоманы ...»): это образец для бродяги. Большинство людей, которые не хотят писать какие-либо спецификации с нуля, без колебаний оставят отзыв о вашем документе. Поскольку вам нужно несколько раз угадать, когда пишете свою версию, вам нужно подготовиться к тому, чтобы над вами смеялись при просмотре. Но, по крайней мере, у вас будет лучшая информация.

Answer 9

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

Чтобы проверить масштабируемость (при условии, что вы тестируете программу / веб-сайт): Создайте много пользователей и данных и проверьте, могут ли ваша система и база данных справиться с этим. MyISAM типа таблицы в MySQL может выполнить свою работу.

Для проверки производительности: Оптимизируйте коды, проверяйте их при медленном интернет-соединении и т. Д.

Answer 10

полагайтесь на инструменты (на ум приходит fxcop) полагаться на здравый смысл