2014-11-20 3 views
0

Прежде всего, если это уже задано, но я не могу найти его нигде.У меня есть jmeter botleneck?

Вот сценарий.

У меня есть 8-процессорный Linux-ящик с 8 ГБ памяти, на котором я запускаю простой HTTP-тест jmeter против http://www.xpto.com/info.php, который даст мне типичную информационную страницу php.

Если я запускаю тест с 10 нитями против одной виртуальной машины я получаю результаты: - сводную = 177665 в 158s = 1122,5/s Среднее: 8 Мин: 4 Макс: 217 Err: 0 (0,00%)

Теперь, когда я делаю тот же тест, но с 40 потоками снова 4 VMS, результат не экстраполируется, поэтому я получаю что-то вроде: - summary = 535859 in 338s = 1584.6/s Средн. 24 мин.: 2 Макс. 155 Err: 0 (0.00%)

4 vms находятся на разных гипервизорах, поэтому они не влияют друг на друга. VMS SL6.4 с 8 ГБ памяти и 8 CPUS.

Глядя на ящик jmeter, я вижу, что у меня много свободной памяти, ошибок памяти нет, а в java-процессе используется 80% процессора. Нагрузка на коробке jmeter равна 0,5 с 92% бездействия процессора или около того.

Вопрос в том, что, по вашему мнению, это может быть узким местом jmeter? Я видел такие результаты с любыми тестами, которые я делаю против других URL.

Спасибо за помощь.

--joao

ответ

-1

Нет прямого ответа здесь, лишь некоторые предложения:

  • запустить больше испытаний, скажем 20 до 30 минут при минимуме иметь значимой статистики
  • всегда выполняется разминка работать до фактического теста
  • мелодия должным образом на JVM: хорошей отправной точкой здесь http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/
  • 80% процессора достаточно высока , Не ясно, если это имеет место с 1-го или второго теста

Ciao

+0

как 1584,6/4 лучше, чем 1122,5? – CharlieS

+0

Да, цифры были не такими ясными. Во всяком случае, последние два пункта все еще применяются. с удовлетворением отмечает – sbos61

+0

которые не были ясны? они казались стандартными показателями производительности для меня, TPS и временем отклика. – CharlieS

0

Он появится текущее узкое место, прежде чем попасть в сервер, возможно, в JMeter клиента. Не всегда легко определить причину, это может быть ограничение JVM. Возможно, вы сможете использовать jconsole или jvisualvm, чтобы получить дополнительные подсказки. Также проверьте пропускную способность и другие ограничения, которые могут повлиять на вещи, прежде чем они достигнут сервера.

Используют ли серверы общую базу данных? или общий журнал? Убедитесь, что вы исключили все остальное, прежде чем обвинять клиента.

Легко проверить, является ли JMeter узким местом. Одновременно загружайте сервер из другого клиента и смотрите, влияет ли он на результаты клиента jmeter.

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

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