HTTP client for private API

bogdan · 2018-06-27T18:00:33+00:00

Hello,I'm struggling to use Openresty as a reverse-proxy with client certificates and CRL checking. On service start up it will quickly crash and o...

HTTP client for private API

bogdan

Hello, everybody

We are running a system of multiple NginX instances (OpenResty), the communication between them being made via HTTP requests. We will need to extend and optimize this feature, so I have 2 questions:

1. Which method of the following 2 is faster?
a. Using proxy:
- client NginX has an upstream defined towards the backend and an internal route (location) that is consumed using "ngx.location.capture"

http {
        
upstream backend {
      
      server 127.0.0.1:11001;
            keepalive 32;
        }

...

        
       location ~ /api/(call1|call2)$ {
            internal;
            proxy_read_timeout 600s;
            proxy_send_timeout 600s;

            proxy_connect_timeout 600s;
            proxy_ignore_client_abort
 on;
            proxy_buffering
 on;
            proxy_buffers
 64 8k;
            proxy_set_header
 Connection "Keep-Alive";
            proxy_set_header
 Host $host;
            proxy_set_header Http-Host $http_host;

            proxy_set_header 
X-Real-IP $remote_addr;
            proxy_pass http://backend;
            proxy_intercept_errors on;
       }

}

    

And in Lua:

local res = ngx.location.capture("/api/call1", {['method'] = ngx.HTTP_POST, ['body'] = cjson.encode({["action"] = 'some_action', ['payload'] = 'some payload'})})

b. Using a cosocket HTTP client library from Lua. I would prefer this (second) method because I find it more straightforward, but I am concerned of performance differences. Is this something signigicant or not?

2. The second question is related with the point b. of the previous question: which HTTP client would be fastest for our case? Here are some options I found:
- https://github.com/bakins/lua-resty-http-simple - pretty straightforward, enough for our needs. This is what we are using currently, but this is pretty old (2014)
- https://github.com/pintsized/lua-resty-http - very popular, updated this year
- https://github.com/timebug/lua-resty-httpipe - also updated this year, but seems less popular
- https://github.com/tokers/lua-resty-requests - I found some recommendations for this one; the author sais it has good performance; also updated recently (most recently)
Do you have any other recommendations? Are there any tests regarding the performance of these libs?
Any other advices?

Thank you

Best regards,
Bogdan

zchao1995

Hello!

For the first question, the subrequest mechanism in OpenResty is synchronous,i.e. current request will be blocked until the corresponding subrequests are complete, each subrequest's response body will be read into memory. While with the cosocket scheme, you can process the HTTP response body with the stream way. So the latter is more memory friendly. I haven't do the benchmark for these ways but I think it is tiny.

For the second question. My lua-resty-requests is still under experimental and not ready for the production (I will enhance it as soon as possible) . The lua-resty-httpipe was written by one of my colleague, it is being used in our production evvironment and is vary stable. So you might use this one, ofcourse the lua-resty-http is also good :)

peter_booth

I think OpenResty is an undiscovered gem. It has saved my life, or at least the life of the whatever site I was working on in so many ways. It’s like a Swiss Army knife that can be applied in so many ways to solve problems. So here you are presenting two approaches to solving a problem and asking us to offer an opinion.

But I don’t really know - what us the real issue that you are wanting solve?

Why is it an issue?

Sent from my iPhone

On Jun 27, 2018, at 6:00 AM, Bogdan Irimia <bo...@digitair.ro> wrote:

Hello, everybody

We are running a system of multiple NginX instances (OpenResty), the communication between them being made via HTTP requests. We will need to extend and optimize this feature, so I have 2 questions:

1. Which method of the following 2 is faster?
a. Using proxy:
- client NginX has an upstream defined towards the backend and an internal route (location) that is consumed using "ngx.location.capture"

http {
upstream backend {
server 127.0.0.1:11001;
keepalive 32;
}
...

location ~ /api/(call1|call2)$ {

internal;
proxy_read_timeout 600s;
proxy_send_timeout 600s;
proxy_connect_timeout 600s;

proxy_ignore_client_abort on;
proxy_buffering on;
proxy_buffers 64 8k;
proxy_set_header Connection "Keep-Alive";
proxy_set_header Host $host;
proxy_set_header Http-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://backend;
proxy_intercept_errors on;
}
}

And in Lua:

local res = ngx.location.capture("/api/call1", {['method'] = ngx.HTTP_POST, ['body'] = cjson.encode({["action"] = 'some_action', ['payload'] = 'some payload'})})

b. Using a cosocket HTTP client library from Lua. I would prefer this (second) method because I find it more straightforward, but I am concerned of performance differences. Is this something signigicant or not?

2. The second question is related with the point b. of the previous question: which HTTP client would be fastest for our case? Here are some options I found:
- https://github.com/bakins/lua-resty-http-simple - pretty straightforward, enough for our needs. This is what we are using currently, but this is pretty old (2014)
- https://github.com/pintsized/lua-resty-http - very popular, updated this year
- https://github.com/timebug/lua-resty-httpipe - also updated this year, but seems less popular
- https://github.com/tokers/lua-resty-requests - I found some recommendations for this one; the author sais it has good performance; also updated recently (most recently)
Do you have any other recommendations? Are there any tests regarding the performance of these libs?
Any other advices?

Thank you

Best regards,
Bogdan

.

bogdan

I am trying to find which is the best way to implement this "private API" architecture in terms of speed (performance). This is the problem I am trying to solve: implementing the API calls in the most efficient way.

Peter Booth wrote:

I think OpenResty is an undiscovered gem. It has saved my life, or at
least the life of the whatever site I was working on in so many ways.
It’s like a Swiss Army knife that can be applied in so many ways to
solve problems. So here you are presenting two approaches to solving a
problem and asking us to offer an opinion.

But I don’t really know - what us the real issue that you are wanting
solve?
Why is it an issue?

Sent from my iPhone

On Jun 27, 2018, at 6:00 AM, Bogdan Irimia <bo...@digitair.ro
<mailto:bo...@digitair.ro>> wro te:

Hello, everybody

We are running a system of multiple NginX instances (OpenResty), the
communication between them being made via HTTP requests. We will need
to extend and optimize this feature, so I have 2 questions:

1. Which method of the following 2 is faster?
a. Using proxy:
- client NginX has an upstream defined towards the backend and an
internal route (location) that is consumed using "ngx.location.capture"
http {
upstream backend {
server 127.0.0.1:11001;
keepalive 32;
}
...

location ~ /api/(call1|call2)$ {
internal;
proxy_read_timeout 600s;
proxy_send_timeout 600s;
proxy_connect_timeout 600s;
proxy_ignore_client_abort on;
proxy_buffering on;
proxy_buffers 64 8k;
proxy_set_header Connection "Keep-Alive";
proxy_set_header Host $host;
proxy_set_header Http-Host $http_host;
proxy_set_header X-Real-IP $remote_addr; proxy_pass http://backend;
proxy_intercept_errors on;
}
}

And in Lua:
localres =ngx.location.capture("/api/call1", {['method']
=ngx.HTTP_POST, ['body'] =cjson.encode({["action"] ='some_action',
['payload'] ='some payload'})})

b. Using a cosocket HTTP client library from Lua. I would prefer this
(second) method because I find it more straightforward, but I am
concerned of performance differences. Is this something signigicant
or not?

2. The second question is related with the point b. of the previous
question: which HTTP client would be fastest for our case? Here are
some options I found:
- https://github.com/bakins/lua-resty-http-simple - pretty
straightforward, enough for our needs. This is what we are using
currently, but this is pretty old (2014)
- https://github.com/pintsized/lua-resty-http - very popular, updated
this year
- https://github.com/timebug/lua-resty-htt pipe - also updated this
year, but seems less popular
- https://github.com/tokers/lua-resty-requests - I found some
recommendations for this one; the author sais it has good
performance; also updated recently (most recently)
Do you have any other recommendations? Are there any tests regarding
the performance of these libs?
Any other advices?

Thank you

Best regards,
Bogda.

bogdan

Thank you for your quick answer.
Abouth the lua-resty-httpipe, is it as good in terms of performance as your lua-resty-requests? I found in one of your older threads this text:

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.
(from Gene Unigovski)

Is lua-resty-httpipe as fast? :)

Thanks

tokers wrote:

Hello!

For the first question, the subrequest mechanism in OpenResty is synchronous,i.e. current request will be blocked until the corresponding subrequests are complete, each subrequest's response body will be read into memory. While with the cosocket scheme, you can process the HTTP response body with the stream way. So the latter is more memory friendly. I haven't do the benchmark for these ways but I think it is tiny.

For the second question. My lua-resty-requests is still under experimental and not ready for the production (I will enhance it as soon as possible) . The lua-resty-httpipe was written by one of my colleague, it is being used in our production evvironment and is vary stable. So you might use this one, ofcourse the lua-resty-http is also good :)

.

rpaprocki

Why not do some testing and benchmarking for your specific use case? You’ll probably get faster and better answers that way, as opposed to asking opinionated questions on a mailing list :)

On Jun 27, 2018, at 04:46, Bogdan Irimia <bo...@digitair.ro> wrote:

Thank you for your quick answer.
Abouth the lua-resty-httpipe, is it as good in terms of performance as your lua-resty-requests? I found in one of your older threads this text:

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.
(from Gene Unigovski)

Is lua-resty-httpipe as fast? :)

Thanks

tokers wrote:

Hello!

For the first question, the subrequest mechanism in OpenResty is synchronous,i.e. current request will be blocked until the corresponding subrequests are complete, each subrequest's response body will be read into memory. While with the cosocket scheme, you can process the HTTP response body with the stream way. So the latter is more memory friendly. I haven't do the benchmark for these ways but I think it is tiny.

For the second question. My lua-resty-requests is still under experimental and not ready for the production (I will enhance it as soon as possible) . The lua-resty-httpipe was written by one of my colleague, it is being used in our production evvironment and is vary stable. So you might use this one, ofcourse the lua-resty-http is also good :)

.

bogdan

I just wanted to know the general consensus :)

Thanks

Robert Paprocki wrote:

Why not do some testing and benchmarking for your specific use case? You’ll probably get faster and better answers that way, as opposed to asking opinionated questions on a mailing list :)

On Jun 27, 2018, at 04:46, Bogdan Irimia <bo...@digitair.ro> wrote:

Thank you for your quick answer.
Abouth the lua-resty-httpipe, is it as good in terms of performance as your lua-resty-requests? I found in one of your older threads this text:

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.
(from Gene Unigovski)

Is lua-resty-httpipe as fast? :)

Thanks

tokers wrote:
Hello!

For the first question, the subrequest mechanism in OpenResty is synchronous,i.e. current request will be blocked until the corresponding subrequests are complete, each subrequest's response body will be read into memory. While with the cosocket scheme, you can process the HTTP response body with the stream way. So the latter is more memory friendly. I haven't do the benchmark for these ways but I think it is tiny.

For the second question. My lua-resty-requests is still under experimental and not ready for the production (I will enhance it as soon as possible) . The lua-resty-httpipe was written by one of my colleague, it is being used in our production evvironment and is vary stable. So you might use this one, ofcourse the lua-resty-http is also good :)
.

gpuhome

...and - a general consensus is the most elusive thing to find - for different applications there are different pros and cons... :)

...for starters - in terms of "performance" - are you looking for the lowest latency or the highest throughput?... :)

...for highest throughput you can wrap each outgoing API call (doesn't mater if it is ngx.location.capture or http client) in ngx.thread (in case if your application needs to make a lot of quick API calls really fast) - that would solve blocking issues...

...also - you are welcome to use my "hacked" version of lua_resty_http - it is ugly but it works fine for request_uri() calls - https://github.com/Unigoge/openresty-bundle/blob/master/openresty-1.13.6.1/bundle/lua-resty-http-0.0.7/lib/resty/http.lua (just don't expect any kind of support from me :p )...

Thanks,
Gene

On Wednesday, June 27, 2018 at 9:04:46 AM UTC-4, bogdan wrote:

I just wanted to know the general consensus :)

Thanks

Robert Paprocki wrote:

Why not do some testing and benchmarking for your specific use case? You’ll probably get faster and better answers that way, as opposed to asking opinionated questions on a mailing list :)

On Jun 27, 2018, at 04:46, Bogdan Irimia <bog...@digitair.ro> wrote:

Thank you for your quick answer.
Abouth the lua-resty-httpipe, is it as good in terms of performance as your lua-resty-requests? I found in one of your older threads this text:

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.
(from Gene Unigovski)

Is lua-resty-httpipe as fast? :)

Thanks

tokers wrote:
Hello!

For the first question, the subrequest mechanism in OpenResty is synchronous,i.e. current request will be blocked until the corresponding subrequests are complete, each subrequest's response body will be read into memory. While with the cosocket scheme, you can process the HTTP response body with the stream way. So the latter is more memory friendly. I haven't do the benchmark for these ways but I think it is tiny.

For the second question. My lua-resty-requests is still under experimental and not ready for the production (I will enhance it as soon as possible) . The lua-resty-httpipe was written by one of my colleague, it is being used in our production evvironment and is vary stable. So you might use this one, ofcourse the lua-resty-http is also good :)
.