Фреймворк Talos

Глава 8 из книги "Производительность приложений с открытым исходным кодом".

Оригинал: Talos
Авторы: Clint Talbert, Joel Maher
Перевод: А.Панин

Понимание измеряемых параметров

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

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

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

Мы понимали принцип работы одного определенного теста. Мы знали о том, что этот тест загружал список из 100 наиболее популярных на данный момент вебсайтов, загружал по одному вебсайту, повторяя загрузку по 10 раз. Talos загружал страницу, ожидал наступления события mozAfterPaint (стандартного события, которое генерируется в тот момент, когда Firefox выполнил прорисовку представления веб-страницы на канве), после чего сохранял данные о времени с момента загрузки страницы до момента наступления этого события. Рассмотрение 1000 результатов измерений, полученных в результате однократного выполнения теста оказалось не достаточно очевидным приемом оценки производительности. Представьте обобщение всех этих 1000 результатов измерений в одном значении и отслеживание этого значения в течение длительного промежутка времени. Что будет в том случае, если мы сделаем систему разбора каскадных стилей CSS быстрее, при этом сделав загрузчик изображений медленнее? Как мы обнаружим подобное изменение производительности? Будет ли возможность обнаружения того, что страница 17 замедляет процесс работы браузера в том случае, если остальные 99 страниц загружаются с той же скоростью? Для демонстрации того, как описанные значения вычислялись в оригинальной версии фреймворка Talos, рассмотрим следующие числа.

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

Мы были готовы доказать то, что нам удастся снизить статистический шум в генерируемых в результате проведения этого тестирования процесса загрузки 100 страниц данных. Так как в процессе тестирования измеряется время загрузки страницы, в первую очередь нам потребовалось изолировать тестовое окружение от таких воздействий со стороны системы, как кэширование данных. Мы изменили тест таким образом, что вместо поочередной загрузки страниц снова и снова загружалась одна и та же страница и, таким образом, измерялось время загрузки в большей степени кэшированной страницы. Хотя такой подход не соответствовал практике обзора веб-страниц конечными пользователями, он позволил избежать некоторого статистического шума в данных при записи результатов тестирования. К сожалению, рассмотрение только 10 результатов тестирования заданной страницы является недостаточным.

Изменяя количество тестов и вычисляя стандартное отклонение значений времени загрузки страницы в ходе множества тестов, мы установили, что статистический шум был практически устранен при как минимум 20-кратной загрузке страницы. После множества экспериментов мы определили оптимальное значение в 25 загрузок с пропуском результатов первых 5 загрузок. Другими словами, исследуя стандартное отклонение параметров процесса многократной загрузки страницы, мы обнаружили, что 95% наших результатов со статистическим шумом приходилось на первые пять загрузок. Несмотря на то, что мы не использовали эти первые 5 значений, мы сохраняли их, поэтому при желании у нас имеется возможность изменения алгоритма статистических вычислений в будущем.

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

Продолжение статьи: Повторная разработка системы против рефакторинга.