[Seaside] Re: Seaside and Connection Reset by Peer problems

[David Carlos Manuelda]

Sebastian Sastre wrote:

> To be safe, if you want to go beyond 10 or 15 concurrent connections you
> put additional Pharo image workers so you scale your application
> horizontally. It makes good use of CPU too.
> 
> There is a point in which all stacks have to do it, so yes, I think you
> are testing the borders of one Pharo worker.
> 
> PS: when you use more than one, you have to design your app in a "more
> stateless way" and use sticky sessions
> 
Thanks for your response.

Yes, in previous tests, I made an array with 8 pharo images with nginx as 
load balancer with sticky sessions, and, of course it responded to ~1k 
concurrent petitions without problems, but of course, it still failed beyond 
some point, so that is why I decided to run tests on a single one.

Isn't there any way to change this behavior, for example by letting a higher 
timeout or something else in order not to have those connections rejected so 
soon? Because in my opinion, less than 300 petition per second on the same 
image is not such a high load for it to be starting to drop connections.