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.
Regards, Chris
I have no part in this belly dance anymore.
Good day. -Tobias
*plonk*