1. Предисловие
С наступлением эпохи 5G и эпохи Интернета всего будет появляться все больше и больше облачных приложений и облачных сервисов, а объем данных будет увеличиваться в геометрической прогрессии. В частности, эпохальное значение глобальной эпидемии в 2020 году приведет к тому, что все сферы жизни начнут мигрировать в облако. Это приведет к рождению различных продуктов с высокой степенью персонализации.
Экология всех отраслей будет похожа на эффект падения кита, вокруг нескольких гигантских компаний будут производиться мелкие и средние продукты, удовлетворяющие различные потребности людей. Форма большинства продуктов может стать тяжелой для сервера и легкой для клиента.
Таким образом, спрос на тестирование производительности на стороне сервера также может резко возрасти. Однако для малых и средних компаний, особенно тех компаний, которые не обращают внимания на пользовательский опыт, требования к тестированию производительности сервера характеризуются короткими циклами и жесткими графиками.
Поэтому для большинства специалистов по тестированию важно понимать и осваивать общие знания по тестированию производительности, хотя они и не будут использоваться часто.
2. Что такое производительность?
Разные роли сосредоточены на разных характеристиках.В рамках систематического проекта тестирования производительности каждая роль должна предоставлять информацию или помощь в пределах своего внимания.
Производительность в глазах пользователей
Для пользователей производительность — это скорость отклика операций и то, влияют ли сбои продукта на их жизнь. Например, авария на выступлении службы такси Диди в День святого Валентина.
Производительность в глазах начальника
Начальник в основном заботится о доходах от продукта, стоимости (сколько денег используется для обслуживания скольких пользователей) и удовлетворенности пользователей (удовлетворен ли пользователь продуктом).
Производительность глазами операций
производительность глазами разработчиков
Производительность глазами испытуемых
3. Влияние производительности
3.1 Влияние производительности на пользователей
Для продуктов ToC большинства коммерческих компаний производительность связана с судьбой и развитием продукта. Как показано на рисунке ниже, хотя подменить приложение под монополию Ali JD.com непросто, при плохой производительности я все же не могу не сказать несколько слов в душе.
3.2 Влияние производительности на доход
Все знают, что производительность очень сильно влияет на доход от продукта, но лишь немногие компании проводят всесторонний операционный анализ, подтверждающий это.
Ниже приведены данные о влиянии производительности на доход из отчета Global Retail Digital Performance Benchmark Report 2016.
Как видно из рисунка большое влияние на коэффициент конверсии оказывает время отклика, например, Wal-Mart достаточно хардкорный, если уменьшить время отклика Wal-Mart на 0,1 секунды, то выручка может увеличиться на 1 %, что является очень большим увеличением дохода.
4. Структура производительности
На примере небольших и средних веб-сайтов электронной коммерции, как показано на рисунке ниже, базовая структура производительности: Производительность
клиента (Интернет, мобильный терминал, апплет).
Производительность DNS
Производительность службы балансировки нагрузки
Производительность кластера Nginx, процент потерь
Производительность кэша CDN (скорость возврата к источнику, скорость проникновения)
производительность сервера приложений
Производительность БД (Mysql/Redis/Memcache)
Можно видеть, что тестирование производительности средних и крупных проектов всегда было систематическим проектом, который требует сотрудничества многих людей из разных отделов, длится долго и потребляет много ресурсов.
5. Базовые знания и меры предосторожности при тестировании производительности
Прежде чем знакомиться с тестированием производительности, сначала поймите, какова цель тестирования производительности. Мышление с целями будет более способствовать пониманию следующего содержания.
5.1 Цель теста производительности
Конечной целью теста производительности является максимальное удовлетворение потребностей пользователей, обычно для достижения следующих целей:
(1) Оценка производительности: оценка QPS, времени отклика, процента успешных попыток и т. д. системы во время теста;
(2) Найти систему (3) Обнаружить проблемы
в программном обеспечении;
(4) Проверить стабильность и надежность;
5.2 Показатели, на которые следует обратить внимание в отношении производительности
Вообще говоря, тестирование производительности должно учитывать следующие факторы: , время ожидания ответа, использование ресурсов (CPU/MEM/IO/Bandwidth...), вероятность успеха, стабильность системы.
(1) Время отклика: необходимо определить задержку времени отклика системы, которая рекомендуется на уровне TP95 или выше. Каково конкретное требование ко времени отклика?Как правило, чтение не превышает 200 мс, а запись не превышает 500 мс. Если вы действительно не знаете, сравните с конкурирующими продуктами в той же отрасли.
(2) Максимальная пропускная способность: TPS (запросов транзакций в секунду) или QPS (запросов в секунду), максимальная пропускная способность, которую система может поддерживать в соответствии с требованиями к целевому времени отклика.
(3) Уровень успеха: обращая внимание на количество запросов в секунду и время отклика, мы также должны обращать внимание на показатель успеха. Если и QPS, и время отклика соответствуют требованиям производительности, вероятность успеха запроса составляет всего 50%, и пользователь его не примет.
(4) Критическая точка производительности. Общие службы имеют критические точки производительности. Когда критическая точка превышена, пропускная способность снижается нелинейно, время отклика увеличивается экспоненциально, а вероятность успеха снижается.
Найдите основную причину точки перегиба производительности:
установите сигнальную линию высокого риска производительности на основе основной причины точки перегиба производительности. Это серьезная мера предосторожности, потому что, как только будет достигнута критическая точка производительности, может произойти сход лавины, что приведет к очень серьезной аварии.
Понаблюдайте, не возникнут ли в системе события высокого риска, такие как приостановка анимации и сбой, после превышения точки перегиба производительности.
(5) Стабильность системы: поддерживать максимальную пропускную способность (самая высокая пропускная способность при целевом времени отклика) и работать непрерывно в течение 7*24 часов. Затем соберите ЦП, память, жесткий диск/сетевой ввод-вывод и другие показатели, чтобы проверить, стабильна ли система, например, ЦП стабилен, а использование памяти также стабильно. Тогда это значение является производительностью системы.
(6) Предельная пропускная способность: ступенчато увеличивайте одновременное давление, чтобы найти предельное значение системы. Например: В случае успеха 100% (независимо от продолжительности времени ответа) система может поддерживать пропускную способность 10 минут.
(7) Надежность системы: выполните Burst Test. Используйте пропускную способность, полученную на втором шаге, для выполнения в течение 5 минут, затем выполните предельное значение, полученное на четвертом шаге, в течение 1 минуты, затем вернитесь к пропускной способности второго шага для выполнения в течение 5 минут, а затем выполните значение полномочий в четвертый шаг в течение 1 минуты.Так туда и обратно в течение периода времени, например, 2 дня. Соберите системные данные: ЦП, память, жесткий диск/сетевой ввод-вывод и т. д., наблюдайте за их кривыми и соответствующим временем отклика, чтобы убедиться, что система стабильна.
(8) Низкая пропускная способность и небольшой тест сетевых пакетов: иногда, когда пропускная способность низкая, задержка может увеличиться.Например, если параметр TCP_NODELAY не включен, задержка будет увеличиваться (подробности см. package Это приведет к неудовлетворительному использованию пропускной способности и снижению производительности, поэтому тест производительности также должен выборочно тестировать эти два сценария в соответствии с реальной ситуацией.
5.3 Типы тестов производительности
Сначала просто проанализируйте стресс-модель тестов производительности.
Как показано на рисунке ниже, по мере того, как давление в единицу времени продолжает увеличиваться, давление на тестируемую систему и сервер продолжает расти, и TPS будет изменяться из-за этих факторов и обычно соответствует следующим правилам.
Чтобы получить индикаторы производительности, его в основном делят на следующие типы тестирования производительности:
тестирование производительности (в узком смысле)
Описание. Метод тестирования производительности заключается в проверке того, соответствует ли производительность системы требованиям производительности производства, путем моделирования бизнес-нагрузки производственной операции и комбинации сценариев использования. С точки зрения непрофессионала, этот метод предназначен для проверки состояния возможностей системы в конкретных условиях эксплуатации.
Особенности: 1. Основная цель этого метода — проверить, обладает ли система теми возможностями, о которых она заявляет. 2. Этот метод должен заранее знать классический сценарий тестируемой системы и имеет определенную цель производительности. 3. Этот метод требует работы в уже определенной среде. Другими словами, этот метод является предпосылкой понимания производительности системы, имеет четкую цель спроса и выполняется в уже определенной среде.
Нагрузочный тест
Описание: путем непрерывного повышения давления в тестируемой системе до тех пор, пока показатель производительности не достигнет предела (например, «время отклика») не превысит заданный показатель или пока некоторые ресурсы не достигнут насыщения.
Особенности: 1. Основная цель этого метода тестирования производительности — найти предел вычислительных возможностей системы. 2. Этот метод тестирования производительности должен выполняться в заданной тестовой среде, и обычно также необходимо учитывать бизнес-давление и типичные сценарии тестируемой системы, чтобы результаты тестирования имели значение для бизнеса. 3. Этот метод тестирования производительности обычно используется для определения производительности системы или в сочетании с настройкой производительности. Другими словами, этот метод заключается в постоянном повышении давления в системе, чтобы увидеть, когда вы превысили «мои требования» или произошел сбой системы.
Стресс-тест (тест на прочность)
Описание: метод стресс-теста проверяет способность системы обрабатывать сеансы в определенном состоянии насыщения, например использование ЦП и памяти, а также возможность сбоя системы.
Особенности: 1. Основной целью этого метода тестирования производительности является проверка производительности приложения, когда система находится под нагрузкой. 2. Этот тип теста производительности обычно использует такие методы, как имитация нагрузки, чтобы увеличить использование ресурсов системы до более высокого уровня. 3. Этот метод тестирования производительности обычно используется для проверки стабильности системы. Другими словами, этот тип теста заключается в том, чтобы подвергнуть систему сильному давлению, чтобы увидеть, стабильна ли система и где могут возникнуть проблемы.
Параллельное тестирование¶
Описание. Метод проверки параллелизма имитирует одновременный доступ пользователей, чтобы проверить наличие взаимоблокировок или других проблем с производительностью, когда несколько пользователей одновременно обращаются к одному и тому же приложению, одному и тому же модулю или записям данных.
Особенности: 1. Основная цель этого метода тестирования производительности — выявить возможные скрытые проблемы с одновременным доступом в системе. 2. Этот метод тестирования производительности в основном фокусируется на возможных проблемах параллелизма в системе, таких как утечки памяти, блокировки потоков и проблемы с конфликтами ресурсов в системе. 3. Этот метод тестирования производительности может использоваться на различных этапах разработки и требует сотрудничества и поддержки соответствующих инструментов тестирования. То есть этот тип тестирования фокусируется на нескольких пользователях, одновременно (одновременно) нагружающих модуль или операцию.
Тестирование конфигурации¶
Объяснение: метод проверки конфигурации настраивает программную и аппаратную среду тестируемой системы, чтобы понять степень различных воздействий на производительность системы, чтобы найти оптимальный принцип распределения различных системных ресурсов.
Особенности: 1. Основная цель этого метода тестирования производительности — понять степень влияния различных факторов на производительность системы, чтобы определить наиболее целесообразную операцию настройки. 2. Этот метод тестирования производительности обычно выполняется после предварительного понимания состояния производительности системы. 3. Этот метод тестирования производительности обычно используется для настройки производительности и возможностей планирования. Другими словами, в центре внимания этого вида тестирования находится «тонкая настройка» посредством настройки программного и аппаратного обеспечения, определение их наилучшего состояния, чтобы система могла достичь самого сильного состояния.
испытание на надежность
Описание: Оказывая определенное бизнес-нагрузку на систему (например, коэффициент использования ресурсов составляет 70%-90%), дайте системе поработать в течение определенного периода времени, чтобы определить, работает ли система стабильно.
Особенности: 1. Основная цель этого метода тестирования производительности — проверить, поддерживает ли он долгосрочную стабильную работу. 2. Этот метод проверки производительности требует непрерывной работы под давлением в течение определенного периода времени. (2~3 дня) 3. Во время теста необходимо обратить внимание на рабочее состояние системы. Если во время теста обнаруживается, что время отклика значительно меняется со временем или использование системных ресурсов значительно колеблется, это может быть признаком нестабильности системы. Другими словами, в центре внимания этого вида тестирования находится «стабильность», и нет необходимости оказывать слишком большое давление на систему, если система может находиться в стабильном состоянии в течение длительного времени.
Отказоустойчивый тест
Описание: Смогут ли пользователи продолжать использовать систему в случае частичного сбоя системы, и в какой степени это повлияет на пользователей.
Особенности: 1. Основная цель этого метода тестирования производительности — проверить, может ли система продолжать использоваться в условиях частичного сбоя. 2. Этот метод тестирования производительности также должен указать, когда возникает проблема, вывод о том, «сколько пользователей может поддерживать доступ», и план «какие экстренные меры принять». 3. Вообще говоря, этот тип испытаний требуется только для систем, у которых есть четкие требования к показателям непрерывной работы системы.
Тестирование больших объемов данных: тестирование больших объемов данных для определенных системных систем хранения, передачи, статистических запросов и других служб.
ПРИМЕЧАНИЕ. Забудьте о сортировке при тестировании производительности. Например, запустите на 8 часов, чтобы проверить, надежна ли система, и этот тест, скорее всего, включает тестирование производительности надежности, тестирование прочности, тестирование параллелизма, нагрузочное тестирование и так далее. Следовательно, при реализации тестов производительности они не должны быть отделены от своих внутренних связей, а должны основываться на целях тестирования, анализировать взаимосвязь между ними и эффективно разрабатывать тесты производительности.
5.4 Процесс тестирования производительности
(1) Анализ требований к производительности
Анализ требований к производительности является основой всей работы по тестированию производительности.Если требования к производительности не ясны, о последующих инструментах тестирования производительности и реализации не может быть и речи.
На этом этапе тестировщики производительности должны общаться с PM, DEV и персоналом, связанным с проектом, собирать различные данные о проекте, анализировать систему и подтверждать цели тестирования. И перевести это в конкретные измеримые показатели эффективности.
Основная задача этапа анализа требований к тестированию состоит в том, чтобы проанализировать тестируемую систему и ее требования к производительности, установить модель данных тестирования производительности, проанализировать требования к производительности, определить разумные цели производительности и провести проверки; (2) Подготовка к тестированию производительности в основном включает: разработка сценариев, по
сценариям
Написание программ, написание сценариев, подготовка тестовых сред, построение тестовых данных, предварительная настройка среды и т. д.,
разработка сценариев: разработка разумных тестовых сценариев в соответствии с характеристиками системы. Для того, чтобы результаты испытаний были более точными, здесь требуется тщательная работа. Например, для создания пользовательской модели только зная, как реальные пользователи оказывают давление на систему, можно разработать репрезентативный сценарий стресс-теста. Это включает в себя много информации, такой как распределение групп пользователей, функции, используемые различными типами пользователей, привычки пользователей, рабочее время, распределение нагрузки каждого модуля системы и так далее. Только при постоянном накоплении такого рода данных из различных аспектов стресс-сценарий будет более значимым. Наконец, сценарии проектирования переводятся в конкретные варианты использования.
Тестовые данные. Дизайн тестовых данных также является ключевым моментом и чреват проблемами. Это только самый основной шаг для создания количества тестовых данных, чтобы достичь ожидаемого количества в будущем.Что необходимо учитывать, так это разумность распределения данных.Необходимо тщательно подтвердить различные условия запроса, используемые в Значения этих ключевых столбцов должны максимально имитировать реальное распределение данных, иначе результаты теста могут быть недействительными. Для тестовых данных лучше всего использовать десенсибилизированные онлайн-данные, которые максимально приближены к реальному поведению пользователя.
Предварительная настройка: относится к предварительной оптимизации и настройке различных аспектов системы в соответствии с характеристиками системы и опытом команды, чтобы избежать ненужных переделок во время выполнения теста. Например, в системе с высокой степенью параллелизма 10 000 человек подключены к сети, а конфигурация пула соединений и пула потоков по-прежнему используется по умолчанию, очевидно, будут обнаружены проблемы.
(3) Проведите тестирование производительности
Работа на этапе выполнения в основном включает в себя два аспекта: во-первых, выполнение модели тестового примера, включая сценарии и сценарии выполнения; во-вторых, мониторинг процесса тестирования, включая результаты тестирования, запись показателей производительности и значений счетчиков производительности (4). ) анализ результатов и
настройка производительности
. Если обнаружены проблемы или показатели эффективности не соответствуют ожиданиям, своевременно проанализируйте и определите их, а после обработки повторите процесс тестирования.
Проблемы с производительностью, как правило, взаимосвязаны и влияют друг на друга, явление, наблюдаемое на поверхности, может быть не основной проблемой, а реакцией, вызванной другой проблемой. Это требует всестороннего мониторинга и сбора данных, а также оценки и позиционирования с различных аспектов и точек зрения. Процесс настройки на самом деле является процессом баланса, и его достаточно для достижения баланса во многих аспектах системы.
(5) Отчет о производительности и сводка
Напишите отчет о тестировании производительности, чтобы прояснить цели тестирования производительности, результаты производительности, тестовую среду, правила структуры данных, возникшие проблемы и решения и т. д. И подведите итог и ускорьте опыт этого теста производительности. Для подготовки конкретных отчетов о тестировании производительности см. «Шаблон отчета о тестировании производительности».
Среди всего вышеперечисленного контента, если исключить технические проблемы, самое сложное в тестировании производительности — это анализ пользовательских моделей. Он напрямую определяет, может ли сценарий стресс-теста эффективно имитировать реальное давление, и именно это моделирование реального давления делает тестирование производительности более значимым. Можно сказать, что когда тест производительности выполнен в определенной степени, разрыв отражается в создании модели.
Что касается анализа, позиционирования или настройки проблем с производительностью, то это во многом техническая проблема, требующая различных профессиональных знаний. База данных, операционная система, сеть и разработка — все это навыки, которыми должен обладать квалифицированный тестировщик производительности Только таким образом мы можем рассматривать и анализировать проблемы с разных точек зрения.
6. Сравнение производительности инструментов для повышения производительности
На основе текущих основных инструментов для повышения производительности, представленных на рынке, мы проводим горизонтальные сравнительные тесты, чтобы помочь нам гибко выбирать различные инструменты для тестирования в различных средах.
6.1 Результаты сравнения инструментов производительности
Объект тестирования: Nginx index.html (612 байт), ЦП: 16 ядер / память: 16 ГБ / диск: 500 ГБ
Пресс: Ubuntu18.04, ЦП: 8 ядер / Память: 8 ГБ / Диск: 500 ГБ
Здесь проводится только самый базовый сравнительный тест производительности, который предназначен только для базовой оценки выбора инструмента.
6.2 Знакомство с инструментами повышения производительности
(1) wrk / wrk2
wrk — эталонный инструмент для протокола Http. одномашинного многоядерного ЦП. Благодаря многопоточности и режиму обработки событий он создает большую нагрузку на целевую машину.
PS: На самом деле, wrk повторно использует асинхронную управляемую событиями структуру ae из redis. Если быть точным, управляемая событиями структура ae не была изобретена redis. Она исходит от интерпретатора Tcl jim. , Всем хорошо известен.
Преимущества:
легкий инструмент для тестирования производительности;
простая установка (по сравнению с Apache ab);
кривая обучения практически нулевая, вы можете научиться использовать его за несколько минут;
основанный на высокопроизводительном механизме ввода-вывода, который поставляется с системой, такие как epoll, kqueue, Используя асинхронную управляемую событиями структуру, большой объем параллелизма можно выжать через несколько потоков; Недостатки
:
в настоящее время wrk поддерживает только стресс-тестирование на одной машине и вряд ли поддерживает многомашинное тестирование. -целевое стресс-тестирование в будущем, потому что оно само Позиционирование wrk не предназначено для замены профессиональных инструментов тестирования, таких как JMeter и LoadRunner.Функции, предоставляемые wrk, удобны для бэкенд-разработчиков для ежедневной проверки производительности интерфейса.
Ранее в LeTV наш архитектор тестирования руководил разработкой на основе wrk2 и поддерживал распределенную среду, но стоимость разработки все еще была немного высокой.
Основное использование:
Описание параметра подкоманды:
Как использовать: wrk <опция> <URL тестируемой службы HTTP>
Опции:
-c, --connections Количество установленных и поддерживаемых TCP-соединений с сервером
-d, --duration Время измерения давления
-t, --threads Сколько потоков используется для измерения давления (чтобы уменьшить количество готовых переключений контекста, официальная рекомендация состоит в том, что количество потоков равно количеству ядер ЦП)
-s, --script <S> 指定Lua脚本路径
-H, --header <H> 为每一个HTTP请求添加HTTP头
--latency 在压测结束后，打印延迟统计信息
--timeout <T> 超时时间
-v, --version 打印正在使用的wrk的详细版本信息
Представляет цифровые параметры, поддерживает международные единицы (1k, 1M, 1G)
представляет временные параметры, поддерживает единицы времени (2s, 2m, 2h)
PS: Что касается количества потоков, это не означает, что чем больше параметр, тем лучше эффект теста под давлением.Если значение слишком велико, это приведет к частому переключению потоков и уменьшит эффект.Вообще говоря, рекомендуется установить его в 2-4 раза больше числа ядер ЦП машины для стресс-теста.
пример
wrk -c400 -t24 -d30s --latency http://10.60.82.91/
анализ отчета:
Выполнение 30-секундного теста @ http://www.baidu.com (время тестирования давлением 30 с)
12 потоков и 400 подключений (всего 12 тесты Поток, 400 подключений)
(среднее значение) (стандартное отклонение) (максимальное значение) (пропорция плюс или минус одно стандартное отклонение)
Статистика потока Средн. Stdev Max +/- Stdev
(задержка)
Задержка 386,32 мс 380,75 мс 2,00 с 86,66%
( запросов в секунду)
Запрос/сек 17,06 13,91 252,00 87,89%
Распределение задержки
50% 218,31 мс
75% 520,60 мс
90% 955,08 мс
99% 1,93
с 4922 запроса, потребление 73,86 МБ трафика)
Ошибки сокетов: подключение 0, чтение 0, запись 0, тайм-аут 311 (количество возникших ошибок)
Запросов/сек: 163,76 (QPS 163,76, то есть среднее количество запросов на обработку в секунду 163,76)
Передача/сек : 2,46 МБ (в среднем 2,46 МБ в секунду)
Выполнение 30-секундного теста @ http://10.60.82.91/ (время испытания под давлением 30 с)
32 потока и 400 соединений (всего 32 тестовых потока, 400 соединений)
(среднее значение) (стандартное отклонение) (максимальное значение) (плюс или минус) один Доля стандартного отклонения)
Статистика потока Avg Stdev Max +/- Stdev
Latency (задержка) 10,31 мс 40,13 мс 690,32 мс 98,33 %
Req/Sec (количество запросов в секунду) 2,14k 482,15 6,36k 77,39 %
Распределение задержки
50 % 5,11 мс
75 % 7,00 мс
90 % 9,65 мс
99 % 212,68 мс
(2022092 запроса были обработаны за 30,10 с, потребляя 1,62 ГБ трафика) 2022092
запроса за 30,10 с, чтение 1,62 ГБ
Запросов/сек: 67183,02 (QPS 67183,02, то есть среднее количество запросов, обработанных в секунду, равно 67183,02)
Передача/сек : 55,03 МБ (средний трафик в секунду составляет 55,03 МБ)
(2) Jmeter
Jmeter — это инструмент для измерения давления, разработанный Java и основанный на многопоточной модели параллелизма, а также самый популярный в настоящее время инструмент для измерения давления с открытым исходным кодом. Его принцип работы аналогичен, как показано на рисунке ниже:
Так называемый виртуальный пользователь (vuser) соответствует потоку
В одном потоке каждый запрос (запрос) вызывается синхронно, и следующий запрос должен дождаться завершения предыдущего запроса, прежде чем продолжить.
Запрос (запрос) делится на три части:
отправить - начать отправку на нагнетающем конце, пока прием не будет завершен на принимающей стороне
ожидание - Начать, когда приемная сторона напорной стороны будет завершена, до конца бизнес-обработки
recv - сторона, принимающая давление, возвращает данные до тех пор, пока сторона, принимающая давление, не получит данные
Есть понятие времени ожидания между двумя последовательными запросами в одном потоке, то есть пробел на рисунке
Можно ли в многопоточной модели параллелизма создать большее давление, постоянно увеличивая количество потоков?
ответ отрицательный.
На самом деле процесс может выполнять только один поток в определенный момент времени, а так называемый параллелизм относится к непрерывному переключению потоков в процессе для достижения параллелизма нескольких задач, но переключение контекста потока имеет высокую стоимость, слишком много. Наоборот, количество потоков приведет к серьезному снижению производительности.
С точки зрения приложения многопоточная модель параллелизма часто требует установки максимального количества параметров параллелизма, но если сценарий пресс-теста нужно постоянно увеличивать, то с такими инструментами на самом деле довольно сложно иметь дело.
(3) Locust
Locust — это распределенный инструмент измерения стресса, разработанный на языке Python, который в последние годы стал популярным в Китае. Locust основан не на многопоточности Python, а на сопрограмме (предоставленной gevent), а gevent использует libev или libuv в качестве цикла обработки событий.
Проблема искажения времени отклика саранчи:
когда ЦП пресса саранчи достигает узкого места, время отклика будет серьезно искажено.
Например, в обычном режиме Locust с 8 процессами и узким местом ЦП время отклика 90% составляет 340 мс. При этом время отклика, полученное wrk, составляет 59,41 мс.
Введение в основное использование:
задача декоратора может установить коэффициент давления.
Пример HttpUser:
из саранчи импортировать HttpUser, задача
class QuickstartUser(HttpUser):
# задача создает гринлет (микропоток) для каждого работающего пользователя
@task(1)
def detail(self):
self.client.get("http://10.60.82.91/")
def on_start(self):
pass
Пример FastHttpUser
из задачи импорта саранчи
из саранчи.contrib.fasthttp import FastHttpUser
class QuickstartUser(FastHttpUser):
# задача создает гринлет (микропоток) для каждого работающего пользователя
@task(1)
def detail(self):
self.client.get("http://10.60.82.91/")
def on_start(self):
pass
Начать и распространять
-c количество одновременных пользователей
-r количество пользователей, запущенных в секунду
-t непрерывное время работы
саранча -f load_test.py --host=http://10.60.82.91 --no-web -c 10 -r 10 -t 1m
распределенный
nohup locust -f locust_files/fast_http_user.py --master &
nohup locust -f locust_files/fast_http_user.py --worker --master-host=10.60.82.90 &
6.3 Тестовые записи
(1) wrk тестовые записи
2 потока: -c1000 - t1 (по крайней мере, 2 потока) QPS: 35560.79
wrk -c1000 -t1 -d30s --latency http://10.60.82.91/
3 потока: ( -c1000 -t2 QPS: 66941,77 )
wrk -c1000 -t2 -d30s --latency http://10.60.82.91/
8 потоков: ( -c1000 -t8 QPS: 75579,30 ）
wrk -c1000 -t8 -d30s --latency http://10.60.82.91/
Nginx: 86% * 16 = 1376%, достигая узкого места ЦП
Работа: ЦП = 40% * 8 = 320%
(2) Locust HttpUser записывает
1 процесс: (10 одновременных, QPS: 512)
Nginx: (ЦП: 8,6%)
Саранча: (ЦП: 100%, одноядерный ЦП становится узким местом)
8 процессов: (100 одновременных, QPS: 3300)
Nginx: (ЦП: 50%)
саранча: (ЦП: 800%, ЦП достигает узкого места)
(4) Тест Jmeter записывает
8 ядер (100 параллелизма, QPS: 38500)
Nginx：（ЦП：397,3%）
Jmeter：（ЦП：681%）
