Для анализа скорости работы сайта, на мой взгляд, лучший сервис - webpagetest.org. И в первую очередь из-за того, что его свободно можно развернуть в любом месте. И это будет полноценная полнофункциональная версия. В этом его главное преимущество. Вы можете локально развернуть его у себя и тестировать локальный же сайт, исключая все возможные помехи.
Одно время я много занимался сайтами, в том числе ускорением их работы. И webpagetest использовал постоянно. У меня была и локальная версия, и публичная, с подключением агентов из разных локаций. Я даже в общий доступ выставлял этот сервис и видел, что люди им пользуются.
Решил на днях посмотреть свежую версию и немного расстроился, не увидев готового образа Docker для быстрой установки сервиса. Установить можно и вручную. Я так делал, но это хлопотное занятие, так как сервис многокомпонентный. Не знаю, почему разработчики перестали сами его собирать.
Хорошая новость в том, что всё для сборки образа есть, но придётся это делать самостоятельно. В репозитории Docker Compose файл и краткая инструкция для сборки. Я стал собирать и столкнулся с множеством проблем. Со всеми в итоге разобрался и запустил у себя локальный сервис webpagetest. Рассказываю, как это сделал.
Для начала клонируем к себе репозиторий (он очень большой, 1 ГБ):
В корне лежит файл
Второй момент - не собирался wptagent. Я его просто отключил, так как сам по себе он с сервером не связан. Его можно собрать и подключить отдельно. Так что закомментировал в композе всё, что связано с агентом:
То есть в исходном
Он соберётся и запустится на 80-м порту сервера. Можно зайти по IP адресу. На странице http://172.26.180.29/install/ можно посмотреть информацию об установке и о подключенных агентах. Скорее всего у вас будет проблема с правами доступа на корневую директорию сервера. Я не стал разбираться, от какого пользователя он стартует и какие конкретно права нужны. Для теста просто дал права 0777 на всю папку www в корне репозитория:
Теперь нам нужно подключить агента. Он может быть запущен как тут же в докере, так и на любом другом сервере. В этом и удобство webpagetest. Вы можете запустить сервер и любое количество агентов в разных местах.
На dockerhub есть собранный агент двухлетней давности. Я не стал его использовать, а собрал свежий из репозитория WebPageTest.agent. По инструкции всё собралось без проблем. После этого запускаем агента, прицепив его к нашему серверу. Перед этим нужно один модуль ядра загрузить:
Параметры в переменных обусловлены настройками Location на сервере в момент сборки, которые живут в
Если вам интересен этот сервис, то полное описание настройки есть у меня на сайте. Ни логика работы, ни формат конфигов не изменились. Разница только в том, что контейнеры нужно собирать самому.
#webpagetest
Одно время я много занимался сайтами, в том числе ускорением их работы. И webpagetest использовал постоянно. У меня была и локальная версия, и публичная, с подключением агентов из разных локаций. Я даже в общий доступ выставлял этот сервис и видел, что люди им пользуются.
Решил на днях посмотреть свежую версию и немного расстроился, не увидев готового образа Docker для быстрой установки сервиса. Установить можно и вручную. Я так делал, но это хлопотное занятие, так как сервис многокомпонентный. Не знаю, почему разработчики перестали сами его собирать.
Хорошая новость в том, что всё для сборки образа есть, но придётся это делать самостоятельно. В репозитории Docker Compose файл и краткая инструкция для сборки. Я стал собирать и столкнулся с множеством проблем. Со всеми в итоге разобрался и запустил у себя локальный сервис webpagetest. Рассказываю, как это сделал.
Для начала клонируем к себе репозиторий (он очень большой, 1 ГБ):
# git clone https://github.com/WPO-Foundation/webpagetest.gitВ корне лежит файл
docker-compose.yml, в котором инструкции для сборки с отсылкой к конфигам в docker/local. На момент написания заметки в Dockerfile-php есть проблемы. Я нашёл готовый Pull Request с решением это проблемы с зависимостями. Возможно вскоре он будет принят, но пока рабочий Dockerfile-php можно взять в форке от одного автора. Второй момент - не собирался wptagent. Я его просто отключил, так как сам по себе он с сервером не связан. Его можно собрать и подключить отдельно. Так что закомментировал в композе всё, что связано с агентом:
# agent:# cap_add: #### Allows traffic shapping# - NET_ADMIN# build:# context: .# dockerfile: docker/local/Dockerfile-wptagent# command: python3 wptagent.py -vvvv --xvfb --dockerized --server http://web/work/ --location Test --key 1То есть в исходном
docker-compose.yml закомментировал строки с агентом и полностью заменил файл /docker/local/Dockerfile-php. Далее собрал сервер:# docker-compose upОн соберётся и запустится на 80-м порту сервера. Можно зайти по IP адресу. На странице http://172.26.180.29/install/ можно посмотреть информацию об установке и о подключенных агентах. Скорее всего у вас будет проблема с правами доступа на корневую директорию сервера. Я не стал разбираться, от какого пользователя он стартует и какие конкретно права нужны. Для теста просто дал права 0777 на всю папку www в корне репозитория:
# chmod -R 0777 www/Теперь нам нужно подключить агента. Он может быть запущен как тут же в докере, так и на любом другом сервере. В этом и удобство webpagetest. Вы можете запустить сервер и любое количество агентов в разных местах.
На dockerhub есть собранный агент двухлетней давности. Я не стал его использовать, а собрал свежий из репозитория WebPageTest.agent. По инструкции всё собралось без проблем. После этого запускаем агента, прицепив его к нашему серверу. Перед этим нужно один модуль ядра загрузить:
# modprobe ifb numifbs=1# docker run -d \ -e SERVER_URL="http://172.26.180.29/work/" \ -e LOCATION="Test" \ -e NAME="Test" \ -e KEY="123456789" \ --cap-add=NET_ADMIN \ --init \ wptagentПараметры в переменных обусловлены настройками Location на сервере в момент сборки, которые живут в
docker/local/wptconfig. После этого через пару минут на сервере на странице http://172.26.180.29/install/ вы должны увидеть подключенного агента. После этого сервис полностью готов к выполнению тестов. Если вам интересен этот сервис, то полное описание настройки есть у меня на сайте. Ни логика работы, ни формат конфигов не изменились. Разница только в том, что контейнеры нужно собирать самому.
#webpagetest
Основной вопрос, который возникает при включении прокола HTTPv3 для сайта: "А какая разница с прошлым протоколом? Зачем включать?". Я решил провести некоторые тесты на своём реальном сайте, включая и отключая h3. Для тестов взял хорошо известный мне инструмент WebPageTest и запустил у себя.
Как обычно, он не собрался без ошибок, пришлось поковыряться. Если кому-то интересен этот локальный сервис для теста производительности сайтов, дайте знать. Сделаю по нему свежую заметку, как собрать и запустить самую свежую версию сервера и агента. Его удобно использовать, так как можно запускать локально и исключать влияние сторонних факторов, которые обязательно будут в публичных сервисах.
Запустил я локальную версию WebPageTest на своём сервере и прогнал серию тестов с отключенным h3 и включенным. Для каждого прогона делал по 9 тестов с двумя запусками, когда второй использует кэш после первого запуска. И сравнил результаты, как между одинаковыми тестами в рамках h2 и h3, так и между ними. Различия между однотипными тестами были минимальны. И между h2 и h3 разница была стабильная.
Результаты получились неоднозначными. Поленился поднять локальную копию сайта. Тестировал на рабочем, который опубликован в интернет. Интересно увидеть практические результаты, а не лабораторные. В итоге разница получилась незначительная в пользу h2. Можно сказать в пределах погрешности, кроме одного значения - Time To first Byte и как его следствие - время начала отрисовки Time to Start Render. В режиме h3 она неизменно была выше, чем в h2. То есть дольше приходил ответ на первый запрос, и позже начиналась отрисовка. Параметр TTFB важный с точки зрения СЕО, так что даже не знаю, как реагировать на эти измерения. По идее надо отключать h3.
Внимательно смотрел на результаты и сравнивал. H3 даёт по всем параметрам результаты не хуже h2, а где-то даже лучше. DNS Lookup одинаковый, то есть проседания на DNS запросы нет, Total Connection Time у h3 неизменно ниже, загрузка всех элементов чуть быстрее, но Time to First Byte, за который по идее отвечает непосредственно сервер, всегда у h3 выше и из-за этого едут все остальные метрики, так как и отрисовка, и полная загрузка начинают отставать. Такое ощущение, что причина в реализации h3 в самом веб сервере. Надо тестировать с другими, но это довольно хлопотно, если разворачивать реальный сайт, а не синтетические странички.
Внизу показал результат сравнения, где получилась наиболее усреднённая картинка. Думаю, что разверну сайт отдельно локально и потестирую. Надо понять, в каком режиме всё же лучше оставлять сайты. В целом, с обоими версиями HTTP у меня результат получился хорошим, ниже рекомендованного порога, который считается хорошим результатом. Но всё равно, чем меньше, тем лучше. HTTPv3 пока отключил.
Было бы интересно узнать, если кто-то делал подобные тесты или видел где-то результаты. Нет возможности посвятить много времени этому вопросу, чтобы окончательно разобраться. Один сайт и веб сервер - не показатель. Надо массовые тесты делать.
#webserver #webpagetest
Как обычно, он не собрался без ошибок, пришлось поковыряться. Если кому-то интересен этот локальный сервис для теста производительности сайтов, дайте знать. Сделаю по нему свежую заметку, как собрать и запустить самую свежую версию сервера и агента. Его удобно использовать, так как можно запускать локально и исключать влияние сторонних факторов, которые обязательно будут в публичных сервисах.
Запустил я локальную версию WebPageTest на своём сервере и прогнал серию тестов с отключенным h3 и включенным. Для каждого прогона делал по 9 тестов с двумя запусками, когда второй использует кэш после первого запуска. И сравнил результаты, как между одинаковыми тестами в рамках h2 и h3, так и между ними. Различия между однотипными тестами были минимальны. И между h2 и h3 разница была стабильная.
Результаты получились неоднозначными. Поленился поднять локальную копию сайта. Тестировал на рабочем, который опубликован в интернет. Интересно увидеть практические результаты, а не лабораторные. В итоге разница получилась незначительная в пользу h2. Можно сказать в пределах погрешности, кроме одного значения - Time To first Byte и как его следствие - время начала отрисовки Time to Start Render. В режиме h3 она неизменно была выше, чем в h2. То есть дольше приходил ответ на первый запрос, и позже начиналась отрисовка. Параметр TTFB важный с точки зрения СЕО, так что даже не знаю, как реагировать на эти измерения. По идее надо отключать h3.
Внимательно смотрел на результаты и сравнивал. H3 даёт по всем параметрам результаты не хуже h2, а где-то даже лучше. DNS Lookup одинаковый, то есть проседания на DNS запросы нет, Total Connection Time у h3 неизменно ниже, загрузка всех элементов чуть быстрее, но Time to First Byte, за который по идее отвечает непосредственно сервер, всегда у h3 выше и из-за этого едут все остальные метрики, так как и отрисовка, и полная загрузка начинают отставать. Такое ощущение, что причина в реализации h3 в самом веб сервере. Надо тестировать с другими, но это довольно хлопотно, если разворачивать реальный сайт, а не синтетические странички.
Внизу показал результат сравнения, где получилась наиболее усреднённая картинка. Думаю, что разверну сайт отдельно локально и потестирую. Надо понять, в каком режиме всё же лучше оставлять сайты. В целом, с обоими версиями HTTP у меня результат получился хорошим, ниже рекомендованного порога, который считается хорошим результатом. Но всё равно, чем меньше, тем лучше. HTTPv3 пока отключил.
Было бы интересно узнать, если кто-то делал подобные тесты или видел где-то результаты. Нет возможности посвятить много времени этому вопросу, чтобы окончательно разобраться. Один сайт и веб сервер - не показатель. Надо массовые тесты делать.
#webserver #webpagetest
Для тестирования скорости загрузки сайта существует старый и известный в узких кругах инструмент WebPageTest. Упоминал уже не раз о нём, потому что регулярно пользуюсь, но отдаю себе отчёт, что он не очень популярен. На днях ставил себе с нуля свежую версию и потратил пол дня, пока всё запустил на своей виртуалке. Проект развивается в плане кодовой базы и возможностей, но конкретно Private Instances, которые можно развернуть у себя и использовать без ограничения, ставятся с костылями, так как для них не обновляют документацию и Docker файлы.
В очередной раз всё развернул и сразу зафиксирую, чтобы не забыть. Так как в прошлый раз решал ровно те же проблемы, но не записал сразу, потом забыл. Пришлось опять разбираться.
Проект состоит из серверной части и агентов, которые могут быть развёрнуты в разных локациях. Репозитории:
⇨ https://github.com/catchpoint/WebPageTest
⇨ https://github.com/catchpoint/WebPageTest.agent
В первом есть
Клонируем репозиторий сервера:
В
После этого собираем. Можно не трогать настройки по умолчанию.
После сборки запустится серверная часть на 80-м порту. Можно идти браузером по IP адресу сервера. Состояние сервера можно посмотреть так: http://10.20.1.21/install/ Там должно быть всё зелёное. И видно, что есть одна локация Test Locations и нет подключенного агента. Это настройка по умолчанию, она задаётся в файле
Идём на машину, где будет запускаться агент. Клонируем репозиторий:
В корне лежит Dockerfile. Откройте его и измените следующую строку:
На
Отдельно npm ставить не надо, он входит в состав nodejs. Сборка будет валиться с ошибкой, если это не исправить. Собираем агента. Я сразу указал ему часовой пояс. Можно и другие параметры задать:
Если сборка прошла без ошибок, то можно запускать самого агента:
10.20.1.21 - IP адрес сервера. Через пару минут по ссылке http://10.20.1.21/install/ вы должны увидеть, что агент подключился. В логе сервера это будет видно по запросам на /work/getwork.php от IP адреса агента.
Теперь можно выполнять тесты сайтов с помощью этого агента. Мне это нужно было, чтобы протестировать последние изменения в Angie. Авторы указали, что повысили стабильность работы с протоколом HTTP/3. Напомню, что когда я включил в Angie протокол HTTP/3, заметил, что параметр TTFB увеличился. В тестах это стабильно воспроизводилось.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webpagetest
В очередной раз всё развернул и сразу зафиксирую, чтобы не забыть. Так как в прошлый раз решал ровно те же проблемы, но не записал сразу, потом забыл. Пришлось опять разбираться.
Проект состоит из серверной части и агентов, которые могут быть развёрнуты в разных локациях. Репозитории:
⇨ https://github.com/catchpoint/WebPageTest
⇨ https://github.com/catchpoint/WebPageTest.agent
В первом есть
docker-compose.yml, который включает в себя php-бэкенд, веб-интерфейс и агент. Контейнеры собираются по месту из представленных докерфайлов в папке docker/local. Если взять этот проект и запустить, то не соберётся wptagent. В нём есть привязки к названию репозитория, где он раньше был, но имя репозитория поменяли, а тут ничего не поправили. Проще собрать агента отдельно, а тут исключить его из сборки. К тому же агент будет запускаться не только на этой машине, так что разнести их не только географически, но и логически - разумно.Клонируем репозиторий сервера:
# git clone https://github.com/catchpoint/WebPageTestВ
docker-compose.yml комментируем всё, что относится к agent. Это в самом конце секция, после web и php. Собранный веб сервер будет много всего писать в директорию www/ в разные вложенные папки. Для простоты назначим ей права 0777:# chmod -R 0777 www/После этого собираем. Можно не трогать настройки по умолчанию.
# docker compose upПосле сборки запустится серверная часть на 80-м порту. Можно идти браузером по IP адресу сервера. Состояние сервера можно посмотреть так: http://10.20.1.21/install/ Там должно быть всё зелёное. И видно, что есть одна локация Test Locations и нет подключенного агента. Это настройка по умолчанию, она задаётся в файле
docker/local/wptconfig/locations.ini. Там только один тестовый location с ключом доступа 123456789. Если будете строить распределённую сеть агентов, то нужно будет добавлять туда новые локации и подключать агентов в соответствии с названиями и ключами.Идём на машину, где будет запускаться агент. Клонируем репозиторий:
# git clone https://github.com/catchpoint/WebPageTest.agentВ корне лежит Dockerfile. Откройте его и измените следующую строку:
RUN curl -sL https://deb.nodesource.com/setup_20.x | bash - && \ apt-get install nodejs npm -yНа
RUN curl -sL https://deb.nodesource.com/setup_20.x | bash - && \ apt-get install nodejs -yОтдельно npm ставить не надо, он входит в состав nodejs. Сборка будет валиться с ошибкой, если это не исправить. Собираем агента. Я сразу указал ему часовой пояс. Можно и другие параметры задать:
# docker build --tag wptagent --build-arg TIMEZONE=MSK .Если сборка прошла без ошибок, то можно запускать самого агента:
# modprobe ifb numifbs=1# docker run -d -e SERVER_URL="http://10.20.1.21/work/" -e LOCATION="Test" -e NAME="Test" -e KEY="123456789" --cap-add=NET_ADMIN --init --name wptagent wptagent10.20.1.21 - IP адрес сервера. Через пару минут по ссылке http://10.20.1.21/install/ вы должны увидеть, что агент подключился. В логе сервера это будет видно по запросам на /work/getwork.php от IP адреса агента.
Теперь можно выполнять тесты сайтов с помощью этого агента. Мне это нужно было, чтобы протестировать последние изменения в Angie. Авторы указали, что повысили стабильность работы с протоколом HTTP/3. Напомню, что когда я включил в Angie протокол HTTP/3, заметил, что параметр TTFB увеличился. В тестах это стабильно воспроизводилось.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webpagetest