(Migrated) Pool size for outgoing SOAP

(This message has been automatically imported from the retired mailing list)

What exactly is the ‘pool size’ for outgoing SOAP connections in Zato 1.2? =
Can it be used for protecting a remote service from overload by putting a l=
imit to how often it can be called?

Finn Gruwier Larsen

Forbrugerr?det Taenk er en uafhaengig medlemsorganisation, der arbejder for=
et Danmark, hvor alle forbrugere kan traeffe et trygt valg.
F? nyheder, informationer om test, tilbud og gode r?d 1-2 gange om ugen. Ti=
lmeld dig vores nyhedsbreve p? taenk.dk/nyhedsbrev

On 12/19/2013 03:25 PM, Finn Gruwier Larsen wrote:

What exactly is the ‘pool size’ for outgoing SOAP connections in Zato 1.2?

Hello,

this is a per outconn limit for each server worker and this setting
dictates how many simultaneous HTTP connections can be established.

For instance, you have a SOAP outconn ‘my-conn’ with a limit of 10. You
also have 2 servers, 3 workers each, so there will be a total of 10 * 2

  • 3 = your environment as a whole will be able to establish at most 60
    HTTP connections to that particular SOAP resource.

The thing to remember is that it’s a per-worker setting that need to be
multiplied by the number of servers and workers.

This is where the number of workers for each server is configured:

https://zato.io/docs/admin/guide/install-config/config-server.html#main-gunicorn-workers

Can it be used for protecting a remote service from overload by putting a limit to how often it can be called?

If the remote service cannot protect itself, yes, this can be used as a
means of ensuring your own services are on their best behavior.

The question is, why are you worried you will overload the external
service? Is it because you can’t be sure clients that will invoke Zato
are going to honor limits you place?

If so, please have a look at this blog post that shows how to rate-limit
such clients on the load-balancer.

https://zato.io/blog/posts/x-http-request-throttlingg-rate-limiting.html

On 12/19/2013 03:25 PM, Finn Gruwier Larsen wrote:

What exactly is the ‘pool size’ for outgoing SOAP connections in Zato 1.2?

Hello,

this is a per outconn limit for each server worker and this setting
dictates how many simultaneous HTTP connections can be established.

For instance, you have a SOAP outconn ‘my-conn’ with a limit of 10. You
also have 2 servers, 3 workers each, so there will be a total of 10 * 2

  • 3 = your environment as a whole will be able to establish at most 60
    HTTP connections to that particular SOAP resource.

The thing to remember is that it’s a per-worker setting that need to be
multiplied by the number of servers and workers.

This is where the number of workers for each server is configured:

https://zato.io/docs/admin/guide/install-config/config-server.html#main-gunicorn-workers

Can it be used for protecting a remote service from overload by putting a limit to how often it can be called?

If the remote service cannot protect itself, yes, this can be used as a
means of ensuring your own services are on their best behavior.

The question is, why are you worried you will overload the external
service? Is it because you can’t be sure clients that will invoke Zato
are going to honor limits you place?

If so, please have a look at this blog post that shows how to rate-limit
such clients on the load-balancer.

https://zato.io/blog/posts/x-http-request-throttlingg-rate-limiting.html

Hi,

Yes it is because we don’t know how often Zato itself will be called. So I think the blog post you sent addresses the concern.

Finn Gruwier Larsen

On 12/19/2013 03:52 PM, Finn Gruwier Larsen wrote:

Yes it is because we don’t know how often Zato itself will be called. So I think the blog post you sent addresses the concern.

Nice, cool.

I guess it soon will be time to implement the feature in the core.
Implementation-wise this won’t do much more than what the blog post does
except there will be a convenient GUI to specify it per HTTP/SOAP
channel so one won’t have to use HAProxy syntax.

It wasn’t really possible earlier because it depends on HAProxy 1.4+
which wasn’t a default version in various distributions up until
recently but now there’s no reason not to have it.

Hence, it will be done :slight_smile: