Какова надлежащая практика для тестирования правил производительности?

Question

Я знаю, что то, что мы делаем, - неправильная / странная практика.

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

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

myStopwatch.StartNew()
newMyObject = New myObject()
myStopwatch.Stop()
Assert(myStopwatch.ElapsedMilliseconds < 100)

Или: Ошибка, если строительство занимает более 100 мс

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

РЕДАКТИРОВАТЬ: В ответ на некоторые ответы; мы явно хотим, чтобы наши ворота отклоняли проверки, влияющие на эту производительность, мы не хотим проверять журналы или отслеживать изменения в данных.

Вопрос:
Как правильно измерять производительность в наших регистрационных воротах?

Answer 1

Чтобы избежать зависимости от машины, вы можете в первый раз построить «эталонный объект», который имеет известное приемлемое время строительства.Затем сравните время создания объекта со временем эталонного объекта.

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

Answer 2

Во-первых, я бы сказал: Разве вы не можете позволить, чтобы часть этой логики выполнялась лениво, а не выполнялась полностью в конструкторе / инициализации?Или вы можете разделить объект?Полезный показатель для этого: LCOM4 .

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

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

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

Answer 3

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

Этот модульный тест должен быть скомпилирован и запущен, пока разработчик сидит и ждет его. Как вы указали, одна итерация теста недостаточно хороша для получения согласованных результатов. Сколько раз нужно было бы запустить, чтобы быть надежным? 10? Выполнение 10 итераций увеличило бы время проверки на 1 секунду и все еще не достаточно надежно, на мой взгляд. Если вы увеличите это значение до 100 итераций, вы получите лучший результат, но это прибавит 10 секунд ко времени проверки.

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

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

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

Что касается конкретного теста, я не думаю, что вы можете сойтись с чем-то другим, кроме как выполнить тест через несколько итераций, чтобы получить более точный результат. Я не хотел бы полагаться на что-то меньшее, чем 5 или 10-секундный тест (то есть от 50 до 100 итераций).