Клиентская производительность – бесконечный процесс. Разрабатываются новые фичи, меняется дизайн, технологии, браузеры – контролировать скорость нужно постоянно.
Здесь есть два принципиальных направления: синтетические тесты в тестовом окружении и сбор метрик у реальных пользователей. Оба этих направления важны, но мы сконцентрируемся на синтетических тестах и будем использовать их для оценки влияния изменений в приложении на клиентскую производительность как часть процесса тестирования.
Проверка на прочность или нагрузочное тестирование с JmeterAleksey Derkach
Мой доклад на второй мини-конференции компании Anadea в феврале 2015 года. Обобщение опыта, полученного в результате проведения полноценной сессии нагрузочного тестирования Web-приложения с использованием Jmeter.
При проектировании нагруженных систем приходится сталкиваться с тем, что разные типы запросов к веб-серверам затрачивают разное количество ресурсов, выполняются за разное количество времени и имеют разные приоритеты выполнения. Некоторые запросы «стоят» мало и должны выполняться как можно быстрее. Некоторые «стоят» дорого, и главное, чтобы они не блокировали обработку быстрых запросов. Существующие схемы приоритезации показались нам громоздкими и неудобными – при росте количества типов запросов конфигурация системы усложнялась в разы. Поэтому, чтобы решить эту проблему, а также для того, чтобы сделать ответы на запросы еще более быстрыми, мы написали свой веб-сервер – Phantom. Я расскажу вам, как он устроен, покажу, какие задачи можно решать с его помощью, а в завершение покажу на практике, как работает приоритезация разных типов запросов, используя для этого инструмент нагрузочного тестирования, основанный на Phantom.
Проверка на прочность или нагрузочное тестирование с JmeterAleksey Derkach
Мой доклад на второй мини-конференции компании Anadea в феврале 2015 года. Обобщение опыта, полученного в результате проведения полноценной сессии нагрузочного тестирования Web-приложения с использованием Jmeter.
При проектировании нагруженных систем приходится сталкиваться с тем, что разные типы запросов к веб-серверам затрачивают разное количество ресурсов, выполняются за разное количество времени и имеют разные приоритеты выполнения. Некоторые запросы «стоят» мало и должны выполняться как можно быстрее. Некоторые «стоят» дорого, и главное, чтобы они не блокировали обработку быстрых запросов. Существующие схемы приоритезации показались нам громоздкими и неудобными – при росте количества типов запросов конфигурация системы усложнялась в разы. Поэтому, чтобы решить эту проблему, а также для того, чтобы сделать ответы на запросы еще более быстрыми, мы написали свой веб-сервер – Phantom. Я расскажу вам, как он устроен, покажу, какие задачи можно решать с его помощью, а в завершение покажу на практике, как работает приоритезация разных типов запросов, используя для этого инструмент нагрузочного тестирования, основанный на Phantom.
Григорий Липин: Автоматизация нагрузочного тестированияYandex
Доклад посвящен нагрузочному тестированию. Мы поделимся своим опытом и расскажем, как автоматизировать нагрузочное тестирование с помощью инструмента Яндекс.Танк.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Часто о нагрузочном тестировании рассказывают через призму используемого инструментария, хорошо раскрывая слово «нагрузочное» и часто оставляя слово «тестирование» за кадром. Так давайте же попробуем поговорить о месте именно тестирования в нагрузочном тестировании.
Жизнь проекта на production советы по эксплуатации / Николай Сивко (okmeter.io)Ontico
Ваш сайт или другой проект приносит деньги только тогда, когда он работает.
Нельзя просто выложить код на серверы, залить схему в базу данных и делегировать домен.
Будем говорить о планировании отказоустойчивости и мониторинге проектов:
- оцениваем риски отказа различных компонентов;
- какие-то из вероятных проблем просто мониторим и планируем действия при сбоях;
- проблемы, которых можно избежать легко и дешево, закрываем сразу.
Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.
Бодрящий микс из Selenium и TestNG- регрессионное тестирование руками разрабо...Andrey Rebrov
Как-то так происходит, что “на 10 девчонок по статистике 9 ребят”, а точнее на группу из 5-7 разработчиков – 1 тестировщик. Или его нет совсем. Так что очень часто приходится и код писать, и тестировать, а дата релиза все ближе и ближе.
В тех случаях, когда мы пишем веб-приложение, помочь в нашей нелегкой судьбе может бодрящий микс из Selenium и TestNG... Как это сделали мы, какие потом получили выводы и результаты — все это я и хочу рассказать и показать
Monitoring driven эксплуатация / Николай Сивко (HeadHunter)Ontico
Огромная часть работы службы эксплуатации, так или иначе, связана с мониторингом существующей инфраструктуры.
Если система мониторинга настроена хорошо, она позволяет сократить время простоя, какие-то проблемы показать на ранней стадии, формализовать рабочие процессы команды админов.
То есть она является носителем знания о нашей инфраструктуре и о том, как именно работают админы.
Можно ли извлечь дополнительную пользу из этого?
В hh.ru мы используем систему мониторинга ещё и как check list для повседневных задач админов (алерты в данном случае являются задачами для человека: сделал задачу - триггер проверил результат и погас), идея взята из TDD.
Также расскажу, как мы работаем с внештатными ситуациями: реагируем на алерты, чиним, разбираем и классифицируем.
Еще на основе разобранных инцидентов мы считаем показатели работы службы эксплуатации, из этих показателей высчитываются наши премии (данный KPI получился удачным: с ним согласен и бизнес и админы).
Ангелы и демоны многопоточного программирования / Алексей Федоров (Одноклассн...Ontico
Современные процессоры имеют на борту по нескольку вычислительных ядер, позволяющих запускать задачи на них параллельно. И, казалось бы, вот оно — счастье: бей большие задачи на куски, запускай эти куски параллельно на разных ядрах и радуйся.
Но не все так просто. Для того чтобы одновременный доступ к общим данным выполнялся корректно, современные системы используют разные примитивы синхронизации. В основе одних лежат блокировки (locks), в основе других — операции типа сравнение-с-обменом (compare-and-swap). Однако и у тех и у других есть свои слабые места. О них мы и поговорим.
Из доклада вы узнаете, чем блокирующие алгоритмы отличаются от неблокирующих, и какими достоинствами и недостатками обладает каждый из этих классов. Кроме того, будут показаны различные подводные камни тех и других решений: Deadlock, Livelock, Starvation, Mutable vs Immutable hype.
Григорий Липин: Автоматизация нагрузочного тестированияYandex
Доклад посвящен нагрузочному тестированию. Мы поделимся своим опытом и расскажем, как автоматизировать нагрузочное тестирование с помощью инструмента Яндекс.Танк.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Часто о нагрузочном тестировании рассказывают через призму используемого инструментария, хорошо раскрывая слово «нагрузочное» и часто оставляя слово «тестирование» за кадром. Так давайте же попробуем поговорить о месте именно тестирования в нагрузочном тестировании.
Жизнь проекта на production советы по эксплуатации / Николай Сивко (okmeter.io)Ontico
Ваш сайт или другой проект приносит деньги только тогда, когда он работает.
Нельзя просто выложить код на серверы, залить схему в базу данных и делегировать домен.
Будем говорить о планировании отказоустойчивости и мониторинге проектов:
- оцениваем риски отказа различных компонентов;
- какие-то из вероятных проблем просто мониторим и планируем действия при сбоях;
- проблемы, которых можно избежать легко и дешево, закрываем сразу.
Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.
Бодрящий микс из Selenium и TestNG- регрессионное тестирование руками разрабо...Andrey Rebrov
Как-то так происходит, что “на 10 девчонок по статистике 9 ребят”, а точнее на группу из 5-7 разработчиков – 1 тестировщик. Или его нет совсем. Так что очень часто приходится и код писать, и тестировать, а дата релиза все ближе и ближе.
В тех случаях, когда мы пишем веб-приложение, помочь в нашей нелегкой судьбе может бодрящий микс из Selenium и TestNG... Как это сделали мы, какие потом получили выводы и результаты — все это я и хочу рассказать и показать
Monitoring driven эксплуатация / Николай Сивко (HeadHunter)Ontico
Огромная часть работы службы эксплуатации, так или иначе, связана с мониторингом существующей инфраструктуры.
Если система мониторинга настроена хорошо, она позволяет сократить время простоя, какие-то проблемы показать на ранней стадии, формализовать рабочие процессы команды админов.
То есть она является носителем знания о нашей инфраструктуре и о том, как именно работают админы.
Можно ли извлечь дополнительную пользу из этого?
В hh.ru мы используем систему мониторинга ещё и как check list для повседневных задач админов (алерты в данном случае являются задачами для человека: сделал задачу - триггер проверил результат и погас), идея взята из TDD.
Также расскажу, как мы работаем с внештатными ситуациями: реагируем на алерты, чиним, разбираем и классифицируем.
Еще на основе разобранных инцидентов мы считаем показатели работы службы эксплуатации, из этих показателей высчитываются наши премии (данный KPI получился удачным: с ним согласен и бизнес и админы).
Ангелы и демоны многопоточного программирования / Алексей Федоров (Одноклассн...Ontico
Современные процессоры имеют на борту по нескольку вычислительных ядер, позволяющих запускать задачи на них параллельно. И, казалось бы, вот оно — счастье: бей большие задачи на куски, запускай эти куски параллельно на разных ядрах и радуйся.
Но не все так просто. Для того чтобы одновременный доступ к общим данным выполнялся корректно, современные системы используют разные примитивы синхронизации. В основе одних лежат блокировки (locks), в основе других — операции типа сравнение-с-обменом (compare-and-swap). Однако и у тех и у других есть свои слабые места. О них мы и поговорим.
Из доклада вы узнаете, чем блокирующие алгоритмы отличаются от неблокирующих, и какими достоинствами и недостатками обладает каждый из этих классов. Кроме того, будут показаны различные подводные камни тех и других решений: Deadlock, Livelock, Starvation, Mutable vs Immutable hype.
Este documento fue elaborado en el marco del proyecto "Tocando Las Estrellas", el que contó con financiamiento del Gobierno Regional Metropolitano de Santiago, a través del su Fondo Regional de Cultura equivalente al 2% del presupuesto FNDR regional.
Что, зачем и каким образом следует проверять и тестировать перед запуском сай...Alexey Kostin
Презентация к докладу Алексея Костина Drupal CIS 2013 в Москве — «Что, зачем и каким образом следует проверять и тестировать перед запуском сайта на Drupal в публичную эксплуатацию»
Vadim Zubovich. Comaqa Spring 2018. Красивое тестирование производительности.COMAQA.BY
Все, кто когда-либо сталкивался с тестированием производительности, прекрасно знают, как сложно сделать отчеты понятными, хорошо визуализированными и прозрачными для заказчика. Очень важно выбрать "правильные" метрики и разработать нужные профили нагрузки, но если в результате заказчик увидит скучные и непонятные кривые на белом фоне, он вполне может отказаться от тестирования производительности как такового, поскольку результат будет не вполне прозрачен. Давайте посмотрим, как можно улучшить впечатление от результатов тестирования производительности, на примере интеграции JMeter с мощным инструментом визуализации - Grafana.
21 октября состоялась 1 встреча одесского сообщества Python-разработчиков - Python Meetup.
Поговорили о новых технологиях, диалектах и инструментарии для создания графических интерфейсов.
Докладчики:
Александр Степанов (Python Team Lead at SteelKiwi Inc.)
Тема: Шаблон проекта. Использование Vagrant, VirtualEnv и Ansible provisioner. Зачем это необходимо?
Евгений Гетманский (Рython team lead at SteelKiwi Inc.)
Тема: Оптимизация работы веб сервера с базой данных на примере Django.
В докладе речь пойдёт об основных принципах разработки и обеспечения отказоустойчивости в системах, развёртываемых в облаках.
Рассмотрим следующие темы:
- что такое отказоустойчивые системы;
- классификация возможных сбоев на уровне приложения и на уровне инфраструктуры;
- подходы к обеспечению отказоустойчивости;
- анализ и верификация отказоустойчивости;
- TheButcher как инструмент обеспечения отказоустойчивости.
Также увидим сравнение вживую отказоустойчивой и отказонеустойчивой систем, развёрнутых на OpenStack.
Автоматизация нагрузочного тестирования в связке JMeter + TeamСity + Grafana ...Positive Hack Days
1. Описание старого процесса сбора данных о тестах: как было до, что хорошего, что плохого
2. Influxdb, как хранилище time-series данных,
3. Zabbix - мониторинг нагрузочных стендов: windows и linux агенты, активный сбор данных, autodiscovery виртуальных машин в esx
4. Grafana, как способ превратить графики и дашборды в конфетку
5. Автоматизация нагрузки от пользователей через web-UI при помощи Jmeter, отображение статистики в реальном времени, CI в Teamcity
Как построить свой фреймворк для автотестов?Dmitry Buzdin
Мы пройдемся по всем основным блокам построения тестового фреймворка и тому, как они связаны между собой. Вы научитесь собирать свое решение по автоматизации из библиотек с открытым кодом и делать так, чтобы они дополняли друг друга.
Dev&Test на Windows Azure IaaS:
* Что за Dev&Test? Ситуации Dev&Test
* Как делать D&T на Windows Azure?
* Как делают люди?
* Ограничения Windows Azure, которые важны
* Топологии
4. Зачем автоматизация?
• Код приложения меняется
• Выявлять проблемы до релиза кода
• Ручное тестирование не подходит
• Контролируемое окружение
• Бюджет
5. Что мы хотим знать
• Время загрузки
• Время рендеринга
• Различие для состояния кэша
• Влияние сети
• Нет ли деградации?
• Есть ли проблемы конфигурации?
13. Patrick Meenan
• Главный разработчик WebPagetest
• Патриарх движения веб-производительности
• Много полезных видео о WPT:
https://www.youtube.com/user/patmeenan/videos
16. WebPagetest Private Instance
• То же, но на своей инфраструктуре
• Полный контроль
• Есть поддержка агентов на Amazon EC2
• Open source (BSD):
https://github.com/WPO-Foundation/webpagetest
17. Location 1
Как это работает WPT PI сервер
Тестовый агент
(Windows)
Тестовый агент
(Windows)
18. Что мы получаем из коробки
• Параметры сети
• Chrome, Firefox, IE
• Сбор метрик
• Сбор скриншотов и видео
• Очистка кэша (включая SSL, DNS)
19. Тестирование на мобильных
устройствах
• Есть поддержка Android 4.4+ (Chrome)
• Есть поддержка iOS (сырая)
• Слабо документировано
• Проблемы стабилизации
• Заменяем на эмуляцию + ограничение CPU
25. Компоненты системы
• Очередь заданий с сохранением статусов
• Сервер WPT PI
• Обработчик результатов
Очередь заданий WPT PI сервер
Тестовый агент
(Windows 7)
Обработчик
результатов
26. Сценарий использования
• Точки входа
• Бюджет (эталон)
• Тесты
• Сравнение результатов
• Если проблема – alert
• Прикладываем URL WPT
• Исправляем
27. Запрос на тестирование
• POST-запрос на http://wptdomain/runtest.php
• url — что тестировать
• location — тестовый агент (включая браузер и сеть)
• runs — количество тестов
• fvonly – тестировать только FirstView
• video — захват скриншотов и видео
• f — формат данных (XML или JSON)
30. Ситуация №1 – конфигурация и контент
• Текст отдаётся без сжатия
• Статика не кэшируется
• Нет keep-alive
• Настройки TLS?
• Картинки не оптимизированы
31. Метрики WPT — оптимизация
minify_savings, gzip_savings, image_savings (JSON)
Осторожно: image_savings рассчитывается от JPEG-качества ~70%,
уровень сжатия gzip не учитывается
Можно дополнить оценкой GPSI (png, gif, jpg)
32. Метрики WPT — трафик по типам
breakdown→(css|html|js|font|image)->bytes (JSON)
39. Метрики WPT — Speed Index
Speed Index (SpeedIndex — JSON) – чем меньше, тем лучше
𝑆𝑝𝑒𝑒𝑑𝐼𝑛𝑑𝑒𝑥 =
0
𝑒𝑛𝑑
1 −
𝑉𝐶
100
40. Ситуация №4 – зависимость от внешних API
• Нет стабильности результатов
• Внешние ресурсы (JS API, счетчики, виджеты)
Решение
• Блокируем запросы по хостам
• Параметр block (хосты через пробел)
• Локальный кэш
41.
42. Ситуация №5 – CPU-bound
• Большое количество DOM-элементов, JS
• Сложный рендеринг
Решение
• Снимаем ограничение сети
• Увеличиваем количество прогонов
43. Метрики WPT — CPU
docCPUms (JSON) — затраты CPU на частичную загрузку
fullyLoadedCPUms (JSON) — затраты CPU на полную загрузку
docCPUpct, fullyLoadedCPUpct (JSON) – средний процент CPU
cpuTimes, cpuTimesDoc (JSON) – время CPU из DevTools timeline
44. Метрики WPT - DOM
domContentLoadedEventStart,
domContentLoadedEventEnd (JSON) – начало и конец события
domContentLoaded
45. Метрики WPT — load event
Load Time (loadTime — JSON) – время до начала события load
Включает в себя время TTFB (First Byte).
Чтобы исключить, можно использовать: loadTime — TTFB
46. Добавляем кастомные метрики
• Для одного запуска (параметр custom)
[iframe-count]
return document.getElementsByTagName("iframe").length;
[script-tag-count]
return document.getElementsByTagName("script").length;
• Постоянные метрики (в settings/custom_metrics/iframe-count.js)
47. Проблемы WPT PI (1)
Нестабильность результатов
• увеличение количества прогонов
• использование медианного варианта теста
• оптимизация Windows тестового агента
• расположение агента рядом с приложением
• блокирование запросов на внешние сервисы
48. Проблемы WPT PI (2)
Ресурсоёмкость проведения тестов
• Распределяем нагрузку на несколько агентов (сами)
• Меняем настройки тестов (убираем захват видео, количество
прогонов, скорость сети)
Безопасность и обслуживание
• Обновление агентов (обязательно, регулярно)
• Обновление Windows
• Мониторинг (зависшие агенты — перезагрузка)
49. Подходит
• Внутренний мониторинг скорости
• Сравнение с конкурентами
• Тестирование изменений, технологий
• Оценка уровня оптимизации
50. Не подходит
• Тестирование микроизменений (до 200 мс)
• Тестирование серверной производительности
• Нагрузочное тестирование, эмуляция действий реальных
пользователей