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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Microbenchmarking

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

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

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

Системный бенчмаркинг

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

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

Answer 6

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

1. Какие функции чаще всего используются?
2. Сколько данных передается?
3. Не предполагайте ничего. Если вы думаете, «это будет быстро / медленно», не ставьте на это. В 9 из 10 случаев вы ошибаетесь.

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

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

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