IX Международная студенческая научная конференция Студенческий научный форум - 2017

ВВЕДЕНИЕ

Согласно статистике (см. рис. 1), собираемой сайтом http://httparchive.org/, за последние 5 лет размеры отдельно взятых страниц сайтов выросли значительно. Особенно заметен рост числа javascript модулей, загружаемых в браузер при построении страницы. Всё это обуславливается усложнением веб-приложений, которое приходит из-за того, что в погоне за скоростью разработки создатели сайтов предпочитают использовать готовые фреймворки. Последние, пытаясь угодить сразу всем, обрастают множеством функций, большая часть из которых отдельно взятому проекту и не нужна. Так же в виду большого числа технологий, задействованных в веб-разработке, суммарно возникает большое число проблем с производительностью. Как следствие, мы получаем многие тысячи проверок, которые мы должны выполнить применительно к страницам с сотнями запросов и десятками тысяч строчек кода. На данный момент существует несколько десятков решений, которые позволяют проанализировать отдельно взятую страницу сайта, но нет ни одного законченного, позволяющего легко реализовывать свои собственные проверки. Этим и обуславливается актуальность данной работы.

Рис. 1

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

Объектом проектирования будет система, выполняющая проверки. Предметом же является вопрос создания удобного механизма добавления новых проверок.

Главной целью будет создание работающего приложения, позволяющего выполнять следующие задачи:

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

2. Максимально легко добавлять собственные уникальные проверки, связанные с производительностью

3. Иметь удобную интеграцию с популярными Серверами Непрерывной Интеграции

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

ГЛАВА 1. Анализ предметной области. 1.1 Формализация процесса контроля за производительностью выпускаемого продукта

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

В его задачи входит следующее:

1. Выявлять как можно раньше регрессию во времени работы функционала выпускаемого приложения

2. Давать рекомендации по ускорению существующего функционала

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

Рассмотрим третий пункт более детально. И постараемся более-менее формально описать последовательность действий, которые должен выполнить инженер для выявления указанных ошибок.

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

2. Для начала требуется открыть браузер Google Chrome и предварительно очистить кэш, куки и открыть проверяемый сайт.

3. Далее проходим авторизацию.

4. После открываем Chrome DevTools, нажимая клавишу F12, запускаем запись событий на вкладке Timeline.

Рис. 1.1 Окно Chrome DevTools

1. Открываем тестируемую страницу и дожидаемся её полной загрузки.

2. Теперь наступает основная часть работы - выполнение проверок.

3. После завершения всех проверок – нужно составить отчёт и опубликовать его. По этому отчёту ответственные за выпуск принимают решение об отмене или возможном переносе релиза.

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

1.2 Общий процесс выпуска версии

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

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

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

2. Затем через инструмент непрерывной интеграции Jenkins при помощи вспомогательных скриптов происходит сборка приложения. Код, написанный на C++, компилируется, для JS происходит обфускация. Происходит создание rpm пакетов для разворота приложения на серверах.

3. При помощи внутреннего инструмент выполняется развёртывание приложения, его первичная настройках и минимальная проверка.

4. Через тот же CI инструмент мы проводим разнообразное число проверок, среди которых особое место занимают автотесты, написанные на различных языках, но интегрированные в Jenkins. По результату прогонки автотестов получаются отчёты.

5. Анализируя отчёты, полученные на 4-ом шаге идёт определение серьёзности обнаруженных ошибок. Если обнаружены проблемы, сильно мешающие работе пользователей – происходит исправление ошибки и заново повторяются все шаги. Если же ошибки не критичны или их и вовсе нет, то принимается решение об обновлении боевой версии сайта.

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

Из всех рассмотренных шагов нам особо интересны 4-ый и 5-ый шаги, т.к. именно там происходит автоматическое выполнение проверок, создание отчётов и дальнейший их анализ. Эти части коррелируют с процессом анализа производительности, рассмотренном в параграфе 1.1. В виду этого в нашей системе появляются такие объекты как сервер непрерывной интеграции Jenkins, репозиторий, веб-приложение и отчёты. В дальнейшем при помощи этих элементов мы сможем внедрить систему оценки производительности в общий процесс разработки и релизов, что обеспечит наибольшую эффективность созданного решения.

1. 3 Выбор технологий методов и средств проектирования

При выбранном подходе с использованием паттернов автотестирования мы сталкиваемся с ситуацией, когда одним из интерфейсов взаимодействия с пользователем будет являться написание нового кода, реализующего ту или иную проверку. Эти проверки вносить будет инженер производительности, а не разработчик системы. Как следствие в данном случае мы вынуждены учитывать удобство добавления нового кода. И проектировать не только удобную систему, но и удобные классы, методы, модули, etc. Из всех возможных CASE-средств наиболее подходящим под эту роль является язык UML. Он ближе всего к «коду» и позволяет достаточно легко после проектирования перейти к реализации, что позволит упростить процесс разработки. Существуют десятки инструментов, с помощью которых можно работать с UML. «Umbrello» был выбран среди них из-за его доступности – он распространяется под GPL лицензией, его простоте и функциональных возможностей и кроссплатформенности.

Для моделирования процессов, как основных, так и вложенных нам потребуются методология IDEF0. Предстоит описать сложные процессы, а так же выполнить их анализ. Основываясь на высказанных требованиях мы выберем инструмент под названием «Rasmus». Он достаточно гибок и функционален и поможет нам спроектировать и оценить, анализируемые процессы.

В меньшей степени нам предстоит работать с СУБД. В основном будет речь о накоплении данных о производительности и состоянии веб-приложения. Тут нам поможет IDEF1X нотация и ER-диаграммы. Опять же мы их сможем просто нарисовать в любом графическом редакторе. Но этого не достаточно, когда нужно не просто продемонстрировать решение, а целиком его спроектировать. Тут нам потребуется очередной специалист в области CASE средств для баз данных – «ERwin».

ГЛАВА 2. Проектирование ИС

2. 1 Моделирование процессов

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

Рис. 2.1 Верхний уровень модели в нотации IDEF0

В качестве общего действия мы выбрали «Выпуск новой версии». Поскольку задачи инженера по анализу производительности включены в общий вектор усилий по успешному выпуску релиза разрабатываемого приложения. Традиционно на вход подаются объекты, над которыми выполняются операции. В нашем случае – это требования и ресурсы. И первое и второе крайне важно при проектной работе и являются ключевыми факторами, определяющими то как, когда и часто с каким результатом произойдёт окончание работ. Все работы регламентируются как общеотраслевыми стандартами, так и внутренними технологиями и методиками. На выходе мы получаем обновлённую версию (основная цель всей работы) и оформленные ошибки и задачи в багтрекере (система документооборота специализирующаяся на процессах разработки). Все эти задачи в будущем позволят улучшить следующую итерацию выпуска новой версии приложения. Отдельно указаны используемые инструменты. Их большое число обусловлено большим разнообразием технологий и работ, выполняемых при разработке сложных программных комплексах. В реальности их конечно будет гораздо больше, но поскольку мы сконцентрировались на внедрении отдельного элементу в существующий налаженный процесс, то и инструменты указываем лишь те, что понадобятся для автоматизации работ по оценки производительности продукта.

Перейдём к рассмотрению процесса выпуска нового релиза (рис. 2.2). Всё начинается с решения руководства о выпуске нового релиза, в результате чего в отдел разработки попадают требования, оформленные в виде письма с набором требований (чаще) или же готового технического задания (реже). Далее ответственные лица от разработки занимаются разработкой архитектуры, проектированием и реализацией уточнённых требований. Как итог – разработанный исходный код попадает в общий репозиторий, в которому в последствии смогут обратиться все лица, задействованные в процессе выпуска версии. Первыми с ним начинаются работать сборщики. Эти специалисты при помощи сервера непрерывной интеграции Jenkins, необходимого набора компиляторов и большого числа вспомогательных инструментов создают rpm-пакеты. Они же далее, используя внутренний инструменты для разворота приложений на тестовых стендах обновляют тестовую копию сайта. И уже только после этого наступает фаза тестирования. Результатом работы отдела тестирования являются отчёты и заведённый в багтрекере задачи. Благодаря отчётам ответственные за выпуск продукта могут оценить текущее состояние версии, наличие ошибок и пригодность для использования на бою. И если все показатели оказываются в пределах норм принимается решение об обновлении продукта на боевых стендах. Последнее выполнятся в точности так же, как это происходило на тестовых стендах, что позволяет избежать проблем при работах в боевом окружении.

Рис. 2.2 Детализированное описание процесса работы над релизом

Наконец мы подошли к проектируемому нами процессу – процессу автоматизированного анализа производительности веб-приложения (рис. 2.3).

Рис. 2.3 Процесс автоматизированного анализа производительности веб-приложения

Процесс решено было сделать полуавтоматическим, первая фаза (A41-A43) автоматически создаёт отчёты, которые далее уже обрабатывает специалист (A44), что позволяет сократить объём рутины, но оставить высокий уровень качества работ за счёт наличия в данной информационной системе экспертной оценки производительности. Автоматизация выполняется в рамках CI сервера Jenkins, через который мы получаем свежие инструменты и инициируем сам процесс построения отчёта. В первой фазе через скрипты, написанные на языке Python и bash запускаем браузер Chrome. Выбор последнего обусловлен наличием в нём дебаг-режима, позволяющего управлять браузером и получать множество необходимой информации о состоянии страницы сайта и самого браузера. После того как браузер был запущен мы выполняем открытие страницы. Это действие на практике сопряжено со сложностью определения окончания времени открытия страницы. Т.к. даже человеку вручную иногда это сложно сделать, то продумать действенный алгоритм ещё более сложная техническая задача. Все общепринятые подходы имеют множество недостатков и в каждом конкретном случае проектировщик выбирает подходящее под текущие условия решения. Мы выбрали вариант с использованием, реализованным в качестве стандарта W3C консорциумом, инструментом – WebDriver. Он выполняет свои проверки через тот же отладочный режим браузера Google Chrome. После этого мы получаем дамп данных из браузера и можем выполнить весь список проверок. Это действие является ключевым во всей системе, т.к. инженеру по производительности необходимо оперативно вносить свои проверки, а для этого нужна продуманная реализация системы классов и их методов. Выбранный паттерн будет кратко рассмотрен в параграфе 2.3. По окончанию всех проверок создаётся отчёт, анализируемый ответственным лицом. По результату анализа заводятся ошибки и задачи в системе багтрекинга.

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

2.2 Проектирование БД

Для создания ER-диаграмм логической и физической структуры БД воспользуемся решением ERwin Data Modeler, специализированное непосредственно для таких задач. В общим виде хранение информации в БД при единичном анализе производительности не имеет никакого смысла кроме академического. Однако, всё меняется когда мы приходим к пониманию того, что крупное веб-приложение – динамическая система, важной составляющей которой является её развитие во времени. Это обуславливает важность ретроспективных исследований, в частности в области производительности. И вот в этом случае нам понадобиться база данных, в которой можно структурировано хранить данные по каждой выпускаемой нами версии в различный точки во времени. Немаловажным является возможность быстрой всех данных по первому требованию пользователя. Это накладываем ряд ограничений на структур БД, к примеру к необходимости привести все связи к третьей нормальной форме. Так же важно понимать потенциальные объёмы получаемой БД и связанные с этим сложности. Для того, что бы заблаговременно их избежать принято решение использовать свободно распространяемую корпоративную СУБД PostgreSQL.

Рис. 2.4 Логическая схема спроектированной БД

На рис. 2.4 изображена логическая схема нашей базы данных. Ключевой сущностью является test, который связан с сущностями build_config и site связью многие к одному. Сущность test отображает понятие отдельно взятой тестовой сессии, в рамках которой мы проводим замеры производительности. Под сущностью site мы подразумеваем продукт, который будем проверять, а в сущности build_config содержатся данные о версии тестируемого приложения. Далее мы имеем две ключевые сущности – url и measurements. Первый представляет собой страницы, а второй непосредственно сами замеры. Сущность page выполняет вспомогательную роль, являясь связующим звеном между отдельно взятым тестом и замером, отражая в себе экземпляр сущности url в момент замера. Большая часть атрибутов сущностей очевидна, рассмотрим самые важные атрибуты – атрибуты сущности measurement. Для того, что бы оценивать время открытия страницы в перспективе мы записываем время открытие в поле load_time. Кроме клиентских метрик и логов полезными при анализе оказываются серверные логии, в наших приложениях они хранятся в специализированных БД – Elastic и собственном решении, в основе которого лежит особым образом сконфигурированный кластер из PostgreSQL серверов. Соответственно в полях load_from_cloud и load_from_elastic содержатся ссылки на соответствующие логии, перейдя по которым мы получим отфильтрованные данные, связанные с нашими замерами. Точное время выполнения замера записывается в поле measurement_datetime. Состояние браузера и время работы сайта часто зависит от заполненности localStorage и sessionStorage, где сайт хранит пользовательские данные, для быстрого доступа, не выходя з пределы компьютера пользователя. Для того, что бы иметь подробные данные о сетевой активности при генерации отчётов мы создаём файл со спецификацией HAR. В текущем решении мы в БД храним только ссылку на этот файл (атрибут har-_file), но оставляем за собой возможность непосредственно записывать сам HAR файл в это поле. Время открытия страниц, скорость работы сайта и в целом производительность сильно зависят от окружения, в том числе от конфигурации компьютера. На данном этапе мы не знаем точно, какие данные и в каком формате тут понадобятся. Поэтому оформляем их в виде только одного атрибута client_pc_parameters. Особняком указываются данные о числе запросов – requests_number и объёме переданного трафика - traffic_size. Их так же можно получить из HAR-файла, но поскольку массового такая операция выполняется очень долго – мы специально выносим их в отдельные атрибуты. Наш замер по тем или иным причинам может оказаться невалидным – выключили электричество или неправильно сконфигурировали тестовое приложение, что бы мы могли отличать полезные замеры от неполезных – используем атрибут is_successful. Можно конечно такие замеры и вовсе не вносить в БД. Но в практике ретроспективного анализа даже такие неудачные замеры могут дать пищу для размышлений, особенно когда речь заходит об экспериментах в области производительности или принятия управленческих решений. Например нам хотелось бы понять, насколько сложно и долго мы получаем информацию о производительности новой версии. В этом случае неудачные замеры послужат лакмусовой бумажкой. Так же всегда происходит разделение типов замеров. Одни выполняются с пустым кешем браузера, а вторые уже с заполненным. Что бы понять какой замер перед нами имеется атрибут cache.

Хоть нами и была выбрана СУБД PostgreSQL, мы оставляем за собой право и следовательно возможность переезда на другую систему. Это отражено в физической модели, которая была спроектирована для нашей информационной системы (рис. 2.5).

Рис. 2.5 Физическая модель БД

2. 3 Проектирование архитектуры проверок

Как писалось выше – инженер, оценивающий производительность будет вносить свои проверки в систему за счёт написания кода. И желательно сделать так, что бы этот код писать было удобно и мы бы не запутались во всём множестве проверок. Вместо описания конкретной реализации – постараемся спроектировать и описать на языке UML диаграмму классов, который позднее можно будет реализовать на объектно-ориентированном языке Python (рис. 2.6).

Рис. 2.6 UML диаграмма классов, описывающих структуру проверок производительности

В процессе разработки любого приложения обобщение решений происходит в частности через паттерны проектирования. В области автоматизации тестирования так же есть такие паттерны. Один из нх xUnitTest – паттерн проектирования самих тестов. Мы по сути опишем его адаптацию под нашу информационную систему. На вершине мы видим класс Test Suite обозначающий под собой весь набор тестов. Среди атрибутов у него имеется описание (description) и экземпляры класса Test Case, а среди методов – get_configuration и run. Первый возвращает нам экземпляр класса Configuaration,а в торой запускает все проверки. Класс Configuration инкапсулирует в себе все общие настройки для тестов, e.g. сайт, на котором мы выполняем наши проверки и время таймаута ожидания открытия страницы. Ясно, что в дальнейшем этот класс будет дополняться атрибутами, при проектировании важно лишь обозначить наличие самого класса для работы с кофнгурацией. Класс Test Case содержит в себе экземпляры класса Test Method. Каждый экземпляр класса Test Method по факту является отдельной проверкой. В соответствии с выбранным паттерном на нужна возможность выполнять какие-либо постоянные действия перед всеми тестами и после всех тестов – например закрыть браузер. Для этого мы используем методы setup_class и teardown_class. Аналогичную роль но уже для каждого отдельного теста выполняют методы setup и teardown. Непосредственно в классе Test Method содержатся проверки, для их выполнения используются методы assert – тут мы указываем код с проверками и вспомогательные методы для открытия страницы – open_page() и для получения данных из браузера – get_chrome_dump. Разные классы проверок могут потребовать разных тестовых методов и вспомогательных механизмов. Для этого мы можем наследоваться от класса Test Case и создавать например класс для проверки работы сайта с сетью – Network Test Case.

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

Список литературы

1. Daniel Austin. Web Performance: The Definitive Guide [Текст] / Daniel Austin. –O'Reilly Media, 2016. – 500 с.

2. HTTP Archive (HAR) format. [Электронный источник], 2012. URL: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HAR/Overview.html (дата обращения: 30.01.2016).

3. HypertextTransferProtocol– HTTP/1.1. [Электронный источник], 1999. URL: https://www.ietf.org/rfc/rfc2616.txt (дата обращения: 30.01.2016).

4. IlyaGrigorik. High Performance Browser Networking: What every web developer should know about networking and web performance [Текст]/ IlyaGrigorik–O'Reilly Media, 2013. –400 c.

5. Jesus Castello. Web performance: a pragramatic approach [Электронныйисточник]/ Jesus Castello–Amazon Digital Services LLC, 2015. –70с.

6. NavigationTimingLevel 2. [Электронный источник], 2015. URL: https://www.w3.org/TR/navigation-timing-2/ (дата обращения: 30.01.2016).

7. Peter Smith. Professional Website Performance: Optimizing the Front-End and Back-End [Текст]/ Peter Smith–Wrox, 2012. – 480с.

8. StoyanStefanov. Web Performance Daybook Volume 2 [Электронныйисточник]/ StoyanStefanov–O'Reilly Media, 2012. – 226 с.

9. Заботина Н. Н.Проектирование информационных систем[Электронный источник]/ Заботина Н. Н. – НИЦ ИНФРА-М, 2014. – 331 с.

Код для цитирования: Скопировать