Хорошая у вас память, по годам помните. Когда вспоминаю Ижевск, то вижу большие тихие кабинеты НПО. В Москве такой тишины не хватает, тут плотнее.
А про автомобиль (это из заключительной скрытой части) такое мнение, обратное — в Ижевске машина мне была нужна. Для удовольствия, просто потому, что её приятно водить. В Москве машина уже не столь нужна, расходов больше. Метро и другой общественный транспорт удобнее.
Привет, rahna.
Могу посоветовать попробовать YAML-синтаксис. Он не будет уступать текстовому представлению по понятности. И кроме того, тесты в таком представлении можно будет сразу же запускать, используя taurus.
Здравствуйте. Интересная статья. Коллеги на одном из проектов пробовали сделать такое. Cucumber для нагрузки. Доступность облаков будила фантазию. Но не сделали — это не для всех задач подходит.
На другом проекте также использовали функциональные тесты, уже успешно и регулярно. Но не для нагрузки в широком смысле понимания, а как индикатор появления узких мест после внесения небольшой изменений в проект. Думаю, как и у Антона Косякина. Подход такой:
запуск тестов + сбор метрик производительности (длительность выполнения, память, процессор, количество error/warn/info/debug в логе)
изменение системы
запуск тех же тестов + сбор метрик производительности
сравнение метрик от теста 1 и 2 на одном графике — и так от сборки к сборке
Такой вариант хорошо работает. Если показатели производительности ухудшились, то причина скорее всего в функциональности и изменениях, которые были между запусками тестов. То есть — причина более-менее локализована. Это плюс. И очень быстрая обратная связь разработчикам — это самый главный плюс. Они не боятся вносить изменения в код.
Из минусов — нет точного понимания, какие будут показатели RPS (запросов в сек), TPS (операций в сек). Ведь функциональный тест может зависнуть, и если вчера за минуту выполнялось 60 тестов (1 TPS), то сегодня выполняется только 1 тест в минуту (1/60 TPS) — то есть нагрузка на систему подаётся в 10 раз меньшая, и результаты запусков не сравнимы. Предположу, что в данном подходе такое может случиться. Это открытая модель нагрузки. В JMeter/Gatling/Yandex.Tank контроль TPS/RPS — решаемая задача, с понятными ограничениями.
Также, достаточно дорого поддерживать много генераторов нагрузки, если она подаётся браузером — браузер требует очень много оперативной памяти, JMeter требует сильно меньше, а Gatling, так как гораздо меньше потоков, требует ещё меньше памяти. Для реализации нагрузки 100 операций в минуту через браузер (много)/http-api-robot (только аутентификация), может понадобится 20 станций. С ростом потребностей (1000 операций в минуту), доля http-api-robot будет расти, а доля браузера снижаться. А потом (10 000 операций в минуту) и вовсе решите перейти на модель, когда всю нагрузку подаёт 4 станции с Gatling/JMeter, и ещё на одной параллельно выполняется функциональный тест в BDD-формате — для оценки отзывчивости интерфейса под высокой нагрузкой.
Спасибо, за статью. Заголовки могут служить каркасом оценки кандидатов: «Кандидат коммуникабелен, основ тестирования не знает, обладает знаниями языка Java, претендует на лидирующие позиции». Приведённые факторы встречаются в разном сочетании.
В команде нужны разные люди — весёлый, терпеливая, умный, в платье, с бородой,… и гитарист. Это шутка, в которой лишь доля шутки. А для сложных систем нужны команды.
Пример подхода — если есть на входе список из 7-ми целей, выбираю три наиболее интересные и важные основываясь на интуиции. Цели соответствуют SMART и их три.
На что обратить внимание при формировании и выборе целей?
Такое видел. Лимиты заранее не известны даже руководителям. И может случиться так, что завершилась оценка, отправлено обоснование повышений команды руководителю, он согласует, уже оглашает команде даты и суммы. А потом выясняется, что о-па и упс, лимиты есть.
Бюджет надо заранее выяснять, просчитывать.
Вообще, общий подход, принятый во многих больших компаний — это постановка целей. Цели не только получают ранг, степень выполнения, но и степень влияния на команду, отдел и бизнес целиком
Спасибо за акцент на степени влияния на команду и бизнес. Думаю стоит оценить этот фактор, не выделял его явно
Вопрос про вопрос «что должен знать мидл?». Один из комментариев раскрывает один из способов повышения — смена проекта или компании. А если говорить про вариант работы на том же проекте, то такой вопрос задаёт себе каждый лид.
Кто-то использует матрицы компетенций, различные профили специальностей, наборы курсов и систему их прохождения с получением баллов. Ещё есть оценка 360, просто разговоры по душам. И это только начало.
Понятно, что система повышения должна быть прозрачной и справедливой. И что это большой труд.
Здравствуй, Сергей. Спасибо за статью. Отдельное спасибо за "${}" и Just magic с анонимной функцией. И за примеры.
Написал сценарий с профилем: поднять нагрузку до 20 сценариев в сек, и подержать ее такой час.
rumpUsersPerSec(0) to (20) during (5 minutes),
constantUsersPerSec(20) during (1 hour)
Проверил, на версии 2.3.1: constantUsersPerSec держит среднюю частоту выполнения пользовательского сценария равной указанному значению rate — обычная ровная ступенька. То что надо.
Поправь описание, в статье написано, про рост нагрузки на rate каждую секунду.
Спасибо за статью. За наглядное представление работы инструментов в связке друг с другом. Прочёл с интересом.
В статье нет рисунков 6, 7. Было бы здорово добавить.
Статья раскрывает способы проверки на наличие уязвимостей. Сценарий. Её можно методикой назвать. А OWASP top 10 mobile — один из вариантов классификации. Без подобных методик top 10 не столь полезен. Спасибо за труд.
Очень сильно. Прямо, вау.
В том году, а может и в 2016 зимой, был в mail.ru на конференции по нейронным сетям, где представитель NVidia как раз рассказывал, что в железе и фреймворках была реализована оптимизация ускорения работы алгоритмов обучения за счёт использования целых чисел вместо плавучек. С потерей качества вычислений, но с приростом в скорости.
Проблема, что когда ты эту проблему решил, тренировке это особо не помогает. Все методы, что они предложили для inference, такие как удалять какие-то веса, использовать квантизацию, фактически это взять 32-битный floating point, плавучку, и превратит ее в 16 бит, 8 или 4. Все эти механизмы для тренировки не работают, потому что теряется качество вычислений, и обычно используется какой-то алгоритм stochastic gradient descend, он просто перестает сходиться. Мы пересмотрели эти алгоритмы, никто из них к тренировке напрямую не применим. Также они не очень хорошо ложатся на современные GPU, все эти статьи предлагают сделать новый ISAC, что-то похоже на TPU или давайте используем в лучшем случае какую-то программируемую логику типа FPGA для этого. На GPU все эти техники не очень хорошо ложились
И если ему верить, то есть группа задач, где возможна потеря точности вычислений. Не готов ввязываться в спор по этому вопросу. Помню, что тогда понял, как мало я знаю про нейронные сети. И сейчас такое же чувство.
Спасибо за статью. Очень интересно написано. Не знаком с D, поэтому прошу прощения за глупый вопрос. Верно ли понимаю, что возможность вызова операторов времени компиляции, позволяет выполнять расширение методов языка без дополнительных накладных расходов? И это, вероятно, важно в данной статье.
Вопрос к первому условию, к самому первому if, в примере кода:
ref Checked opUnary(string op)() return
if (op == "++" || op == "--")
{
static if (hasMember!(Hook, "hookOpUnary"))
hook.hookOpUnary!op(payload);
else
static if (hasMember!(Hook, "onOverflow"))
{
static if (op == "++")
{
if (payload == max.payload)
payload = hook.onOverflow!"++"(payload);
else
++payload;
} else
{
if (payload == min.payload)
payload = hook.onOverflow!"--"(payload);
else
--payload;
}
} else
mixin(op ~ "payload;");
return this;
}
Условия не static if, а простое if. Сказывается ли это по последующей скорости выполнения программы?
Спасибо за исследование. Занимаюсь тестированием производительности. Добавлю в копилку аномалий такую: прекратился рост метрики при сохранении роста других метрик.
Например, система под нагрузкой. Вдруг рост утилизации процессора останавливается, а интенсивность Context Switch продолжает расти или даже рост увеличивается. Тут вполне возможно, что упёрлись в ограничения cgroups в linux для архитектуры x86. Или в другие ограничения для других архитектур. Или с ростом нагрузки прекращается рост числа открытых файлов и начинает медленно расти время отклика. Причины могут быть разные — лимиты на процессор, на систему в целом, а может достигнут лимит числа потоков, и из-за этого перестал расти счётчик дескриптоторов файлов.
Это к чему. Мечтаю об автокорреляции временных рядов, которая бы находила такие аномалии — нарушения ожидаемых корреляций. Область знаний — статистика и статистические методы. Не планировал при реализации задействовать нейроные сети в качестве основы. Когда-нибудь сделаю. Пока просто набираюсь опыта, коплю обучающую выборку.
Спасибо за статью. Поддерживаю комментарий выше про graphite. Мой опыт с мониторингом такой. Сначала InfluxData: telegraf, influxdb. И плюсом Grafana для alert-ов и графиков с таблицами. Telegraf потому, что он умеет мониторить всё, плагинов у него куда больше, чем у Prometeus. А InfluxDB развертывается в один клик на любой платформе. Когда производительности InfluxDB перестаёт хватать, а купить коммерческую версию не получается, тогда уже есть Graphite. В Graphite уже есть масштабирование. Или есть Prometeus, который гордится своим партицированием. Неизменными остаются telegraf, который умеет писать данные в Graphite и Prometeus. И Grafana, которая умеет их читать.
Чтобы иметь теоретическую возможность переехать, не надо в Grafana писать слишком сложные запросы к Influx (я уже успел написать). Чтобы потом не так долго их переписывать под другой синтаксис. А вообще надо бы сравнить скорость работы движков. Не сравнивал ещё. Но проседания скорости работы Influx ощущаю, на стандартных настройках. Её тоже надо уметь тюнить, и запросы в Grafana к Influx надо тоже писать оптимально.
Про информацию о New Relic тоже спасибо. Сейчас доволен работой JavaMelody — APM под Java, свою работу делает, open source. New Relic выглядит интересно — APM под все языки и технологии сразу. Его можно поставить внутри закрытого контура? Или он только как внешний сервис работает?
Вечер добрый. В статье есть интересный эпизод, про вопросы от слушателя, после которых всё пошло не так. По опыту участия в публичных выступлениях, в качестве слушателя )), могу поделиться таким наблюдением. Слушателями люди являются чаще, опыт будет близок.
Если задать вопрос во время выступления, то выступающий вполне вероятно предложит перенести беседу в кулуары, а на вопрос не ответит. Так как время дорого. И вот самые интересные истории на конференциях получались в кулуарах. Подходил к выступающему, рассказывал свою историю, упоминал моменты истории выступающего, а дальше получался разговор. Иногда очень интересный, и следующий доклад, по обоюдному согласию, пропускался.
Если со стороны выступающего смотреть. То есть такой опыт. При рассказе студентам, которые привыкли на лекциях лишь слушать. Лучше их вовлечь в беседу. Предлагать им задавать вопросы по ходу рассказа. И если вопросов нет, то самостоятельно задавать самому себе вопросы, показывая ход мысли, а их подключать к ответам, например, к выбору из двух вариантов. Особенно интересно, когда верный вариант, не самый очевидный. Совет такой — вопросы и ответы на них надо тоже подготовить, сделать их частью рассказа.
Если рассказывать более профессиональной аудитории. То многое решает заранее оговорённый регламент. Например, часто организатор оговаривает, что вопросы задаются в конце и только в конце — вариант удобный выступающему. Например, так было на SQA Days. На Гейзенбаге есть отдельное время для вопросов после выступления и дискуссионная зона — очень удобный формат, уже более близкий слушателю. В то же самое время, в статье есть верное замечание, что слушатели помнят лишь последнюю минуту из услышанного. И желательно давать возможность задавать вопросы по ходу рассказа — вариант наиболее комфортный для слушателя. Совет выступающему тут такой — сделать полную версию рассказа и сокращённую. И отрепетировать обе. Сокращённая нужна, если пойдут вопросы или если предыдущий выступающий не уложится во временные рамки. А полная, если будет соблюдён регламент и если вопросы будут только в конце.
Хорошая импровизация должна быть тщательно отрепетирована.
Здравствуйте. Готов помочь с Apache.JMeter.
Если речь о хитах в секунду, то 1к запросов в секунду — прекрасный показатель.
На недавнем тесте мой профиль был 500 запросов в секунду с двух Apache.JMeter в сумме. Но моей целью не было найти технологический предел JMeter по подаче нагрузки. И каждый третий запрос был тяжёлым, как минимум один PostProcessor и Assertion, а где-то и несколько.
Когда упираюсь в некий предел нагрузочной станции, то использую две-три-четыре станции. Это нормально. Если нужно увеличить хиты в секунду, в hit-based тесте, то можно использовать ab из httpd-tools (не работает с самоподписанными сертификатами, но сгодится для http или корректных сертификатов) или аналоги. Если нужна логика работы запросов с завязкой на тестовые данные и связанность операций, то нужен JMeter. Цена добавления логики — снижение максимального количества хитов в секунду.
А про автомобиль (это из заключительной скрытой части) такое мнение, обратное — в Ижевске машина мне была нужна. Для удовольствия, просто потому, что её приятно водить. В Москве машина уже не столь нужна, расходов больше. Метро и другой общественный транспорт удобнее.
Могу посоветовать попробовать YAML-синтаксис. Он не будет уступать текстовому представлению по понятности. И кроме того, тесты в таком представлении можно будет сразу же запускать, используя taurus.
gettaurus.org/docs/JMX2YAML
Здравствуйте. Интересная статья. Коллеги на одном из проектов пробовали сделать такое. Cucumber для нагрузки. Доступность облаков будила фантазию. Но не сделали — это не для всех задач подходит.
На другом проекте также использовали функциональные тесты, уже успешно и регулярно. Но не для нагрузки в широком смысле понимания, а как индикатор появления узких мест после внесения небольшой изменений в проект. Думаю, как и у Антона Косякина. Подход такой:
Такой вариант хорошо работает. Если показатели производительности ухудшились, то причина скорее всего в функциональности и изменениях, которые были между запусками тестов. То есть — причина более-менее локализована. Это плюс. И очень быстрая обратная связь разработчикам — это самый главный плюс. Они не боятся вносить изменения в код.
Из минусов — нет точного понимания, какие будут показатели RPS (запросов в сек), TPS (операций в сек). Ведь функциональный тест может зависнуть, и если вчера за минуту выполнялось 60 тестов (1 TPS), то сегодня выполняется только 1 тест в минуту (1/60 TPS) — то есть нагрузка на систему подаётся в 10 раз меньшая, и результаты запусков не сравнимы. Предположу, что в данном подходе такое может случиться. Это открытая модель нагрузки. В JMeter/Gatling/Yandex.Tank контроль TPS/RPS — решаемая задача, с понятными ограничениями.
Также, достаточно дорого поддерживать много генераторов нагрузки, если она подаётся браузером — браузер требует очень много оперативной памяти, JMeter требует сильно меньше, а Gatling, так как гораздо меньше потоков, требует ещё меньше памяти. Для реализации нагрузки 100 операций в минуту через браузер (много)/http-api-robot (только аутентификация), может понадобится 20 станций. С ростом потребностей (1000 операций в минуту), доля http-api-robot будет расти, а доля браузера снижаться. А потом (10 000 операций в минуту) и вовсе решите перейти на модель, когда всю нагрузку подаёт 4 станции с Gatling/JMeter, и ещё на одной параллельно выполняется функциональный тест в BDD-формате — для оценки отзывчивости интерфейса под высокой нагрузкой.
В команде нужны разные люди — весёлый, терпеливая, умный, в платье, с бородой,… и гитарист. Это шутка, в которой лишь доля шутки. А для сложных систем нужны команды.
Пример подхода — если есть на входе список из 7-ми целей, выбираю три наиболее интересные и важные основываясь на интуиции. Цели соответствуют SMART и их три.
На что обратить внимание при формировании и выборе целей?
Такое видел. Лимиты заранее не известны даже руководителям. И может случиться так, что завершилась оценка, отправлено обоснование повышений команды руководителю, он согласует, уже оглашает команде даты и суммы. А потом выясняется, что о-па и упс, лимиты есть.
Бюджет надо заранее выяснять, просчитывать.
Спасибо за акцент на степени влияния на команду и бизнес. Думаю стоит оценить этот фактор, не выделял его явно
Кто-то использует матрицы компетенций, различные профили специальностей, наборы курсов и систему их прохождения с получением баллов. Ещё есть оценка 360, просто разговоры по душам. И это только начало.
Понятно, что система повышения должна быть прозрачной и справедливой. И что это большой труд.
Как лучше такую систему сделать?
Написал сценарий с профилем: поднять нагрузку до 20 сценариев в сек, и подержать ее такой час.
rumpUsersPerSec(0) to (20) during (5 minutes),
constantUsersPerSec(20) during (1 hour)
Проверил, на версии 2.3.1: constantUsersPerSec держит среднюю частоту выполнения пользовательского сценария равной указанному значению rate — обычная ровная ступенька. То что надо.
Поправь описание, в статье написано, про рост нагрузки на rate каждую секунду.
В статье нет рисунков 6, 7. Было бы здорово добавить.
Статья раскрывает способы проверки на наличие уязвимостей. Сценарий. Её можно методикой назвать. А OWASP top 10 mobile — один из вариантов классификации. Без подобных методик top 10 не столь полезен. Спасибо за труд.
Научные степени близости:
Взято из интернета, найдено поисковиком — adme.ru.
Смастерил на www.draw.io, подписи неточны — как уж понял, так и написал
Интересная мысль в статье, про некорректную обратную связь. А рецепт даётся во многих случаях общий — сказать, что же конкретно не устраивает.
Ещё обобщу. Есть понятие:
Был на семинаре SOFTER (митапы в Москве), где рассказывали как такую связь можно давать, не обижая человека:
Рецепт такой (плюс — минус — плюс), а также:
Пример:
В жизни эти знания пока не применял, просто усвоил и внутренне с ними согласен. Прочитал статью и вспомнил.
Пересмотрел, да, там про Inference. В комментарии выше я был не прав.
В том году, а может и в 2016 зимой, был в mail.ru на конференции по нейронным сетям, где представитель NVidia как раз рассказывал, что в железе и фреймворках была реализована оптимизация ускорения работы алгоритмов обучения за счёт использования целых чисел вместо плавучек. С потерей качества вычислений, но с приростом в скорости.
И если ему верить, то есть группа задач, где возможна потеря точности вычислений. Не готов ввязываться в спор по этому вопросу. Помню, что тогда понял, как мало я знаю про нейронные сети. И сейчас такое же чувство.
Спасибо за статью.
Вопрос к первому условию, к самому первому if, в примере кода:
Условия не static if, а простое if. Сказывается ли это по последующей скорости выполнения программы?
Прочёл свободно доступную первую главу «Анти-паттерны»: conferences.oreilly.com/velocity/vl-ca/public/content/practical-monitoring, этого мне хватило. Содержимое перекликается с комментариями и дополняет тему статьи.
"JMeter без jmx" — это невероятно. Так можно? Спасибо огромное за статью и за этот заголовок
Спасибо за исследование. Занимаюсь тестированием производительности. Добавлю в копилку аномалий такую: прекратился рост метрики при сохранении роста других метрик.
Например, система под нагрузкой. Вдруг рост утилизации процессора останавливается, а интенсивность Context Switch продолжает расти или даже рост увеличивается. Тут вполне возможно, что упёрлись в ограничения cgroups в linux для архитектуры x86. Или в другие ограничения для других архитектур. Или с ростом нагрузки прекращается рост числа открытых файлов и начинает медленно расти время отклика. Причины могут быть разные — лимиты на процессор, на систему в целом, а может достигнут лимит числа потоков, и из-за этого перестал расти счётчик дескриптоторов файлов.
Это к чему. Мечтаю об автокорреляции временных рядов, которая бы находила такие аномалии — нарушения ожидаемых корреляций. Область знаний — статистика и статистические методы. Не планировал при реализации задействовать нейроные сети в качестве основы. Когда-нибудь сделаю. Пока просто набираюсь опыта, коплю обучающую выборку.
Спасибо за статью. Поддерживаю комментарий выше про graphite. Мой опыт с мониторингом такой. Сначала InfluxData: telegraf, influxdb. И плюсом Grafana для alert-ов и графиков с таблицами. Telegraf потому, что он умеет мониторить всё, плагинов у него куда больше, чем у Prometeus. А InfluxDB развертывается в один клик на любой платформе. Когда производительности InfluxDB перестаёт хватать, а купить коммерческую версию не получается, тогда уже есть Graphite. В Graphite уже есть масштабирование. Или есть Prometeus, который гордится своим партицированием. Неизменными остаются telegraf, который умеет писать данные в Graphite и Prometeus. И Grafana, которая умеет их читать.
Чтобы иметь теоретическую возможность переехать, не надо в Grafana писать слишком сложные запросы к Influx (я уже успел написать). Чтобы потом не так долго их переписывать под другой синтаксис. А вообще надо бы сравнить скорость работы движков. Не сравнивал ещё. Но проседания скорости работы Influx ощущаю, на стандартных настройках. Её тоже надо уметь тюнить, и запросы в Grafana к Influx надо тоже писать оптимально.
Про информацию о New Relic тоже спасибо. Сейчас доволен работой JavaMelody — APM под Java, свою работу делает, open source. New Relic выглядит интересно — APM под все языки и технологии сразу. Его можно поставить внутри закрытого контура? Или он только как внешний сервис работает?
Вечер добрый. В статье есть интересный эпизод, про вопросы от слушателя, после которых всё пошло не так. По опыту участия в публичных выступлениях, в качестве слушателя )), могу поделиться таким наблюдением. Слушателями люди являются чаще, опыт будет близок.
Если задать вопрос во время выступления, то выступающий вполне вероятно предложит перенести беседу в кулуары, а на вопрос не ответит. Так как время дорого. И вот самые интересные истории на конференциях получались в кулуарах. Подходил к выступающему, рассказывал свою историю, упоминал моменты истории выступающего, а дальше получался разговор. Иногда очень интересный, и следующий доклад, по обоюдному согласию, пропускался.
Если со стороны выступающего смотреть. То есть такой опыт. При рассказе студентам, которые привыкли на лекциях лишь слушать. Лучше их вовлечь в беседу. Предлагать им задавать вопросы по ходу рассказа. И если вопросов нет, то самостоятельно задавать самому себе вопросы, показывая ход мысли, а их подключать к ответам, например, к выбору из двух вариантов. Особенно интересно, когда верный вариант, не самый очевидный. Совет такой — вопросы и ответы на них надо тоже подготовить, сделать их частью рассказа.
Если рассказывать более профессиональной аудитории. То многое решает заранее оговорённый регламент. Например, часто организатор оговаривает, что вопросы задаются в конце и только в конце — вариант удобный выступающему. Например, так было на SQA Days. На Гейзенбаге есть отдельное время для вопросов после выступления и дискуссионная зона — очень удобный формат, уже более близкий слушателю. В то же самое время, в статье есть верное замечание, что слушатели помнят лишь последнюю минуту из услышанного. И желательно давать возможность задавать вопросы по ходу рассказа — вариант наиболее комфортный для слушателя. Совет выступающему тут такой — сделать полную версию рассказа и сокращённую. И отрепетировать обе. Сокращённая нужна, если пойдут вопросы или если предыдущий выступающий не уложится во временные рамки. А полная, если будет соблюдён регламент и если вопросы будут только в конце.
Хорошая импровизация должна быть тщательно отрепетирована.
Здравствуйте. Готов помочь с Apache.JMeter.
Если речь о хитах в секунду, то 1к запросов в секунду — прекрасный показатель.
На недавнем тесте мой профиль был 500 запросов в секунду с двух Apache.JMeter в сумме. Но моей целью не было найти технологический предел JMeter по подаче нагрузки. И каждый третий запрос был тяжёлым, как минимум один PostProcessor и Assertion, а где-то и несколько.
Когда упираюсь в некий предел нагрузочной станции, то использую две-три-четыре станции. Это нормально. Если нужно увеличить хиты в секунду, в hit-based тесте, то можно использовать ab из httpd-tools (не работает с самоподписанными сертификатами, но сгодится для http или корректных сертификатов) или аналоги. Если нужна логика работы запросов с завязкой на тестовые данные и связанность операций, то нужен JMeter. Цена добавления логики — снижение максимального количества хитов в секунду.
В любом случае, напишите. Буду рад помочь.