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

Question

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

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

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

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

Answer 2

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