alexander shigin slides

О [нагрузочном]тестировании имониторинге

производительностидля программистов

Александр Шигин, [email protected]

Жизнь проекта

1 Создание.2 Тестирование:

• функциональное;• нагрузочное.

3 Эксплуатация.4 Изменение.

Тестируем

План тестирования:• понять, что мы тестируем;• определить желаемые значения;• определить граничные условия;• протестировать;• проанализировать результат.

Цель тестирования

Если вам надо измерить процент запросов,которые уложатся в 800 мс, не надо измерятьсреднее время ответа: измеряйте проценттаймаутов.

Среднее время ничего неговорит о количестве таймаутов.

время, с неуспех0.0 100.0%0.2 14.5%0.4 10.6%0.6 8.4%0.8 3.6%1.0 2.7%

10

100

1000

10000’hist2.dat’ using 2:xticlabels(1)

Среднее: 0.19

Тестируем

Начинаем тестирование:• тестируем количество запросов в секунду(RPS);

• желаемое значение 1000 RPS;• граничное условие среднее время ответадо 5 мс.

Начнем тест

Что еще нужно для теста?• программа, которую тестируем;• программа, которая тестирует;• несколько серверов.

Начнем тест

• тестируем nginx + fastcgi сервер;• с помощью самописного скрипта, которыйпроверяет вывод;

• тестовые машины: два одинаковыхAMD Athlon64 3500+, FreeBSD 7.0

Первые результаты

тредов 1 2 3 4 5 6 9t, мс 1.9 2.7 3.9 5.2 6.6 5.4 12.0σ 7.0 6.6 4.7 6.9 9.5 7.3 13.3rps 370 543 593 617 626 644 644

• по этим данным, максимум запросов для сервера≈ 600 запросов в секунду;

• при этом сервер не держит параллельную нагрузку.

Подумаем над ними

C 1 2 3 4 5 9user s1 20 34 35 44 46 44sys s1 8 12 12 10 10 12user qa 50 71 80 80 79 84sys qa 8 9 13 17 19 16

s1 — тестируемый сервер

Подумаем над ними

Новые выводы:• максимум для тестовой программы ≈ 644запросов в секунду;

• при этом тестовая программа чрезвычайнолюбит CPU.

Вторая попытка

тредов 1 2 3 4 5 6 9t, мс 1.9 2.7 3.4 4.0 4.6 5.4 8.0σ 4.6 7.0 4.7 8.4 7.1 7.3 6.5rps 512 709 868 916 1036 1076 1078

• максимум RPS ≈ 1036;• при большом количестве параллельных

соединений, время ответа растет.


тредов 1 2 3 4 5 6 9rps 512 709 868 916 1036 1076 1078t/o, % 0 0 6 25 30 51 74

• максимум RPS ≈ 900;• при большом количестве параллельных

соединений, велико количество таймаутов.


C 3 2 3 4 5 9user s1 35 39 57 64 67 79sys s1 10 16 16 13 15 16user qa 27 39 41 49 79 63sys qa 12 16 17 16 19 23

s1 — тестируемый сервер

Хитрый тест

s1 s3 s2

начало тестирования

ожидание

окончание проверки

окончание теста

C RPS t/o, %s1 5 1024 30s3 1 223 20s1 6 1017 51s3 1 186 40


Выводы:• сервер способен обеспечить ≈ 1000запросов в секунду;

• количество тайм-аутов находится на грани.

Общие выводы

• тестируйте одну вещь за раз;• изменяйте одну вещь за раз;• контролируйте ваше окружениенезависимыми тестами;

• не забывайте контролировать весь процесстестирования.

Заглушки

Допущения при тестировании:• заглушки не должны отдаваться за 0 сек;• лучше, если их будет несколько;• не забывайте про ошибки.

Лучшее тестирование — реальноетестирование.

Заглушкиtest serv mock

запрос

20 мс

опрос заглушки

100 мс

Тестирование:20 RPS

Общее время:120 мс

Одновременно≈ 2.4

Заглушкиtest serv mock

запрос

опрос

500 мс

100 мс

Тестирование:20 RPS

Общее время:520 мс

Одновременно≈ 12.4

Apache benchmark

Посмотрим на любимый ab и nginx.Результаты последовательных тестов на трехмашинах:

c 1 2 5 10 15 20 22s1 726 1361 3043 5457 6959 7556 7447s2 1197 2653 5299 10500 14458 15782 15774s3 995 1876 5352 9300 12792 13530 13689

ab vs nginx

Я подкорректировал количество запросов так,чтобы тест на каждой машине шел ≈ минуту.А потом запустил три теста одновременно c 20потоками на каждой машине:

s1 s2 s37750 13321 11323

ab vs nginx

s1 s2 s37750 13321 11323

Даже учитывая небольшое время, когдатестовые машины работали вдвоем,суммарное RPS больше 20 000.

Жизнь проекта

1 Создание.2 Тестирование:

• функциональное;• нагрузочное.

3 Эксплуатация.4 Изменение.

Среднее

Чем хорошо среднее:• среднее легко считать;• его можно считать онлайн;• оно всем понятно.

Среднее

Чем плохо среднее:• два абсолютно разных распределениямогут иметь одно среднее;

• в случаях частого попадания в кеш, выфактически измеряете cache-hit ratio;

• хорошо, если среднее cчитают правильно.

СреднееОпределения среднего по мнениюизготовителей алкогольного тестераDraeger Alcotest 7110 MKIII-C:

X30 +X29+

X28+X27+...

22

2

2

Среднее

Еще один интересный способ посчитатьсреднее.

x̄ =99 · x̄ + x

100

Онлайн среднее и скользящее окно

Как правильно считать среднее:• скользящее окно;• он-лайн.

Он-лайн: считаем сумму времен ответа иколичество ответов. Мониторинг разберется.

Онлайн и скользящее

отклонение до 40%

Среднее

Чем плохо среднее:• два абсолютно разных распределениямогут иметь одно среднее;

• в случаях частого попадания в кеш, выфактически измеряете cache-hit ratio;

• хорошо, если среднее cчитают правильно.

Два и один

Сейчас это выглядит, как два одинаковых сервера.

Два и один

Вот первый.

Два и один

А вот второй.

Два и один

Вы все еще считаете их одинаковыми?

Два и один

Как такое можно проверить?

Очевидный способ — распределение временответа.

Два и один

Как такое можно проверить?

Два и один

Как такое можно проверить?Не менее очевидный, но более простой —стандартное отклонение.

первое второе0.256± 0.197 0.256± 0.296

sd

Что я знаю про стандартное отклонение, σ?• его легко считать;• его можно считать он-лайн;• его надо считать.

σ2 =n∑i

(xi − x̄)2

n − 1=

∑ni x2

i − (∑n

i xi)2/n

n − 1

sd

Что я знаю про стандартное отклонение, σ?

Гистограммы

• Для показа распределения времен ответаможно построить гистограмму;

• гистограммы можно строить онлайн, еслизаранее зафиксировать интервалы;

• основная проблема — визуализация.


• можно строить он-лайн;• главная проблема — графика.

Классы ответа

Квартили

1-ы

й к

варти

ль

2-о

й к

варти

ль

(мед

иан

а)

3-и

й к

варти

ль0 с. 1 с.

Среднее против квартилей

третий квартиль значительно меняетсяа среднее — нет

Среднее против квартилей

Квартили

• их нельзя считать он-лайн;• не все понимают, что это.

Благодарю за внимание

[email protected]/shigin

Вопросы?

[email protected]/shigin

alexander shigin slides

Documents