Pandora -- экспериментальная пушка на Golang, которая умеет SPDY и которую хочется научить стрелять lua/js-сценариями

 

А в каком сейчас состоянии Pandora ? Она полностью готова для продакшена? Послений коммит был Feb 11, 2016

Она, как и BFG умеет в логику?

Делали замеры сколько rps у BFG и Pandora максимум?

 

Pandora сейчас -- это прототип новой стрелялки.

На ней я пробовал SPDY делать, там архитектура другая по сравнению с фантомом, можно более детально управлять каждой сессией. Потом мы померили SPDY и HTTP/2 в реальных условиях (замеряли хождения на top 15 интернета, включая FB, Wikipedia) -- и не увидели большого профита от них. Соответственно, пушку SPDY и HTTP/2 отложили до лучших времен.

Хочется заменить этой пушкой phantom, потому что в ней больше возможностей и ей не нужны заранее сгенеренные патроны, а это сэкономит нам время и место. Поэтому первое, что там появится -- это полноценный HTTP. В HTTP я достреливал до 50 000 RPS. Упирался в JSON decoder -- патроны сейчас читаются из JSON. Хочу переделать на фантомовский формат -- должно стать еще быстрее.

Логику сейчас не умеет, но есть идея вкрутить туда lua/js. Естественно, это будет быстрее, чем BFG.

В прод пока ее не стоит, вот прикрутим новый формат патронов, потом мы у себя попробуем -- можно будет. Еще dropbox обещал прислать патчи с оптимизацией производительности. Заняты все пока другими делами.

BFG -- порядка 10 000 в HTTP, но за ней нужно пристально следить, потому что можно упереться в питон в неожиданных местах. Особенно если какой-то свой протокол.

 

Для кого-то JMeter -- юзер френдли, но для меня -- совсем нет. Программировать в GUI -- это адский ад, малейшее изменение влечет кучу кликов мышкой. И копипастить не получится.

Хочется инструмент с современным и понятным интерфейсом

с одной стороны вы хотели крутой и современный юзер-интерфейс, а с другой стороны сделали только программное управление на питоне. не совсем понятно получается что вы хотели

 

Программное управление на Питоне -- это очень современно. Питон сейчас везде, в администрировании, в программировании, в DataScience. Почему бы ему не быть в нагрузочном тестировании?

Плюс опять же, у нас есть танки в облаке и старт тестов через вебформу. Тоже современно.

 

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

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

 

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

 

Кстати говоря, у нас отдел тестирования -- 15 чел на весь Яндекс.

Агаааа... Попался!!!
1) "Карты" просчитывая маршрут на общественном транспорте указывают время без учета пробок. Уже, наверное, год как.
2) "Транспорт" регулярно миксует координаты этого транспорта в итоге на экране трамвай едет боком по улице на которой и рельсов то нет, а потом волшебным образои превращается в местный автобус.
3) "Маркет" в результатах поиска показывает товар, которого при ближайшем рассмотрении нет. Обнаружено недавно на редких ноутах, но баг похоже очень старый, регулярно в списке отсортированном по ценам не вижу нижней цены из поисковой выдачи.
4) "Погода" на мобилке требовала сложного танца с бубном чтоб перестать показывать позавчерашнюю погоду и показать уже сегодняшнюю, хотя она недавно сильно поменялась и вроде баг ушел.

 

Спасибо за фидбек, я передам в сервисы +) Я имел в виду нагрузочное тестирование, функциональные баги вне нашей компетенции. И функциональщиков у нас больше 15-ти, я не знаю сколько. Хотя мы (нагрузочники) хотим придумать очень клевое автоматическое тестирование на мобильниках, которое и функциональным тоже будет.

танк, насколько я понимаю - это платформа для нагрузочного тестирования, с аналитикой

 

к ней подключаются генераторы нагрузки - например, phantom, JMeter и другие

Все верно.

phantom -- C++, очень быстрая стрелялка, до 100 тысяч запросов в секунду, но можно стрелять только заранее приготовленными логами, нельзя генерить запросы прямо в процессе стрельбы

JMeter -- вы и так знаете +)

BFG -- стрельба сценариями на питоне

Pandora -- экспериментальная пушка на Golang, которая умеет SPDY и которую хочется научить стрелять lua/js-сценариями

 

 

В этом, наверное, и суть - иметь инструмент, с которым можно было бы быстро и удобно работать.

У нас, например, отдел тестирования порядка 20 человек. И не всегда в нужный момент можно задействовать тех специалистов, которые являются продвинутыми в нагрузочном тестировании. Есть естественное желание, снизить порог входа в данную тему.

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

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

 

Самый удобный интерфейс для создания сценариев -- у Лоад Раннера. Нажал на запись, потыкал -- пожалуйста, сценарий. Проблема у них в том, что все остальное из 90-х, а в сценариях используется C (не соответствующий общепринятому стандарту) и Java (тоже с расхождениями со стандартом). Сложно настраивать схемы нагрузки, мониторинг, итд. Сложно с результатами работать. И главное, сторонние тулзы нельзя использовать, потому что в формате выходных данных нетривиально разобраться.

Отсюда две идеи:

-- либо научиться заливать данные ЛП в overload

-- либо научиться "записывать" сценарии на питоне (или lua, или javascript)

Танк модульный, сценарии сможет исполнять -- сейчас уже можно на питоне (мы так, кстати, в мобильники стреляем), есть идея прикрутить еще lua или js.

Кстати говоря, у нас отдел тестирования -- 15 чел на весь Яндекс. Но большую часть тестов гоняют разработчики и админы, т.е. порог входа у нас очень низкий. У нас есть сервис для стрельб -- заходишь, поля в формочке заполняешь, нажимаешь "пострелять".

Еще есть очень много автоматизированных (полностью) стрельб, которые гоняются на каждый релиз. Сами, без участия людей. Задача наших нагрузочников, чаще всего, не "потестировать", а "сделать автоматическое тестирование".

 

Для тех кто в танке: Если вылезти из танка и оглянутся, то вы как раз и увидите тот самый неназванный инструмент. Да-да, Яндекс.Танк.

Алексей, а это собственный интерфейс поверх графита или какая-нибудь графана затюненая?

 

У нас свой интерфейс на джанге, бэкэнд -- Кликхаус. Графит такое точно не потянет (я делал плагин для заливки в графит, там таймлайны непрерывные, т.е. пока вы не тестите -- там нули будут). Еще был вариант InfluxDB, но кликхаус в итоге подошел намного лучше.

яндекс.танк на питоне

непонятно, почему сразу нельзя было написать, что речь идет о яндекс.танке

Я почему-то подумал, что не очень прилично будет так неприкрыто рекламить свой продукт. Хотя с другой стороны, это опенсорс. Да, речь о Яндекс.Танке.

Так вы с пользовательским интерфейсом сделали, гибким юзер-френдли и понятным, лучше чем у JMeter?

Для кого-то JMeter -- юзер френдли, но для меня -- совсем нет. Программировать в GUI -- это адский ад, малейшее изменение влечет кучу кликов мышкой. И копипастить не получится.

Самый юзер френдли интерфейс, как мне кажется, у LoadUI. Тормозит только +)

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

Если уж делать GUI для настройки генератора, то в виде web-обертки над облаком генераторов нагрузки. Такое тоже делаем, но я бы не сказал, что там сейчас чудеса UI-дизайна. Хотя пользователям хватает того, что есть, на это не жалуются.

 

 

как отображаете графики для разных типов запросов

Графики такие.

 

 

а чем JMeter не устроил если не секрет? какие были причины?

Хочется инструмент с современным и понятным интерфейсом, с минимальным порогом вхождения, гибкими настройками и широкой системой интеграции. А jmeter в этот плане совсем не userfriendly, довольно сложный в освоении и поддержке, ресурсоёмкий. Нет привязки скриптов к тестовой документации. Не нравится, что нет полноценной визуализации результатов из коробки.

 

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

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

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

Я не хочу сказать что у вас все будет именно так, но прежде чем изобретать свой велосипед разберитесь почему существующие таковы как они есть.

 

Наш инструмент показывает в процессе генерации нагрузки:

1. график распределения времен ответа

2. график квантилей времен ответа

3. распределение сетевых и http кодов ответов

4. полсотни метрик мониторинга

Так что все возможно. Хотя это конечно не велосипед уже.