Server sizing - 100 concurrent users

Hi,

I have been asked to quote on a web application and am considering
using Squeak / Seaside.

I have to specify the server environment that is required or desirable
for the application.  I do not have the time or luxury of building the
application then sizing the configuration to suit.

So the limitations are that the server will be linux distribution.  I
would like to know if their are any known issues with RedHat / CentOS.

Memory,  the client specifies that we have capacity for 100 concurrent
user sessions.

To handle 100 sessions, I assume that we will need the type of
configuration used for
DabbleDB - Apache load balancer, multiple images, etc.

What RAM requirements should be necessary - my guess is that the
application will be fairly simple - say Sushi shop  x 5.  (IE about 5
modules each roughly as complex as Sushi shop.)

The application has only very limited need for a database.  Currently
I anticipate serializing the object model for each user.

Any known issues with 64 bit chips for the VM?

Any comments would be welcome.

Thanks

--

Edward Stow
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 6/1/07, Edward Stow <[hidden email]> wrote:

> So the limitations are that the server will be linux distribution.  I
> would like to know if their are any known issues with RedHat / CentOS.

Dabble DB runs on dual xeons running CentOS.

> Memory,  the client specifies that we have capacity for 100 concurrent
> user sessions.
>
> To handle 100 sessions, I assume that we will need the type of
> configuration used for
> DabbleDB - Apache load balancer, multiple images, etc.

Yep, I would split that into 10-20 VMs, which, even with just 2GB of
RAM in the server, gives you up to 100MB for each of them, which
should be plenty.

> Any known issues with 64 bit chips for the VM?

No, it's sometimes difficult to build a VM on a 64 bit distro, but if
you build the binary elsewhere it runs just fine.

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Avi

Thanks for the reply -- I however have just re-read my clients
requirements and the *mininum* number of concurrent users is100 so the
max could be a lot more.

So I need to assumen that the maximum number of concurrent user
sessions was 500 or even 1000.  Is their any experience with running
this number of users with Seaside and if so what specification
machine?

I point out the application is fairly simple - no database requirement
or concurrent access to data among the user sessions.


On 02/06/07, Avi Bryant <[hidden email]> wrote:

--

Edward Stow
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Fri, 1 Jun 2007, Avi Bryant wrote:

What's the point of having 10-20VMs (not sure whether you mean virtual
machines as in OS virtualization or squeak's VM) on a single server? I
would understand having 2-4 (one image per cpu/core).

rado
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 6/3/07, radoslav hodnicak <[hidden email]> wrote:

> What's the point of having 10-20VMs (not sure whether you mean virtual
> machines as in OS virtualization or squeak's VM) on a single server? I
> would understand having 2-4 (one image per cpu/core).

For two reasons.  One is that you keep the individual image size of
each down, which helps out the garbage collector and also makes it
unlikely that you'll run into evil problems with Squeak on linux in
particular that can cause segfaults when the image size gets up over
500MB or so.

The other is that Squeak tends to drop socket connections when there's
too many concurrent clients, so it's good to spread that over multiple
VMs.

In a perfect world you'd certainly only want one per core, but these
are the practical realities we've found.

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

radoslav hodnicak wrote:
>
> What's the point of having 10-20VMs (not sure whether you mean virtual
> machines as in OS virtualization or squeak's VM) on a single server? I
> would understand having 2-4 (one image per cpu/core).
>
> rado


Well having more doesn't hurt.  For example, now that Erlang uses native
threads to create extra VMs you can configure how many to create.  From
what I have seen they tend to get the best numbers with 3 or 4 per CPU,
not 1 per.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Disclaimer: VisualWorks]

There are also plenty of things that block the VM on occasion, for
instance our RSA auth calls sometimes take upwards of 3 seconds during
which time VM is waiting for external call to return, so having less
users per VM helps substantially if we want to provide as much of a
seamless experience as possible.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
virtual
> > machines as in OS virtualization or squeak's VM) on a single server?
I
> > would understand having 2-4 (one image per cpu/core).
> >
> > rado
>
>
> Well having more doesn't hurt.  For example, now that Erlang uses
native
> threads to create extra VMs you can configure how many to create.
From
> what I have seen they tend to get the best numbers with 3 or 4 per
CPU,
> not 1 per.
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside