SstHttpClient startUp/shutDown

I have a probably stupid question regarding the lifecycle of an SstHttpClient.

All example code of course always start with a send of startUp and ends with shutDown. But I couldn't find any information as to whether this should be the case for each and every single request.

Our Kontolino! server is currently learning a few new tricks that involves communiction with quite a few 3rd party services via HTTP (restful API calls mostly).

For our first few uses we kept shutting Down the http client after every single request/response. I wonder if this is necessary and / or if it could cause troubles if we reuse SstHttp clients several times.

Do you have any experiences with this? Should we stick to shutting down after each request or is it okay to use an SstHttpClient multiple times? Are there restrictions, like timouts of underlying infrastructure (sockets etc.)? Platform differences (Windows/Linux)?

This may sound like a weird question, so please feel free to ask if it's unclear what I mean...

Joachim

That's certainly not a stupid question.  Most httpclients in various languages spend some time talking about what it means to reuse/share them.

If you can reuse the httpclient for multiple requests...that would be much more performant and resource friendly.
SstHttpClient is associated with a transport configuration (keyed by transportScheme) and so those are really the set of session-like configurations that must stick between multiple calls.  The most important one being the http or https scheme.  You'll need separate clients for each scheme.  But there are other parameters like proxy configuration.

The internal 'synchronizer' also protects critical sections so mutliple requests from different smalltalk procs would be fine.

The SstHttpClient was refactored for our upcoming release and tested more...but I'm assuming everything I said above is true  in something like 8.6.3.  I only recall some proxy related bugs that were fixed.

Here is some sample code to see the basic ways you could use the client.  Single fetches being almost 3x more expensive than the reusable scenarios.
Timings would differ based on what page you are going to ...but it's just an example.  There is a law of diminishing returns when using the multiple smalltalk processes that kicks in pretty quick...but that might be just for this page since it is a very quick response.

On Tuesday, July 3, 2018 at 4:19:59 AM UTC-4, Joachim Tuchel wrote:

I have a probably stupid question regarding the lifecycle of an SstHttpClient.

All example code of course always start with a send of startUp and ends with shutDown. But I couldn't find any information as to whether this should be the case for each and every single request.

Our Kontolino! server is currently learning a few new tricks that involves communiction with quite a few 3rd party services via HTTP (restful API calls mostly).

For our first few uses we kept shutting Down the http client after every single request/response. I wonder if this is necessary and / or if it could cause troubles if we reuse SstHttp clients several times.

Do you have any experiences with this? Should we stick to shutting down after each request or is it okay to use an SstHttpClient multiple times? Are there restrictions, like timouts of underlying infrastructure (sockets etc.)? Platform differences (Windows/Linux)?

This may sound like a weird question, so please feel free to ask if it's unclear what I mean...

Joachim

Hi Seth,

thank you for this explanation.

Your samples clearly show that runtime can be reduced by up to 30%, which is really not bad, especially in a server environment:

Client per Request Time: 1591
Client per Request Time: 1248
Client per Multiple Request Time: 1030
Client per Multiple Request Time: 1061
Threaded Requests Time: 952
Threaded Requests Time: 920

So if I understand correctly, it is not only possible but also sensible to not shutDown an SstHttpClient immediately after each and every call. You can reuse a client as long as there is no change to the proxy config or the transport scheme (and a few more "esoteric") parameters. Reusing the client for multiple target URLs should not be a problem iiuc, not even if the SstHttpClient keeps "standing by" for hours... It does'nt actually lock any system resources while it is inactive (meaning not actively sending a request or waiting for a response, which can take a while).

Your threaded example makes me think whether using a pool of http clients in a Seside image wouldn't be a good idea... If you have multiple users connecting to 3rd party APIs, it would probably be good to have one readily start(ed)Up http client per user, right?

Sigh, there are soo many areas in which there is soo much to learn, and a developer's day is just too short...

Joachim