It's probably because coroutines in ngx_lua are a bit weird as they have had to be re-implemented to work in the Nginx environment.
Switching lua-resty-http to a purely functional non-coroutine approach is/was something we were going to do.
The co-routine approach is nice and elegant from a code PoV but isn't JIT'able and appears to have other performance issues.
It was kinda assumed that not being able to JIT the cosocket operations would be the bottleneck in the realworld but it was never benchmarked or investigated very far.
PR to switch pintsized/lua-resty-http to a function based body reader would be very much appreciated, as would any benchmarks/flamegraphs that show the coroutine reader as an issue!
Thanks
Hamish
On Wednesday, 13 June 2018 15:17:34 UTC+1, Gene Unigovski wrote:
I did some performance testing to compare lua-resty-requests with lua-resty-http - for requests/responses with small body (under 1K) lua-resty-requests could be up to 10x times faster. I also have a hacked version of lua-resty-http where I had removed coroutines usage for request_uri() function - it is also more than 10x faster then the original one (for some reason that I don't completely understand running body_reader as a coroutine wrapped function causes a huge performance degradation).
On Friday, June 8, 2018 at 6:12:03 AM UTC-4, tokers wrote:
> yes!
>
>we mostly use the existing lua-resty-http module to pull routing information from an internal api (then cached into nginx for a bit). for this application, speed is most important.
>
> i'm thinking of building an auto-cert module for letsencrypt, and this package might be better for that because the speed concern isn't as sensitive.
OK. I will do some benchmarks and paste the result in the README.md (also synchronize it here). BTW, PR is welcome if you think some code path is not efficient enough :).
