Victor,

Am 14.12.16 um 19:23 schrieb Vitor Medina Cruz:

If I tell you that my current estimate is that a Smalltalk image with Seaside will not be able to handle more than 20 concurrent users, in many cases even less.��

Seriously? That is kinda a low number, I would expect more for each image. Certainly it depends much on many things, but it is certainly very low for a rough estimate, why you say that?

seriously, I think 20 is very optimistic for several reasons.

One, you want to be fast and responsive for every single user, so there is absolutely no point in going too close to any limit. It's easy to lose users by providing bad experience.

Second, in a CRUD Application, you mostly work a lot with DB queries. And you connect to all kinds of stuff and do I/O. Some of these things simply block the VM. Even if that is only for 0.3 seconds, you postpone processing for each "unaffected" user by these 0.3 seconds, so this adds to significant delays in response time. And if you do some heavy db operations, 0.3 seconds is not a terribly bad estimate. Add to that the materialization and stuff within the Smalltalk image.

Seaside adapters usually start off green threads for each request. But there are things that need to be serialized (like in a critical Block). So in reality, users block each other way more often than you'd like.

So if you asked me to give a more realistic estimation, I'd correct myself down to a number between 5 and probably a maximum of 10 users. Everything else means you must use all those fancy tricks and tools people mention in this thread.
So what you absolutely need to do is start with an estimate of 5 concurrent users per image and look for ways to distribute work among servers/images so that these blocking situations are down to a minimum. If you find your software works much better, congratulate yourself and stack up new machines more slowly than initially estimated.

Before you turn around and say: Smalltalk is unsuitable for the web, let's take a brief look at what concurrent users really means. Concurrent users are users that request some processing from the server at they very same time (maybe within an interval of 200-400msec). This is not the same as 5 people being currently logged on to the server and requesting something sometimes. 5 concurrent users can be 20, 50, 100 users who are logged in at the same time.

Then there is this sad "share all vs. share nothing" argument. In Seaside you keep all your objects alive (read from db and materialized) between web requests. IN share nothing, you read everything back from disc/db whenever a request comes in. This also takes time and ressources (and pssibly blocks the server for the blink of an eye or two). You exchange RAM with CPU cycles and I/O. It is extremely hard to predict what works better, and I guess nobody ever made A/B tests. It's all just theoretical bla bla and guesses of what definitely must be better in one's world.

Why do I come up with this share everything stuff? Because it usually means that each user that is logged on holds onto a load of objects on the server side (session storage), like their user account, shopping card, settings, last purchases, account information and whatnot. That's easily a list of a few thousand objects (and be it only Proxies) that take up space and want to be inspected by the garbage collector. So each connected user not only needs CPU cycles whenever they send a request to the server, but also uses RAM. In our case, this can easily be 5-10 MB of objects per user. Add to that the shadow copies that your persistence mechanism needs for undo and stuff, and all the data Seaside needs for Continuations etc, and each logged on users needs 15, 20 or more MB of object space. Connect ten users and you have 150-200 MB. That is not a problem per se, but also means there is some hard limit, especially in a 32 bit world. You don't want your server to slow down because it cannot allocate new memory or can't find contiguous slots for stuff and GCs all the time.

To sum up, I think the number of influencing factors is way too high to really give a good estimate. Our experience (based on our mix of computation and I/O) says that 5 concurrent users per image is doable without negative impact on other users. Some operations take so much time that you really need to move them out of the front-facing image and distribute work to backend servers. More than 5 is probably possible but chances are that there are operations that will affect all users and with every additional user there is a growing chance that you have 2 or more requesting the yery same operation within a very short interval. This will make things worse and worse.

So I trust in you guys having lots of cool tools around and knowing loads of tricks to wrench out much more power of a single Smalltalk image, but you also need to take a look at your productivity and speed in creating new features and fixing bugs. Sometimes throwing hardware at a problem like growth and starting with a clever architecture to scale on multiple layers is just the perfect thing to do. To me, handling 7 instead of 5 concurrent users is not such a big win as long as we are not in a posotion where we have so many users that this really matters. For sites like Amazon, Google, Facebook etc. saving 40% in server cost by optimizing the software (investing a few man years) is significant. I hope we'll soon change our mind about this question ;-)

So load balancing and services outsourced to backend servers are key to scalability. This, btw, is not smalltalk specific (some people seem to think you won't get these problems in Java or Ruby because they are made for the web...).

Joachim