Как загрузить тестовые события, отправленные сервером?

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


server-sent-events benchmarking load-testing
person Andrew    schedule 06.08.2013    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Поскольку Server-Sent Events это просто HTTP, вы можете использовать утилиту siege. Вот пример:

siege -b -t 1m -c45 http://127.0.0.1:9292/streaming

Где:

  • -b тестовый режим, т. е. без ожидания между соединениями
  • -t 1m контрольный показатель за 1 минуту
  • -c45 количество одновременных подключений
  • http://127.0.0.1:9292 хост моего сервера разработки и пользовательский порт
  • /streaming Конечная точка HTTP, которая отвечает Content-Type: text/event-stream

Выход:

Lifting the server siege...      done.

Transactions:                 79 hits
Availability:             100.00 %
Elapsed time:              59.87 secs
Data transferred:           0.01 MB
Response time:             23.43 secs
Transaction rate:           1.32 trans/sec
Throughput:             0.00 MB/sec
Concurrency:               30.91
Successful transactions:          79
Failed transactions:               0
Longest transaction:           30.12
Shortest transaction:          10.04
person sashaegorov    schedule 22.04.2016
comment
я пытаюсь использовать siege Server-Sent Events, и когда я запускаю эту команду siege -c2 -d10 -t30s streaming_end_point, я получаю далее, по сути, все возвращает 0, но на самом деле соединения выполняются успешно, есть идеи? - person Sai; 15.10.2016
comment
@Sai, это довольно странно, не могли бы вы опубликовать журнал сервера разработки? Также передача опции --verbose в siege может предоставить некоторую информацию. - person sashaegorov; 15.10.2016
comment
спасибо за ответ, я очень ценю это. Я попытался запустить осаду с --verbose, но не смог получить никакой информации о том, почему он возвращает все как 0. Я проверил журналы DEV и смог увидеть, что конечная точка потоковой передачи выполняется количество раз, указанное в -c, каждый запрос будет связан с UUID, и я смог увидеть UUID в журналах, но не получил никаких данных из осады. Я использую осадную версию SIEGE 4.0.2. - person Sai; 16.10.2016
comment
Я создал вопрос stackoverflow.com/questions /40048289/ с более подробной информацией о сервисе и SSE. Я также анализировал инструмент GATLING для выполнения нагрузочного теста для SSE и нашел немного информации здесь http://gatling.io/docs/2.2.2/http/sse.html. С другой стороны, когда я использую осаду против обычного запроса/разрешения, она работает как шарм, но для этой конкретной конечной точки потоковой передачи она не возвращает никакого значения. - person Sai; 16.10.2016

arrow_upward
2
arrow_downward

Я пошел по простому пути создания сценария оболочки, который инициирует N фоновых заданий cURL, которые подключаются к конечной точке SSE моей службы. Чтобы получить точный синтаксис cURL, откройте инструменты веб-разработчика Chrome -> вкладка «Сеть» -> щелкните правой кнопкой мыши запись запроса к конечной точке SSE и выберите в контекстном меню «Копировать как cURL».

Затем вы вставляете эту команду в сценарий оболочки, который примерно выглядит так:

#!/bin/bash

i=0;
while [ $i -lt 50 ] ;do
    [PASTE YOUR cURL COMMAND HERE] -s -o /dev/null &
    i=`expr $i + 1`;
done

Это добавит 50 фоновых заданий cURL при каждом запуске. Обратите внимание, что я добавил в команду Chrome cURL параметры -s -o /dev/null. Это для запуска cURL в автоматическом режиме и для подавления любого вывода.

В моем случае сервис был реализован на NodeJ, поэтому я использовал process.hrtime() для высокой точности синхронизации. измерьте задержку цикла через N подключенных клиентов для передачи данных.

Результаты были в порядке: он обслужил более 1000 активных подключений примерно за 0,02 секунды.

Имейте в виду, что если вы запускаете сервер + клиенты cURL с одной и той же машины, вы, вероятно, достигнете ограничений ОС, равных open files. Чтобы увидеть ограничения open file на вашем Linux-боксе (обычно это 1024), запустите:

$ ulimit -n

Чтобы не достичь 1000+ активных cURL, которые я получил, вы можете:

  • запускать их с нескольких машин
  • или увеличьте этот предел (см. sysctl)

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

person Thalis K.    schedule 26.03.2014