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

У меня есть приложение akka (Java) с потребителем верблюжьей пристани. При некоторой минимальной нагрузке (около 10 TPS) наш клиент начинает видеть ошибку HTTP 503. Я попытался воспроизвести проблему в нашей лаборатории, и оказалось, что пристань не может обрабатывать перекрывающиеся HTTP-запросы. Ниже приведен вывод скамьи apache (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"

Я использую akka 2.3.12 и camel-jetty 2.15.2.


java jetty akka akka-camel
person Khoa Nguyen    schedule 23.07.2015    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

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

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

person gregw    schedule 24.07.2015

arrow_upward
0
arrow_downward

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

person Khoa Nguyen    schedule 24.07.2015