Разработка сравнительных тестов производительности библиотеки - PullRequest
6 голосов
/ 08 сентября 2010

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

Что мне нужно сделать, чтобы продемонстрировать достоверность в тестах? Как мне составить тесты, чтобы они были респектабельными?

Меня также интересуют любые предложения по фактическому оформлению тестов. Способы загрузки данных без влияния на тесты (принцип неопределенности Гейзенберга) или способы мониторинга ... и т. Д.

Ответы [ 3 ]

3 голосов
/ 18 сентября 2010

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

  1. Достоверность - это важно.Постарайтесь убедиться, что все, что вы измеряете, не имеет большого значения для отклонения.Используйте технику выполнения нескольких прогонов по одному и тому же сценарию, избавьтесь от выбросов (т. Е. Вашего самого низкого и самого высокого) и оцените ваши значения avg / max / min / median.Если вы проводите какое-то тестирование пропускной способности, подумайте над тем, чтобы сделать его длительным, чтобы у вас был хороший набор образцов.Например, если вы смотрите на что-то вроде Microsoft Exchange и, таким образом, используете их счетчики производительности, постарайтесь удостовериться, что вы берете частые выборки (один раз в секунду или каждые несколько секунд) и проводите тестовый прогон в течение 20 минут или около того.Опять же, отрежьте первые несколько минут и последние несколько минут, чтобы устранить любой шум запуска / выключения.

  2. Гейзенбург - хитро.В большинстве современных систем, в зависимости от того, какое приложение / меры вы измеряете, вы можете минимизировать это влияние, хорошо разбираясь в том, что / как вы измеряете.Иногда (как в примере с Exchange) вы можете увидеть воздействие, близкое к 0.Старайтесь использовать как можно менее инвазивные инструменты.Например, если вы измеряете время запуска, рассмотрите возможность использования xperfinfo и использования событий, встроенных в ядро.Если вы используете perfmon, не заполняйте систему посторонними счетчиками, которые вам не нужны.Если вы проводите какое-то чрезвычайно длительное испытание, увеличьте интервал выборки.

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

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

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

Наслаждайтесь!

1 голос
/ 19 сентября 2010

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

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

  • Многопоточность: если библиотека использует это или ваше программное обеспечение будет использовать библиотека в многопоточном контексте тогда вам, возможно, придется проверить это с много разных процессоров и многопроцессорные конфигурации, чтобы увидеть как это реагирует.
  • Время запуска: его Важность зависит от того, насколько интенсивно вы будете использовать библиотеку и что характер строящегося продукта с ним (клиент, сервер…).
  • Время отклика: за это не берут первое выполнение, попробуйте выполнить один и тот же звонок много раз после Первый и сделать в среднем. С помощью System.Diagnostics.StopWatch может быть очень полезно для этого.
  • Память потребление: проанализировать рост, остерегайтесь экспоненциальных;). Перейти шаг вперед и измерить количество объекты создаются и удаляются.
  • Отзывчивость: надо не только измерить сырой производительности, как пользователь чувствует скорость продукта это тоже очень важно.
  • Сеть: если библиотека использует ресурсы в сети вам, возможно, придется проверить это с разная пропускная способность и задержка конфигурации, есть программное обеспечение для смоделируйте эти ситуации.
  • Данные: попробуйте создать много разных тестов пакеты данных, пытаясь покрыть, для пример: большая куча необработанных данных, затем большой набор из множества меньших куски, длинная итерация с маленьким кусочки данных,…

Инструменты:

  • System.Diagnostics.Stopwatch : необходим для вызова методов бенчмаркинга
  • Счетчики производительности : при их наличии очень полезно знать, что происходит внутри, позволяя вам контролировать программное обеспечение без ущерба для его производительности.
  • Профилировщики: на рынке есть хорошие профилировщики памяти и производительности, но, как вы сказали, они всегда влияют на измерения. Они хороши для поиска узких мест в вашем программном обеспечении, но я не думаю, что вы можете использовать их для сравнительного теста.
0 голосов
/ 08 сентября 2010

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...