Closed thibaultcha closed 6 years ago
Interestingly I cannot reproduce this issue. I have got two APIs defined, direct and validated. They call the same service. The difference is that validated has the middleman plugin activated that calls a static resource served by a lighttpd instance. Performance is affected when the plugin is activated, as expected, but it is nowhere near as terrible as 1 req/s. Here are my results (doesn't really matter if lighttpd responds with 200 OK or something different).
$ ./wrk -t 4 -c 80 -d 30s http://localhost:8011/direct
Running 30s test @ http://localhost:8011/direct
4 threads and 80 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 41.44ms 3.29ms 82.13ms 98.22%
Req/Sec 484.54 38.01 650.00 65.17%
57976 requests in 30.06s, 21.84MB read
Requests/sec: 1928.64
Transfer/sec: 743.87KB
$ ./wrk -t 4 -c 80 -d 30s http://localhost:8011/validated
Running 30s test @ http://localhost:8011/validated
4 threads and 80 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 52.33ms 36.80ms 535.28ms 96.99%
Req/Sec 412.09 72.43 570.00 66.64%
48749 requests in 30.04s, 18.37MB read
Requests/sec: 1622.71
Transfer/sec: 626.20KB
@Sverik , nevertheless, @thibaultcha is right. It's not a big change tho. I just need to find some time to make it.
@pantsel Sure thing, I just wanted to calm myself and other potential users down by running some tests to see if it's reallty that bad. I thought I'd share the results since I didn't experience the issue. Not denying it's still problematic, for sure.
@Sverik Performance will still depend on the number of workers in use (a single one in my case) and the I/O delay introduced by the middleman upstream (which in your cases seems to be relatively fast).
Users of this plugin should be aware that it uses LuaSocket instead of ngx_lua's cosockets, which will be blocking and horribly hurt the performance of theirs Kong nodes. A simple test on a local instance shows that this plugin throttles Kong's performance to about 1req/s: