Меню Рубрики

Установка и тестирование сервера

WebPageTest — локальная установка и настройка приватного сервера тестирования скорости сайта

Есть очень удобный сервис для тестирования скорости работы сайта — webpagetest.org. Мало того, что он самый удобный и информативный из всех, что я знаю, так его еще и локально можно установить себе на сервер. Этим я и займусь — установкой и настройкой локальной версии сервиса webpagetest для тестирования скорости работы сайта.

Введение

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

Был сайт, который работал на HTTP/1.1 с разделением самого сайта и картинок по разным доменам. Сайт на одном домене, картинки на поддомене. Сделано это было для того, чтобы побыстрее грузить сайт. Если кто не знает, то напомню, что протокол HTTP/1.1 мог одновременно устанавливать только 5 соединений. Вывод картинок на отдельный поддомен ускорял загрузку.

Я решил перевести сайт на HTTP/2.0 и разместить на одном домене. Протокол HTTP/2.0 снимал ограничение на количество подключений, так что весь сайт начинал грузиться сразу. Дополнительно появлялись приоритеты загрузки для разных типов данных, что теоретически тоже ускоряло загрузку сайта. Разделение на поддомены стало не нужным, а оно усложняло управление и администрирование, поэтому логичным было сделать сайт опять единым. Я провел начальные тесты сайта на HTTP/1.1, потом перевел его на HTTP/2.0 и объединил домены.

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

При разделении сайта на поддомены лесенка запросов и загрузок складывалась более оптимально, так что первый контент появлялся раньше, чем то же самое на HTTP/2.0. Это была особенность конкретного сайта, его структуры и верстки. В общем случае так быть не должно, а тут было именно так. Я пытался вручную скорректировать загрузку, используя современные механизмы HTTP/2.0 типа server push, но сделать результат лучше, чем был на HTTP/1.1 так и не получилось. В итоге просто откатился обратно.

Я привел этот случай для примера, зачем нужен webpagetest. Без него мне бы и в голову не пришло, что переход на HTTP/2.0 даст отрицательный результат. Теперь перед каждым изменением сайта, я внимательно тестирую ключевые страницы и сравниваю, как было и как стало. То же самое сделал при переходе на tls 1.3 и сжатие brotli. Но результат оценить не смог. Установленная версия webpagetest не поддерживает tls 1.3 и brotli. По заголовкам увидел, что использует gzip и tls 1.2. Надо внимательно разбираться с настройками и версиями используемых браузеров.

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

Установка docker на Ubuntu 18

Далее расскажу, как установить свою персональную локальную версию webpagetest для регулярного использования. Это может быть нужно по нескольким причинам:

  • Вы часто делаете тесты и вас не устраивает очередь ожидания в публичном сервисе.
  • Вы хотите сами выбирать, где располагать тестовые локации с агентом. Очевидно, что они должны быть там же, где целевая аудитория сайта.

Сервер webpagetest состоит из следующих компонентов:

  1. Сервер с веб интерфейсом.
  2. Агент с браузерами для тестирования.

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

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

Как я уже сказал ранее, сервер и клиент будут в docker. Хостовая система будет Ubuntu 18, как наиболее подходящая для работы с докером. Но в целом это не важно, можете разворачивать на любой системе, где работает docker.

Если он у вас уже установлен, пропустите этот раздел. Установка docker на Ubuntu 18:

Локальная установка webpagetest

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

Скачиваем официальные образы из docker hub:

Подробную информацию об образах можете посмотреть на docker hub — https://hub.docker.com/u/webpagetest/ .

Запускаем сервер webpagetest:

Проверьте, что у вас 80-й порт никто не занимает. Если он занят, то используйте другой. И не забудьте настроить или отключить firewall. Через пару минут после запуска, переходите по адресу http://89.223.28.57/ , где 89.223.28.57 — ip адрес сервера. Увидите веб интерфейс локальной версии webpagetest.

Теперь пройдите по адресу http://89.223.28.57/install/ и проверьте выполнение всех основных условий работы. Должно быть примерно так.

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

Подождите пару минут и проверяйте страничку http://89.223.28.57/install/ , вы должны увидеть подключившегося агента.

Читайте также:  Установка вентилятора с помощью

На этом базовая установка локального сервера webpagetest готова. Можно начинать тесты. В качестве Test Location выбирайте Test Location (тавтология получилась), указывайте остальные параметры и проверяйте сайт.

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

Настройка своего сервера webpagetest

Создадим свои docker образы, на основе официальных, немного их изменив, вынеся конфигурации на хостовую машину. Для этого создадим 2 директории:

Создадим dockerfile и конфиг для сервера:

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

Приведенные настройки образа призывают использовать оригинальный образ, заменив файл locations.ini на тот, что вы создали. Собираем образ с сервером:

Делаем то же самое для агента.

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

Делаем скрипт исполняемым и собираем образ:

Запускаем сервер и агент из наших новых образов. Сначала сервер:

Ждем немного и проверяем web интерфейс. Если все ОК, запускаем агента.

Проверьте на всякий случай, все ли правильно запустилось:

Проверьте, подключился ли агент.

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

На этом все. Вопрос локальной установки webpagetest я раскрыл.

Заключение

Я выбрал установку из контейнера из-за простоты и удобства. Здесь как раз тот случай, где docker оправдывает себя на все 100%. Я собирал все то же самое из пакетов, у меня даже работало, но это занимало в разы больше времени. Система многокомпонентная с огромным числом зависимостей и сервисов. Все это настраивать вручную очень хлопотно. Есть скрипт автоматической установки, но с ним тоже есть проблемы. Я немного повозился просто из любопытства. В итоге понял, что с докером проще, как в установке, так и в обновлении сервера.

При желании, к системе можно прикрутить https, авторизацию через basic auth. Не стал это рассматривать отдельно, так как тема стандартная. При желании, каждый сможет сам настроить. Под капотом у webpagetest обычный nginx в качестве веб сервера. Еще полезная ссылка — https://github.com/WPO-Foundation , профиль компании на github со всем софтом и инструкциями.

В целом, проект Webpagetest очень интересный и полезный, но на удивление, слабо освещен в интернете. Практически не нашел никакой информации. Я внимательно погуглил тему, но в итоге почти во всем разбирался сам с помощью инструкций на github и документации. В заключении маленький и полезный нюанс. По-умолчанию, webpagetest тестирует сайт в разрешении 1024 на 768. Не самое популярное на текущий момент. Я не стал ковыряться в потрохах сервера, чтобы изменить этот параметр, а поступил проще. Для установки разрешения экрана, просто добавьте следующий код на вкладке Advansed settings -> Script:

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

источник

Открытые бенчмарки для нагрузочного тестирования серверов и веб-приложений

Это — подборка утилит, составленная на основе рекомендаций резидентов Hacker News и GitHub. В список вошли: Locust, Vegeta, Slow_cooker, k6 и Siege. Ими пользуются инженеры из DICE, EA и Buoyant, а также разработчики Kubernetes и Load Impact. Расскажем об этих инструментах.

Locust.io

Инструмент для нагрузочного тестирования сайтов. Все сценарии пишутся на Python. Специальный веб-интерфейс, построенный на Flask, позволяет мониторить результаты в реальном времени. Авторы Locust — швейцарские инженеры, среди которых числятся сотрудники компаний DICE и EA, занимающихся разработкой и изданием компьютерных игр.

В основу инструмента заложена интересная концепция: Locust («саранча») эмулирует поведение целого роя насекомых (виртуальных пользователей), «атакующих» сайт во время теста. Запросы формируют с помощью сетевой библиотеки для организации параллельных вычислений — gevent. Вот пример простого теста, который приведен на официальном сайте проекта:

Locust задействует библиотеку requests. Эта надстройка над стандартными средствами Python упрощает работу с HTTP и SSL и делает код более наглядным. К слову, документацию requests можно использовать в качестве шпаргалки для отладки тестов на Locust.

Этот инструмент для нагрузочного тестирования существует уже более семи лет. За это время вокруг него сформировалось обширное комьюнити — на GitHub более 10 тыс. звезд. Locust использовали при оценке работоспособности сети Battlelog для серии игр Battlefield. Об инструменте положительно отозвался Армин Ронахер (Armin Ronacher), автор фреймворка Flask.

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

Если вы хотите поближе познакомиться с Locust, то стоит обратить внимание на документацию инструмента. Также можно рекомендовать выступление Алексея Романова из Wargaming на Python Meetup. Он рассказывает, как писать сценарии, эмулирующие поведение пользователей.

Vegeta

Утилита командной строки для тестирования HTTP-сервисов, написанная на Go. Её можно подключить как библиотеку для создания своих инструментов нагрузочного тестирования. Разработчиком Vegeta выступил один из авторов отрытой платформы Sourcegraph — это движок для рецензирования и навигации по исходному коду, который используют в Lyft, Uber и Yelp.

Vegeta оценивает возможности сетевых ресурсов, «бомбардируя» их запросами с установленной частотой. Например, для проверки localhost достаточно прописать следующую команду:

По умолчанию Vegeta работает со стандартным потоком чтения команд (stdin), поэтому ресурс для тестирования передается через echo. Параметр duration указывает продолжительность теста. Репорт будет сгенерирован в файл results.bin. Отчеты Vegeta генерирует в текстовом формате, но при этом умеет рисовать графики. Сгенерировать их можно следующей командой:

Читайте также:  Установка галогенных ламп osram

Вокруг Vegeta сформировалось крупное сообщество — 12 тыс. звезд на GitHub. Инструмент даже использовали разработчики Kubernetes для оценки производительности своей платформы — тогда Vegeta генерировала около 10 млн запросов в секунду к кластеру из тысячи узлов.

Документация с описанием всех функций и флагов для тестов Vegeta есть в репозитории на GitHub. Там же можно найти предварительно скомпилированные исполняемые файлы.

Slow_cooker

Это — инструмент для нагрузочного тестирования серверов, написанный на Go. Его разработали инженеры из компании Buoyant, которая создает сервисную сеть для Kubernetes — Linkerd. Она является частью Cloud Native Computing Foundation и считается конкурентом Google Istio.


Фото — Joshua Aragon — Unsplash

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

Специалисты из Buoyant используют свою разработку для тестирования Linkerd и других сервисов, например nginx. Инструмент довольно молодой — ему около трех — поэтому пока он не обзавелся большим комьюнити. Но в будущем ситуация может измениться, например, его репозиторий уже форкнули в Skysсanner, международном сервисе для поиска авиабилетов.

Исходный код вы можете найти на GitHub.

Инструмент для нагрузочного и регрессионного тестирования микросервисов, контейнеров и сайтов, размещенных в облаке. Он написан на Go и JavaScript разработчиками из Load Impact — это приложение для тестирования «стойкости» сайтов.

Работа с k6 строится по модели everything as code, когда логика тестов и все настройки пишутся на JavaScript. В скриптах отдельные шаги можно объединять в группы (group), что может быть удобно для тех, кто привык следовать принципам BDD. Вот пример такой группы:

Также инструмент дает возможность записывать скрипты и строить графики — последняя функция реализована на InfluxDB и Grafana. И у него есть интеграции с CI-системами вроде Jenkins, Circle CI, Team City и GitLab.

Пользователи говорят, что k6 не требователен к ресурсам, и у него удобный API. Но есть и несколько недостатков, в частности, k6 не поддерживает websocket и не умеет проводить тесты на распределенных системах. Хотя разработчики k6 в тематическом треде на Hacker News рассказали, что эти функции появятся в будущем.

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

Siege

Siege позволяет провести нагрузочное тестирование веб-серверов. Утилиту создал инженер Джефф Фалмер (Jeff Fulmer), чтобы разработчики могли проверить ресурсоемкость своего кода в условиях, приближенных к боевым. Siege эмулирует непрерывный поток обращений к сайту от множества пользователей, как бы удерживая сервер «под осадой» — отсюда и название инструмента.

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

Siege получил довольно широкое распространение в ИТ-сообществе. Например, нагрузочному тестированию с его помощью посвящен целый раздел в книге «NGINX High Performance». Также его используют некоторые облачные провайдеры.

Из недостатков Siege можно выделить нестандартный синтаксис и неочевидные методы подсчета параметров тестирования — например, редиректы считаются успешными транзакциями, поэтому их количество может превышать общее число запросов. Если вы хотите опробовать Siege на практике, изучите онлайн-руководство — там разобраны некоторые «странности» системы.

Дополнительное чтение в блоге 1cloud.ru:

Что нового в Linux kernel 5.3 — графические драйверы, виртуализация и другие обновления
Почему разработчики мейнстрим-браузера снова отказались от отображения поддомена
Почему Apple изменила требования к разработчикам приложений

источник

Тестовый сервер для команды разработчиков

Вводная

  1. Один тестовый сервер
  2. Gitlab и redmine на другом сервере
  3. Желание разобраться в проблеме

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

  1. Возможность тестировать несколько проектов/веток одновременно
  2. Разработчик может зайти на сервер, до настроить его и при этом не сломать ничего у других
  3. Все должно быть максимально удобно и делаться по 1 кнопке желательно из gitlab (CI/CD).

Варианты решений

1. Один сервер, много хостов

Самый простой вариант. Используем тот же тестовый сервер, только разработчику нужно создавать хост под каждую ветку/проект и вносить его в конфигурацию nginx/apache2.

  1. Быстро и всем понятно
  2. Можно автоматизировать

Минусы:

  1. Не выполняется п.2 из требований — разработчик может запустить обновление бд и при некотором стечении обстоятельств положить все (Привет Андрей!)
  2. Довольно сложная автоматизация с кучей конфигурационных файлов

2. Каждому разработчику по серверу!

Выделяем каждому по серверу и разработчик сам отвечает за свое хозяйство.

  1. Разработчик может полностью настроить сервер под свой проект

Минусы:

  1. п.2 требований так и не выполняется
  2. Дорого и ресурсы могут просто простаивать пока идет разработка, а не тестирование
  3. Автоматизация еще сложней чем в п.1 из-за разных серверов

3. Контейнеризация — docker, kubernetes

Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами.

  1. Используется один сервер
  2. Выполняются все пункты требований

Минусы:

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

Внедрение docker

При использовании gitlab очень часто попадались на глаза настройки AutoDevOps, kubernetes. Плюс бородатые дядьки на различных meetup рассказывают как у них круто все работает с kubernetes. Поэтому было принято решение попробовать развернуть кластер на своих мощностях, был выпрошен сервер (а тестовый трогать нельзя, там люди тестируют) и понеслась!

Читайте также:  Установка и настройка служб сервера

Так как опыта у меня с kubernetes 0, делось все по мануалу с попыткой понять как все эти кластера работают. Спустя некоторое время мне удалось поднять кластер, но потом пошли проблемы с сертификатами, ключами, да и вообще с трудностью развертывания. Мне же нужно было решение проще, чтобы научить своих коллег с этим работать (например, тот же отпуск не хочется проводить сидящим в скайпе и помогающим с настройкой). Поэтому kubernetes был оставлен в покое. Оставался сам docker и нужно было найти решение для маршрутизации контейнеров. Так как их можно было поднять на разных портах, то можно было бы использовать тот же nginx для внутреннего перенаправления. Называется это обратный прокси сервер.

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

Обратный прокси-сервер

Чтобы не изобретать велосипед, я начал искать готовые решения. И оно нашлось — это traefik.

Træfik — это современный обратный прокси HTTP и балансировщик нагрузки, который упрощает развертывание микросервисов. Træfik интегрируется с существующими инфраструктурными компонентами ( Docker, Swarm mode, Kubernetes, Marathon, Consul, Etcd, Rancher, Amazon ECS, . ) и настраивается автоматически и динамически. Для работы с docker достаточно указать его сокет и все, дальше Træfik сам находит все контейнеры и маршрутизацию до них (подробнее в «Упаковываем приложения в docker»).

Запускаю его через docker-compose.yml

Здесь мы сообщаем прокси, что нужно слушать порты 80,443 и 8080 (веб морда прокси), монтируем сокет докера, файл конфигурации и папку с сертификатами. Для удобства именования тестовых сайтов, мы решили сделать локальную доменную зону *.test. При обращении к любому сайту на ней, пользователь попадает на наш тестовый сервер. Поэтому сертификаты в папке traefik самоподписаные, но он так поддерживает Let’s Encrypt.

Перед стартом нужно создать в докере сеть proxy (можете назвать по своему).

Это будет сеть для связи traefik с контейнерами php сайтов. Поэтому указываем ее в параметре networks сервиса и в networks всего файла указав в параметре external: true.

Тут все довольно просто — указываем точки входа http и https трафика, не забудьте поставить insecureSkipVerify = true если сертификаты локальные. В секции entryPoints.https.tls можно не указывать сертификаты, тогда traefik подставит свой сертификат.

Если перейти по адресу site.test, то выдаст ошибку 404, так как этот домен не привязан ни к какому контейнеру.

Упаковываем приложения в docker

Теперь нужно настроить контейнер с приложением, а именно:

1. указать в сетях сеть proxy
2. добавить labels с конфигурацией traefik

Ниже приведена конфигурация одного из приложений

В сервисе app, в секции сети нужно указать proxy и default, это значит что он будет доступен в двух сетях, как видно из конфигурации я не пробрасываю порты наружу, все идет внутри сети.

Далее конфигурируем labels

В общей секции networks нужно указать external: true

Константу TEST_DOMAIN нужно заменить на домен, например, site.test

Теперь если зайти на домены site.test, crm.site.test, bonus.site.test можно увидеть рабочий сайт. А на домене pma.site.test будет phpmyadmin для удобной работы с бд.

Настройка GitLab

Создаем обработчик заданий, для этого запускаем

Указываем url gitlab, токен и через что будет выполняться задание (executors). Так как у меня тестовый и gitlab находятся на разных серверах, то выбираю ssh executor. Нужно будет указать адрес сервера и логин/пароль для подключения по ssh.

Runner можно сделать прикрепленным к одному или нескольким проектам. Так как у меня логика работы везде одинаковая, поэтому был создан shared runner (общий для всех проектов).
И последний штрих это создать файл конфигурации CI

В данной конфигурации описаны 2 этапа — build и clear. Этап build имеет 2 варианта выполнения — build_develop и build_prod

Gitlab строит понятную диаграмму выполнения процесса. В моем примере все процессы стартуют вручную (параметр when: manual). Сделано это для того, чтобы разработчик после разворачивания тестового сайта, мог делать pull своих правок в контейнер без пересборки всего контейнера. Еще одна причина это наименование доменов — site$CI_PIPELINE_ID.test, где CI_PIPELINE_ID — номер процесса запустившего сборку. То есть отдали на проверку сайт с доменом site123.test и чтобы внести горячие правки, сразу заливаются изменения в контейнер самим разработчиком.

Небольшая особенность работы ssh executor. При подключении к серверу создается папка вида

Поэтому была добавлена строчка

В ней мы поднимаемся на папку выше и копируем проект в папку с номером процесса. Так можно разворачивать несколько веток одного проекта. Но в настройках обработчика нужно поставить галку Lock to current projects, так обработчик не будет пытаться развернуть несколько веток одновременно.

Этап clear останавливает контейнеры и удаляет папку, могут понадобиться права root, поэтому используем команду echo password | sudo -S rm, где password ваш пароль.

Уборка мусора

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

Заключение

Данное решение помогло нам существенно оптимизировать тестирование и выпуск новых фич. Готов ответить на вопросы, конструктивная критика принимается.

Бонус

Для того чтобы не собирать каждый раз образы из Dockerfile, можно хранить их локальном реестре докера.

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

Можно настроить gitlab для просмотра

После этого в gitlab появляется список образов

источник

Добавить комментарий