Тайм-аут встроенного Jetty под нагрузкой

Question

У меня есть приложение akka (Java) с потребителем Camel-Jetty. При некоторой минимальной нагрузке (около 10 TPS) наш клиент начинает видеть ошибку HTTP 503. Я попытался воспроизвести проблему в нашей лаборатории, и похоже, что Jetty не может справиться с перекрывающимися HTTP-запросами. Ниже приведен вывод из apache bench (ab):

AB отправляет 10 запросов, используя один поток (т. е. один запрос за раз)

ab -n 10 -c 1 -p bad.txt http://192.168.20.103:8899/pim

Benchmarking 192.168.20.103 (be patient).....done


Server Software:        Jetty(8.1.16.v20140903)
Server Hostname:        192.168.20.103
Server Port:            8899

Document Path:          /pim
Document Length:        33 bytes

Concurrency Level:      1
Time taken for tests:   0.61265 seconds
Complete requests:      10
Failed requests:        0

Requests per second:    163.23 [#/sec] (mean)
Time per request:       6.126 [ms] (mean)
Time per request:       6.126 [ms] (mean, across all concurrent requests)

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   1.0      1       2
Processing:     3    4   1.8      5       7
Waiting:        2    4   1.8      5       7
Total:          3    5   1.9      6       8

Percentage of the requests served within a certain time (ms)
  50%      6
  66%      6
  75%      6
  80%      8
  90%      8
  95%      8
  98%      8
  99%      8
  100%      8 (longest request)

ab отправляет 10 запросов, используя два потока (до 2 запросов одновременно):

ab -n 10 -c 2 -p bad.txt http://192.168.20.103:8899/pim


Benchmarking 192.168.20.103 (be patient).....done


Server Software:        Jetty(8.1.16.v20140903)
Server Hostname:        192.168.20.103
Server Port:            8899

Document Path:          /pim
Document Length:        33 bytes

Concurrency Level:      2
Time taken for tests:   30.24549 seconds
Complete requests:      10
Failed requests:        1
   (Connect: 0, Length: 1, Exceptions: 0)

// obmited for clarity


Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.9      1       2
Processing:     3 3005 9492.9      4   30023
Waiting:        2 3005 9492.7      3   30022
Total:          3 3006 9493.0      5   30024


Percentage of the requests served within a certain time (ms)
  50%      5
  66%      5
  75%      7
  80%      7
  90%  30024
  95%  30024
  98%  30024
  99%  30024
  100%  30024 (longest request)

Я не верю, что причал это плохо. Надеюсь, это просто проблема конфигурации. Это настройка для моего URI потребителя верблюдов:

"jetty:http://0.0.0.0:8899/pim?replyTimeout=70000&autoAck=false"

Я использую Акка 2.3.12 и Верблюд-Джетти 2.15.2

Answer 1

Это был мой плохой код: информация об отправителе (клиенте) была перезаписана перекрывающимися запросами. Сообщение об ошибке 503 было отправлено из-за истечения времени ожидания Jetty.

Answer 2

Jetty, несомненно, не так уж и плох, и должен быть в состоянии обрабатывать десятки тысяч соединений со многими тысячами TPS.

Трудно диагностировать из того, что вы сказали, кроме Jetty не отправляет 503, когда он находится под нагрузкой.... разве возможно, если развернут фильтр защиты Отказ в обслуживании? (и ab выглядело бы как атака DOS.... которая в принципе и не является хорошим генератором нагрузки для бенчмаркинга).

Так что вам нужно отследить, кто / что отправляет эти 503 и почему.