- Lesson 2
  - Корреляция запросов
    - Request>CSS/JQuery Extractor
    - ThreadGroup>HTTP Cookie Manager
    - ?
      - как вытащить параметр из
        - джейсон ответа?
          - JSON Path PostProcessor
        - хедера в респонсе?
        - из кукис?
        - лоукал/сешн сторедж?

  - Управление потоком выполнения
    - Once Only Controller>Request
    - Loop Controller
    - While Controller
      - can be based on var used (updated and used) in requests with additionally set default value
        - so once, update will produce "none", the var will get e.g. "false" and while will break loop
    - If controller
    - Modules as inactive ThreadGroups with Simple Controllers as "defined methods"
      - to call a "defined method":
        - ThreadGroup>if needed parameter - Parametrized Controller (available as plugin)>Module Controller (which links to "defined controller")
    - ?
      - в конце Баранцев ставит риторический вопрос - а нужны ли такие сложные сценарии? и не дает на него ответа... а зря...
        нужно таки ему этот вопрос задать в лоб
        - пока что мне кажется что да, стоит всегда стремиться к простоте... но может как раз особенность нагрузочного тестирования в том, что бы симулировать "реальную нагрузку", это в функциональных тестах, мы можем в основном идти путем атомарных тестов... а сдесь, в нагрузочном - таки рулят "енд ту енд" тесты, и судя по всему сложные - с ифами и циклами... возможно правда можно эту сложность как то "вынести из сценария на уровень выше", но нужно еще потренироваться как это сделать...

  - Протоколы взаимодействия
    - HTTP(s)
    - WebSocket (via plugin)
    - Remote API (SOAP, REST)
      - REST
        - JSON Path PostProcessor
    - Базы Данных
    - SMTP, POP3, IMAP
      - когда нет способа получить нужную информацию из БД (наприм ссылку/код для подтеврждения регистрации)
    - WebDriver
      - прийдется нанимать кучу машин в клауде на недешево
      - когда сильно много аякса, и нереально все это симулировать с помощью http запросов
    - ТСP, UDP
    - Java API


- Lesson 3 - Нагрузка

  - Требования к производительности
    - Характеристики качества
      - Время отклика (response time)
        - для запроса
        - для транзакции (серии запросов)
      - пропускная способность (throughput) = количество событий (запросов/транзакций/etc) произошедших за единицу времени
      - способность к распаралеливанию (concurrency)
      - Доступность (готовность) (availability, uptime)
      - Потребление ресурсов (resource utilization)
        - процесор, память, сеть, дисковая подсистема, etc
      - потенциальная мощность (capacity)
    - Требования
      - время отклика
        - среднее время отклика
          - классификация по типам (пр: action (2.5s), ping(1s), статика (0.2s))
        - дисперсия (пр: не более 20 процентов)
          - классификация по типам
        - максимальное время отклика
          - по типам... (пр: action - <5s, ping - <2s)
        - доля привышений максимума (<0.1%)
        - доля отказов (<0.001%)
        - отсутствие деградации (< 1% в течении часа)
          - ?
            - в течении часа ?
      - расход ресурсов
        - расход процессорного времени
        - расход памяти
        - обьем трафика
        - обьем операций чтения/записи
      - способность к распараллеливанию
        - пример: система должна поддерживать не менее 10к постоянно работающих пользователей
            - уточняющие вопросы:
              - что делают
              - с какой частотой
              - как делают? (один пользователь в разных вкладках - это 1 или 2 пользователя?)
              - а что если прийдет больше 10к?
              - что значит "поддерживать"
        - как надо
          - Профили нагрузки:
            - небольшая  (20%)
            - нормальная (80%)
            - предельная (100%)
          - требования по откликам плюс расходу ресурсов для каждого из профилей

  - Цели тестирования и профили нагрузки
    - цели/вопросы заказчика
      - стала ли новая версия работать быстрее?
      - что тормозит софт или железо?
      - почему пользователи не завершают заказы?
      - скоро распродажа - выдержит ли сервер?
      - че как там вообще?
    - цели тестирования
      - когда конкретные цифры не интересуют
        - сравнить две версии системы
        - найти причину проблемы с производительностью
          - может и не в ней дело, может где то функциональная проблема
      - когда интересуют цифры
        - оценить потенциальные возможности
        - получить подтверждение что все хорошо
          - нужно только уточнить у заказчика - что значит "хорошо"
            - как вариант - не хуже чем раньше
            - но если раньше не было известно - то нужны детали и конкретика

  - проектирование тестов
    - выясняем цель
      - определяем на какой вопрос должны ответить
      - переводим на тех язык
    - описываем требования и условия
    - формулируем проверяемую гипотезу
      - могут быть разные сеансы с разными гипотезами
    - описываем профиль нагрузки
      - какие сценарии, из каких транзакций, сколько сценарий разного типа необходимо использовать
    - делаем сценарии, которые его реализуют
  - как выбирать транзакции
    - критически важные
      - пр:
        - вход в систему
        - поддержка текущей сессии
    - связанные с рисками (с проверяемой гипотезой)
    - требуемые (предполагаемые) заказчиком
    - частоиспользуемые
    - ресурсоемкие
  - модель активности пользователей
    - рисуем разные воркфлоу, определяем либо на глаз либо с помощью имеющихся данных - где сколько процентов каких транзакций
    - потом для каждой транзакции считем сумарные проценты - и сравниваем с тем что в реально жизни (из данных мониторинга)
  - профиль нагрузки
    - количество виртуальных пользователей
    - количество сценариев
    - ** количество транзакций/запросов **
      - то на что равняемся, остальные можем "подгонять"
    - задержки между запросами
    - задержки между транзакциями
  - "виды тестирования" (= названия для типовых профилей нагрузки)
    - нагрузочное
      - постоянная нагрузка, 20-80% от максимума
        - = количество транзакций сохраняется в течении длительного времени
          - при этом соотношение сценариев разного вида можем менять, можем играться в границах 20-80%
          - более правильно говорить так: "мы выполняли тестирование при постоянной нагрузке - столько то от максимума, выполняли такие то сценарии в таком то соотношении"
      - если еще и долго "нагружаем" => "стабильности"
    - стрессовое
      - непреривно возрастающая нагрузка
      - ищем точки насыщения = моменты когда поведение системы меняется
        - пр: начало расти время отклика, увеличилась дисперсия, появились отказы
        - обычно ноги растут от того что заканчиваются какие то ресурсы
      - по сути определяем "максимум" для нагрузочного тестирования
      - спайк тестирование
        - нагрузка с пиками
          - превыщающими максимум на незначительное время
            - как будет себя вести во время?
            - сможет ли востановиться?
          - можно делать для одного или нескольких сценариев
          - повышать/уменьшать частоту

  - Профили нагрузки в JMeter
    - number of threads
      - считается что на "стандартной машине" можно запустить 500-600
        - но - только если при этом не перегружать джеметер
          - например через использование view results tree
          - другие места для облегчения: <todo>
        - проще - использовать несколько машин
    - обеспечение заданой пропускной способности (количество запросов/секунду)
      - Thread Group
      - експериментальным путем подобрать number of threads
      - установить фиксированное number of threads и подтюнить задержки между транзакциями
        - Constant Throughput Timer
          - автоматом подбирает нужные задержки при заданом req/sec
          - к сожалению подбирать tr/sec не умеет
            - либо приходится подбирать нужное количество сценариев
            - либо использовать метрику req/sec
    - возрастающая нагрузка
      - 1 способ: Thread Group
        - max number of threads
        - достаточно длительный период разогрева (Ramp-Up period)
        - Loop Count: forever
        - Scheduler: Duration = ramp up
      - 2 способ: Stepping Thread Group (из модуля плагинов: Custom Thread Groups)
      - 3 cпособ: Concurrency Thread Group
      - 4 cпособ: Arrivals Thread Group
        - количество будет возрастать нелинейно, будет подстраиваться
        - ?
          - не особо вкурил как этим пользовать и зачем... :)
    - нагрузка с пиками/всплесками
      - 1 Ultimate Thread Group
        - все пики "рисуются" вручную
      - 2 Thread Group
        - одна Thread Group как основа
        - вторая Thread Group c большой нагрузкой, и с таймером (Constant Timer) задержки внутри

  - Задержки в JMeter
    - зачем?
    - формировать профиль нагрузки
    - управление частотой запросов
    - симуляция пауз пользователя
      - изза того что существует
        - кеширование в браузере
          - есть срок годности кеша....
            - когда тогда будут отправлятся запросы? - до истечения срока или после? - это можно контролировать
        - кеширование на сервере/прокси
      - желательно делать такие же паузы как в реальной жизни, что бы симулировать реальный "профиль кеширования"
      - но возможен и компромис
        - изза того что может нехватить мощности генератора по нужному увеличению количества вирт. пользователей
    - ?
      - ввообще то я не понял как это мы симулируем профиль кеширования в браузере, если мы посылаем запросы из джеметер а не реального браузера... джеметер же не имеет какого либо профиля кеширования :)
        - типа есть HTTP Cache Manager
          - но, тю, все равно это ведь не реальный браузер... поэтому все это такая себя "симуляция", звучит как слегка "притянутая за уши", не хватает каких то реальных цифр... а то получается решили использовать паузы на основе каких то сомнительных предположений, что джеметр как то более менее правильно там все симулирует в контексте кеширования в браузере...
    - реализация в Jmeter...
      - правила
        - таймер действует на все запросы текущего контекста
          - за этим нужно следить, часто таймер нужен даже конкретно на "запрос" а не "всю транзакцию" или весь сценарий
        - таймер срабатывает перед запросом
          - поэтому если он нужен "в конце" - нужно его поместить внутрь следующего
          - или, что лучше и наглядней - в отдельный компонент Test Action (псевдо-запрос)
            - который и сам может играть роль "постоянной паузы"
              - но если нужно что то особенное, можно его паузу установить в ноль
                - а уже внутрь запихнуть подходящий случайный таймер

  - запуск тестов
    - Этап 1: разработка
      - определить цели, сформулировать гипотезы
      - реализовать сценарии, описать профили нагрузки
      - погонять как функциональные тесты (с небольшой нагрузкой)
        - можно проверки подописывать
        - нужно - что бы проверить функциональность в "паралельном контексте"
        - после - можно отключить/деактивировать
      - откалибровать сценарии (с небольшой нагрузкой)
        - что бы соответствовали в процентном соотношении реальности
        - добавляем задержки вдруг что
        - добавляем/уменьшаем кол. в. польз-ей
        - до тех пока не увидим что количество транзакций разного типа не удовлетворяет требованиям
      - стабилизировать показатели производительности
        - прогнать откалиброванные несколько раз, и убедится что каждый раз получаем одинаковые показатели производительности
        - возможно действуют какие то неизвестные факторы, которые мы не учли
          - например
            - другие процессы которые расходуют много ресурсов
            - может кто то другой также нагружает систему

    - Этап 2: выполнение
      - выбрать эталон/базу, снять показатели
        - (когда показатели стабильны при не большой нагрузке)
        - = последнему по сути шагу первого этапа
      - поискать точки насыщения, найти максимум
        - если нет гипотезы которую нужно проверить
      - прогнать не очень долго на 80% от максимума
        - 5, 10 минут, час
      - прогнать довольно долго на 20%
        - несколько часов, сутки, может даже больше
        - при этом такой не сильно нагруженный сервер можно исопльзовать для отладки, новых сценариев, функционального тестирования...
      - ** каждый сеанс выполнять несколько раз! **

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


  - Ручное тестирование производительности
    - цель: оценка загрузки отдельно взятой страницы, от начала до конца с точки зрения пользователя
      - входит
        - разрешение имен
        - загрузка основного содержимого
        - всех дополнительных ресурсов (картинок, стилей)
        - загрузка и выполнение js
    - developer tools>Network
    - developer tools>Timeline in chrome
    - YSLow chrome extension
    - стоит выполнять как при нагруженном сервере (обычными тестами производительности) так и ненагруженном


- Lesson 4

  - Анализ результатов в JMeter
    - генератор нагрузки дает
      - время отклика
      - количество сбоев
    - лучше просто собирать данные во время выполнения, что бы не забирать ресурсы у генератора
    - а анализировать после, причем лучше на другой машине
      - ?
        - почему
    - Simple Data Writer
      - лучше поотключать все данные которые не нужни для сбора в целях экономии ресурсов
    - Flexible Data Writer (через плагин)
      - слегка гибче, но не намного
    - Summary Report
      - то за чем таки можно следить во время выполнения тестов
      - показывает количество отказов
        - возможно после какой то "катастрофы" уже дальше продолжать тестирование смысла не будет
      - там же можно увидеть точки насыщения по резкому возрастанию некоторых показателей
        - с целью зкономить время выполнения - возможно дальше смысла выполнять этот сценарий уже не будет
        - в этот момент можно зафиксировать текущее количество потоков
      - если мы намерены "дождаться до конца" - тогда конечно следить незачем
      - сюда также можно загружать данные после выполнения
    - Graph Results
      - для грубой оценки
    - Response Times Over Time
      - анализируем запросы отдельно, отдельно быстрые, отдельно медленные
    - Bytes Throughput Over Time
      - к сожалению нельзя посмотреть для отдельных запросов
    - Transactions per Second
      - можно для разных запросов/транзакций посмотреть
    - Response Times Distribution
      - обычно выглядит как крутой подъем и пологий спуск - это хорошо
        - ?
          - почему
    - Response Times Percentiles
      - x: какой процент запросов
      - y: до какого времени успел завершиться
      - или наоборот - что и более удобно - какой процент не успел завершиться за какое время
      - обычно должен быть подйом вначале, плато, и горочка в конце

  - Сравнительный анализ результатов
    - что с чем сравнивать?
      - время отклика для разных запросов
        - jmeter умеет
      - время отклика и пропускная способность
      - время отклика и размер ответа
      - время отклика и latency (ожидание начала прихода данных)
        - время отклика и latency и размер ответа
      - время отклика для разных запусков (профилей нагрузки)
        - jmeter умеет но очень неудобно
          - искажает масштаб
            - можно пофиксить но нужно вручную править цсв файлы - подправлять время
              - можно это сделать через Excel
                - сейчас может обрабатывать до 2 милионов строк
                  - хотя и будет тормозить
              - Python + Numpy
              - R
              - RapidMiner
                - визуальный, но платный:) (бесплатный для некомерческого использования)
              - комментарии якова
                - Knime - очень мощный но с большущим порогом входа... может когда то стоит таки к нему присмотреться
                - Orange - с низким порогом входа, но так и не получилось два графика в один запихнуть... как то нужно попробовать еще раз...
                - Сlojure + Incanter - я бы выбрал именно этот набор... но нужно разбираться... книжка: https://dl.dropboxusercontent.com/u/15301926/Eric%20Rochester%20-%20Clojure%20Data%20Analysis%20Cookbook%2C%202nd%20Edition%20-%202015.pdf

  - Анализ использования ресурсов
    - слишком много всего
    - начать с простого
      - процесорное время
      - оперативная память
    - дальше уже по наявный проблемам, пробовать угадать где ботл нек - и следить именно за соответствующим ресурсом
    - сборщики данных
      - только общие показатели
        - Windows: perfmon
        - *nix: sysstat (sar)
      - как расходуются ресурсы внутри конкретного приложения
        - например
          - как быстро выполняются запросы к базе данных
          - как расходуется память внутри конкретного процесса
        - специализированные
          - обычно есть для каждой базы данных
          - есть для джавы/дотнет свои инструменты, профайлеры, и т.д.
        - универсальные (Zabbix, Nagios, ...)
          - обычно собирают данные (с машин внутри какой то сети) не достаточно часто (например, раз в минуту...)

  - Подготовка Тестового Стенда
    - идеальная ситуация: копия продакшена
    - реальная ситуация: упрощенная модель
    - можно поймать момент когда продакшен уже настроен но еще на "запущен на использование пользователями"
      - очень важно его поймать, это позволит запустить одинаковый тесты и на нем и на стейджинге, и потом вычислить поправочный коэффициент
    - что можно упростить/оставить в "реальном" тестовом стенде?
      - хотя бы такая же конфигурация серверов (железа, апаратная)
        - с такой же мощностью
        - с таким же количеством процессоров и оперативной памяти
        - типа пусть будет 1 сервер а не 30 как на продакшене, но такой же
      - хотя бы та же самая сеть
        - в том же датацентре, в той же сети
      - с такой же схемой развертывания
        - такой же балансировщик нагрузки, также настроен
        - такая же схема репликации баз данных
      - такие же настройки
        - с такими же отключенными/включенными логами
        - механизмы кеширования
      - хотя бы сравнимый размер базы данных
        - либо копия баз данных
          - анонимизированная конечно
        - либо тестовая наполненная тестовыми данными, близкого размера
    - дополнительные факторы
      - генераторы нагрузки
      - системы мониторинга
        - стараться установить датчиков как можно меньше, настолько редко настолько возможно, но так что бы не потерять информацию
      - дополнительный трафик
        - при распределнных системах мониторинга
        - при распределенных генерациях нагрузки
        - нужно как то все это отделить от основного
        - собранные данные лучше не отправлять а сохранять
          - хотя это нагружает систему ввода/вывода
            - может стоит для этого использовать отдельный диск
            - но если для приложения работа с диском несущественна - то и нафиг
        - фоновые процессы
    - виртуализация
      - если продакшен не на виртуальных/в контейнерах то опасно стейджинг виртуализировать...
      - генераторам нагрузки же все равно...

  - Распределенная Генерация Нагрузки
    - когда нужно?
      - высокая нагрузка
      - тестирование балансировки
      - другие особенности
      - несколько точек измерения

  - Понятые отчеты
    - хорошый отчет
      - своевременный
      - релевантный
      - достоверный
      - согласованный и непротиворечивый
      - * доступный для восприятия *
        - сравнение чего-нибудь с чем-нибудь
          - с требованиями
          - с предыдущей версией
        - правильно выбранный масштаб


- Aлгоритм:
  - сразу добавляем
    - куки менеджер (почти всегда он нужен)
    - HTTP Cash Manager
  - Записываем сценарий
  - Просмтриваем запросы
    - есть параметры?
      - находим те которые мы сами заполняли на веб страницах => Тестовые Данные
        - можно генерировать случайно (__RandomString, __Random)
        - загружать из внешнего файла
        - etc.
      - находим те которые мы вручную не вводили (значит подставляются откуда то автоматически)
        - => скорее всего нужна кореляция
        - или что другое
          - например иногда запрос будет отсылать сведения о времени совершения операции. Рекордер запишет конкретный таймстемп,нам нужно будет каждый раз отсылать актуальное время. Это можно симулировать с помощью ${__javaScript(new DatgetTime()
  - добавляем задержки

- Debug
  - Fiddler
  - View Results Tree
  - Debug Sampler - энейблит показывание переменных в view results tree
  - Active Threads Over time - для наблюдения за потоками


?
  - каким образом учитывать ресурсы которые жрет сам нагрузчик
  - можно ли создавать "методы" - Да, можно :) но получается кривовато
     - внутри сценария
      - вокруг набора запросов
      - вокруг контролера с нужными параметрами? типа "partial application"
     - за границами сценария

JMeter cons
  - только ненаглядное/неявное использование переменных
    - пример
      - смотрим и видим цикл, внутри набор запросов, в одном из которых используется переменная обьявленная и впервые устоновленная за  границами цикла, и будет обновлена на каждой итерации... С одной стороны в коде - было бы также, но за счет того что код обычно "не  сворачивают" - такая переменная сразу будет бросаться в глаза, а в "визуальном джеметре" - ты видишь как бы красивые шаги, но не  подозреваешь что они могут использовать какое то внутреннее состоянее которые может изменятся в разных местах, не очевидных сразу...
      В коде при этом - скорее всего, такого состояния можно было бы избежать совсем... сделать его явным, а шаги оставить "абстрактными".  В джеметре такого сделать нельзя.
  - сильно много воды
    - в коде ты пишешь только то что нужно, в JMeter ты видишь целую страницу опций/настроек, из которых тебе нужны только некоторые в конкретном случае
  - DRY но громоздкий DRY, сильно много гемороя с передачей параметров в "описанный в другом месте котролер", и слишком много танцев что бы сделать это читабельным...
    - походу нельзя создать метод вокруг какого то контролера с нужными настройками...

  - не очевидный ненаглядный интерфейс
    - пример
      - -1 as indicator of "extracting all matched elements, 0 as indicator for random element: "http://joxi.ru/p27OXp4h0BW8g2
        - and here what you get if set -1:
          - ITEM_KEY=false
          - ITEM_KEY_1=...
          - ITEM_KEY_2=...
          - ITEM_KEY_matchNr=2
          - so then you can: http://joxi.ru/52a8LWBIGObQdm
      - если Counter дойдет до конца, он начнет все сначала, это - НЕочевидно, и это нигде не видно в настройках...
      - странная логика работы таймеров
        - неважно куда ты его запхнешь в начало или в конец запроса, он все равно будет запущен "вначале"
        - а что бы он запустился после - его нужно в следующий запрос запихнуть
          - хотя есть воркераунд - запихнуть его в отдельный test action

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

  - Юля: менее информативные сообщения о ошибке...
    - забыл скобочку где то - хер поймешь из ошибки в чем дело