[squeak-dev] Server timeouts and 504 return codes

Chris Muller asqueaker at gmail.com
Tue Jan 29 21:59:36 UTC 2019

Hi Tobias,

Given that we're in agreement, this hostility is unnecessary and
puzzling.  Lighten up.

> >>> I know that it mostly a cost and reconfiguration thing, but has there been any thought to maybe make multiple servers? With the front end doing a round robin to distribute the load? I’m saying this without knowing what kind of loads the server is experiencing, or whether there are log files that record the activity.
> >>
> >>
> >> That's what squeaksource3 on gemstone is doing, actually.
> >> Three FCGI-servers (gems) serving the web interface and files, if necessary.
> >> also, one extra gem to collect stale seaside sessions and one extra gem to do async things like update statistics and send out emails.

Paul mentions a "cost and configuration" trade-off, which you
acknowledge you implemented as "Three FCGI servers" (what I refer to
as a "dragster") for squeaksource3.  But then this...

> >> (The Squeak version of that uses Squeak processes for that and is probably not as resilient…)

... made an opportunity to draw a distinction between "resilience" and
UX, which is _important_ too!

> > And yet, when I just went to:
> >
> >   http://ss3.gemtalksystems.com/ss/Projects
> >
> > and entered "squeaksour" in the Search field to look for your
> > referenced packages, my web browser sat there spinning for AT LEAST 30
> > seconds (felt like more, but I didn't time it) before returning with
> > the result list.  This is one of the issues I've had with
> > squeaksource3 since the beginning.  The same first-search on
> > squeaksource.com hosted on single-threaded Squeak 3.x image running on
> > interpreter VM is more than an order-of-magnitude faster.
> "Oh hey Tobias, you said you made the mc directory listing fast. Look how slow the search on that site is ooooo"
> Really?
> I know that the search on that instance is slow.

Then you shouldn't be offended.  We're discussing server implementations.

> That's one of the several reasons why I/Dale actually want to upgrade the instance to the latest code base. If someone's inclined, we have that all tracked (https://github.com/krono/squeaksource3/issues/,  especially https://github.com/krono/squeaksource3/issues/64 and such)
> The directory listing is fast. Like these ones:
>         http://ss3.gemtalksystems.com/ss/STON/
>         https://sdk.krestianstvo.org/sdk/croquet/
> >
> > My point being, I agree that "dragster tech" can be fun, but if the
> > extra complexity it brings sinks the UX, it was all only just
> > masturbation.  The real challenge is not to use nginx, but to actually
> > provide a UX that is better-enough to pay for the extra cost and
> > complexity.
> >
> "dragster tech"? are you kidding? "extra complexity"? Its called divided responsibilities and industry best practices.

Right.  But you ignored my point about UX.

> But you know what? Ask Levente to put map.squeak.org out there on port 80. See how fast it dies.
> Best of luck.

You don't have to be so patronizing.  You made this point very
strongly earlier, and it is something which I was already aware, but
not experienced in, so glad to learn from you and Levente about the
best tools and practices to have a resilient Squeak-based server app
on the net.

> The instance with the latest code base is btw: https://sdk.krestianstvo.org/sdk, ss3 at gemtalksystems is arguably the oldest one.
> But still.

Still what?  Chill out.


> I have no part in this belly dance anymore.
> Good day.
>         -Tobias
> *plonk*

More information about the Squeak-dev mailing list