2015-09-19 3 views
0

У меня есть приложение node.js, которое я контролирую с помощью службы «Мониторинг и аналитика».Bluemix. Мониторинг и аналитика. Время отклика неверно

Я использую jMeter (или SOAP UI) для выполнения теста нагрузки против моего приложения node.js. Среднее время отклика, которое я получаю с помощью инструментов тестирования нагрузки, составляет 900 мс, но на графике мониторинга и аналитики отображается 111 мс.

С другой стороны, пропускная способность правильно. (110tx/сек на JMeter, 6600tx/мин bluemix)

Могу ли я что-то недоразумение в bluemix графиков? Почему эта разница в 800 мсек?


EDIT: 800ms накладные расходы могут быть вызваны из-за моего компьютера/инструментов/сети, но в то время как я бегу тест с 100 одновременных потоков в моей локальной среде, в другом месте (сеть/место) один сингл вызов в службу занимает также 900 мс, если моя среда является причиной в другом месте, время отклика должно быть чуть больше 111 мс, а не 900 мс, поэтому я думаю, что это не связано с моей инфраструктурой.

спасибо.

ответ

2

Служба мониторинга и аналитики измеряет время, необходимое для приложения Node.js для создания ответа HTTP с точки, в которой обрабатывается запрос.

Вот простой пример HelloWorld аннотированный с точками измерения:

var http = require('http'); 
var port = (process.env.VCAP_APP_PORT || 3000); 
var host = (process.env.VCAP_APP_HOST || 'localhost'); 

http.createServer(function handler(req, res) { 
    // TIMER STARTS 
    res.writeHead(200, {'Content-Type': 'text/plain'}); 
    res.end('Hello World'); 
    // TIMER ENDS 
}).listen(port, host); 

Это означает, что два (потенциально крупные) Задержки не измеряются:

  1. Сеть латентность

    т.е. , время, затрачиваемое сетью на отправку запроса от браузера к серверу Node.js, а также ответ, который будет передан обратно.

  2. Запрос HTTP очереди задержки/глубина

    т.е.. время, которое требуется от Node.js, получающего HTTP-запрос, до такой степени, что его можно обрабатывать. Поскольку Node.js имеет цикл событий, который выполняется в одном потоке, одновременно может обрабатываться только одно действие «блокировки». Если обработка запросов HTTP-запроса полностью блокируется, как в примере HelloWorld (не происходит асинхронных вызовов), каждый HTTP-запрос обрабатывается в последовательном порядке.

Сво второй из них, которые, вероятно, будет причиной вашей задержки - HTTP-запросы выполняются в последовательной, поэтому мониторинг и обслуживание Analytics говорит вам, что он принимает 111ms построить ответ на запрос, но есть еще 800 мс, где запрос поставлен в очередь, ожидая его запуска.

+0

Это имеет смысл. Это официально документировано где-то? – Jxadro

+0

Я просил включить информацию о Крисе в документацию по продукту. –

0

Разница заключается в том, что у вас нет задержки в сети от клиента к серверу и от сервера к клиенту. Bluemix будет записывать только задержку, когда он получит звонок, и когда ответ погаснет. В то время как с jMeter вы записываете, когда ответ покидает ваш компьютер, а затем, когда ответ вернется (загрузка данных также).

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

+0

Возвращенные данные: «{'ret25': 'ok'}". Я думаю, что есть тест-инструмент в bluemix. Я попытаюсь использовать это и снова проверить. – Jxadro

+0

100 одновременных потоков могут быть причиной 900 миллисекунд, если вы выполняете некоторые запросы и вычисления, но не возможно, что если вы просто вернете то, что это может достигать 900 мс. – DevAlien

+0

Хорошо, я собираюсь предположить, что проблема в моей стороне, я буду исследовать и опубликовать, если найду проблему, спасибо. – Jxadro

Смежные вопросы