[squeak-dev] Server timeouts and 504 return codes

Tobias Pape Das.Linux at gmx.de
Tue Jan 29 07:45:54 UTC 2019

> On 29.01.2019, at 01:08, Chris Muller <asqueaker at gmail.com> wrote:
>>> On 28.01.2019, at 03:56, John Pfersich via Squeak-dev <squeak-dev at lists.squeakfoundation.org> wrote:
>>> 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.
>> (The Squeak version of that uses Squeak processes for that and is probably not as resilient…)
> 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"


I know that the search on that instance is slow. 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:

> 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.

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

Best of luck.

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

But still.

I have no part in this belly dance anymore.

Good day.


More information about the Squeak-dev mailing list