[squeak-dev] Server timeouts and 504 return codes
asqueaker at gmail.com
Tue Jan 29 21:59:36 UTC 2019
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"
> 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:
> > 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.
More information about the Squeak-dev