Какой совет вы можете мне дать для написания значимого теста?

Question

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

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

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

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

Answer 1

Ваш вопрос довольно широкий, поэтому, к сожалению, мой ответ тоже не будет очень конкретным.

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

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

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

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

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

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

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

Answer 2

Наиболее значимым тестом является измерение производительности вашего кода при повседневном использовании. Это, очевидно, даст вам самые реалистичные цифры.

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

<Ол>

Какие функции чаще всего используются?

Сколько данных передается?

Не принимай ничего. Если вы думаете, что «это будет быстро / медленно», не стоит на этом ставить. В 9 из 10 случаев вы ошибаетесь.

Создайте первую десятку для 1 + 2 и поработайте над этим.

Тем не менее: если вы замените старое оборудование новым, вы можете ожидать примерно на 10% более быстрого выполнения за каждый год, прошедший с момента покупки первого комплекта (если системы в остальном практически одинаковы).

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

Answer 6

Насколько я понимаю, существует два типа тестов, когда дело доходит до тестирования программного обеспечения.Во-первых, микротесты, когда вы пытаетесь оценить фрагмент кода изолированно или то, как система справляется с узко определенной рабочей нагрузкой.Сравните два алгоритма сортировки, написанные на Java.Сравните два веб-браузера, насколько быстро каждый из них может выполнить некоторую операцию манипулирования DOM.Во-вторых, существуют системные тесты (я только что придумал название), когда вы пытаетесь оценить программную систему в условиях реалистичной рабочей нагрузки.Сравните мой бэкэнд на основе Python, работающий на Google Compute Engine и на Amazon AWS.

Имея дело с Java и т. п., имейте в виду, что виртуальной машине необходимо прогреться, прежде чем она сможет обеспечить реалистичную производительность.Если вы измеряете время с помощью time команда, будет включено время запуска JVM.Вы почти всегда хотите либо игнорировать время запуска, либо отслеживать его отдельно.

Микробенчмаркинг

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

Сделайте много измерений и вычислите некоторую статистику.Среднее значение, медиана, стандартное отклонение, постройте диаграмму.Посмотрите на это и увидите, как сильно оно изменится.Вещи, которые могут повлиять на результат, включают паузы GC в виртуальной машине, масштабирование частоты ЦП, какой-либо другой процесс может запустить какую-либо фоновую задачу (например, сканирование на вирусы), ОС может решить переместить процесс на другое ядро ​​ЦП, если вы есть НУМА архитектуры, результаты будут еще более заметными.

В случае с микробенчмарками все это является проблемой.Уничтожьте все процессы, которые можете, прежде чем начать.Используйте библиотеку сравнительного анализа, которая может сделать часть этого за вас.Нравиться https://github.com/google/caliper и тому подобное.

Бенчмаркинг системы

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

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