Тесты производительности linux/apache на 1000 одновременных запросов

У меня есть Linux-сервер следующей конфигурации:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 62
Model name:            Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
Stepping:              4
CPU MHz:               2500.046
BogoMIPS:              5000.09
Hypervisor vendor:     Xen
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              25600K
NUMA node0 CPU(s):     0

RAM = 2 GB

Я делаю тест в j-метре с 500 одновременными потоками и периодом нарастания 10 секунд. У меня пропускная способность 3/сек. Как я узнаю, что эта пропускная способность хорошая или плохая. Есть ли какие-либо тесты, с которых я могу сравнить свои результаты, т.е. пропускная способность и отклонение.


linux throughput jmeter load-testing
person clint    schedule 03.08.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Не существует «хорошей» или «плохой» пропускной способности как таковой. В зависимости от целей приложения и ожиданий ваших заинтересованных сторон пропускная способность 3/с может быть идеальной или ужасной. Итак, первый вопрос: каковы ваши цели по эффективности?

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

введите здесь описание изображения

поэтому, не имея точек с меньшим и большим количеством пользователей, вы на самом деле не знаете, находитесь ли вы на фазе «роста» или «плато». Также график пропускной способности может выглядеть так:

введите здесь описание изображения

поэтому, имея только одну точку, вы также не знаете, растет ли она, находится на плато или ухудшается.

Наконец, количество пользователей — это только один параметр, который может влиять на пропускную способность. Другие могут включать в себя: типы запросов, размер данных, продолжительность теста (например, длинный тест может показать тенденцию к увеличению или ухудшению пропускной способности, невидимую для более короткого теста) и т. д.

Итак, мое предложение было бы таким:

  • Узнайте у заинтересованных лиц, каковы цели вашего приложения. Например, какой пропускной способности ожидают разработчики.

  • Установите надежный эталон с точки зрения операций. Что-то, что представляет «большинство пользователей». Убедитесь, что ваш тест учитывает операции, которые могут резко изменить пропускную способность (или, по крайней мере, знать, какие из них вы намеренно исключили).

  • Установите продолжительность теста, который, скорее всего, покажет стабильную пропускную способность (для некоторых приложений это может быть 10 минут, для других — 24 часа).

  • Не изменяя тест, запустите его несколько раз с увеличением количества пользователей (например, 100, 200, 300, ...), чтобы получить график. Продолжайте увеличивать количество пользователей до тех пор, пока приложение не сломается или производительность не упадет до неприемлемого уровня.

Это даст вам полную картину и хорошее понимание того, является ли пропускная способность 3/сек лучшим, на что способно ваше приложение, или оно может работать намного лучше. И достаточно ли лучшее, что может сделать ваше приложение, для ваших заинтересованных сторон.

Кстати, второе изображение было взято с этой страницы, что действительно хорошо читай по теме.

person Kiril S.    schedule 03.08.2016