Создание лаборатории для тестирования производительности разработчиков

Question

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

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

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

Одно из направлений, которое я настаиваю, - это установить лабораторную среду, установленную с ночной сборкой, чтобы разработчики могли проверить влияние своего кода на производительность. Мне бы хотелось, чтобы эта среда постоянно загружалась скриптами, имитирующими опыт реального пользователя. В этой загруженной среде каждый разработчик должен будет написать специальный сценарий, который тестирует его код (т. Е. Опыт одного пользователя в реальной среде). Я хотел бы создать отчет, показывающий влияние каждой итерации на существующие функции, а также производительность новых функций.

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

Что вы думаете о такой идее? У кого-нибудь есть опыт настройки такой среды? Вы можете поделиться своим опытом?

Answer 1

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

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

После того, как вы это сделаете, у вас будут все знания, необходимые для создания тестов производительности.

Один совет: не пытайтесь достичь всего сразу. Работайте по одному шагу за раз, исправляйте одну проблему за другой. Если кто-то придумает: «Мы тоже должны это сделать», вы должны выполнить ту же сортировку, что и в случае с любым другим запросом: насколько это важно? Насколько опасно? Сколько времени это займет для реализации? Сколько мы получим?

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

Answer 2

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

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

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

РЕДАКТИРОВАТЬ: "Разве разработчики не несут ответственности за тест производительности кода" был комментарий. Да, верно. Я лично хотел бы, чтобы у каждого разработчика была копия Java-профилировщика YourKit (это дешево и эффективно), и я знал бы, как ее использовать. Однако, к сожалению, настройка производительности - это действительно очень интересное техническое занятие, и можно потратить много времени, занимаясь этим, когда вы будете лучше разрабатывать функции.

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

Answer 3

Ночные сборки - правильный подход к тестированию производительности. Я предлагаю вам требовать скрипты, которые запускаются автоматически каждую ночь. Затем запишите результаты в базу данных и предоставьте регулярные отчеты. Вам действительно нужны два вида отчетов:

• График каждой метрики с течением времени. Это поможет вам увидеть ваши тенденции
• Сравнение каждой метрики с базовой линией. Вам необходимо знать, когда что-то резко падает за день или когда оно пересекает порог производительности.

Несколько других предложений:

• Убедитесь, что ваши машины отличаются в зависимости от вашей предполагаемой среды. Имейте в бассейне машины низкого и высокого класса.
• Как только вы начнете измерения, никогда не меняйте машины. Вам нужно сравнить, как нравится. Вы можете добавлять новые машины, но не можете изменять существующие.

Answer 4

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

Убедитесь, что ваши лабораторные условия изолированы и стабильны (т. Е. Вы изменяете только один фактор за раз, будь то ваше приложение или обновление Windows), а оборудование отражает вашу цель. Помните, что ваши сравнительные результаты будут пуленепробиваемыми только внутри лаборатории.

Тестовые сценарии, написанные разработчиками, написавшими код, имеют тенденцию быть токсичным. Это не поможет вам устранить недоразумения при реализации (поскольку такое же недопонимание будет в тестовом скрипте), и мотивация для поиска проблем ограничена. Гораздо лучше использовать подход TDD и написать тесты сначала как группа (или отдельная группа), но при этом вы не сможете улучшить процесс, написав сценарии совместно. Надеюсь, у вас есть несколько пользовательских историй со стадии разработки, и может быть возможно воспроизвести журналы для реального опыта (различные приложения).

Answer 5

Мы построили небольшой испытательный стенд для проверки работоспособности - т.е. приложение запускалось и работало, как и ожидалось, при нажатии кнопок, выполняло проверку и т. Д. У нас было веб-приложение и мы использовали Watir Инструментарий на основе рубина для управления браузером. Выходные данные этих прогонов создаются в виде документов XML, и наш инструмент CI (круиз-контроль) может выводить результаты, ошибки и производительность как часть каждого журнала сборки. Все это работало хорошо и могло быть масштабировано на несколько компьютеров для надлежащего тестирования нагрузки.

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