[Seaside] Seaside for large, high-traffic sites.

Philippe Marschall philippe.marschall at gmail.com
Fri Sep 11 11:47:44 UTC 2009

2009/9/11 Joseph Harrison <stoicdeveloper at hotmail.com>:
> I have some questions about Seaside scalability.
> In 2008 I wrote a small webapp in Seaside and overall found the experience very
> enjoyable; so much so that I would prefer to do my next project in it.
> Unfortunately, due to its nature, this project will receive considerably more
> traffic than the last, and I am somewhat skeptical of Seaside's (and Squeak's)
> ability to scale.
> I understand Smalltalks (especially Squeak) use green threads for concurrency,
> so obviously a single VM process handling all of those HTTP connections would
> not work. Rather, the solution seems to be some sort of parallel setup with many
> VM processes running simultaneously, each using green threads as needed, with
> some load balancer in front of them. Do they share the same image (in which
> case, I am guessing they can't save the image), or must each have its own?

Each must have it's own image/changes file.

> Next,
> persistence: I need a robust alternative. It need not be a pure object database,
> just something with decent performance that can scale; a mature Squeak interface
> to an RDBMS like PostgreSQL would suffice.

We have made good experiences with the PostgreS driver for squeak,
once you start the image with -notimer

> Additionally, I am curious about
> 64-bit Squeak and if it can work with Seaside.

You'll have trouble finding/building a 64bit image. You can however
use a 64bit VM to run a 32bit image.

> Am I setting myself up for a lot of pain, or is it really practical to use these
> tools with large websites? If Squeak + Seaside isn't enough, how hard is it to
> drop down into C for extra performance or to call out to foreign code?

Keep in mind that that Seaside is written for programmer productivity
and not necessarily high throughput. It does certain things like
snapshoting state that make your life as a programmer easier but cost
CPU cycles. So it really depends on how compute bound you are. As for
calling C code are you doing anything compute intensive? If "all" you
do is fetching data from the database and rendering it then calling
out to C probably doesn't yield in huge gains.

In the end the best advice is probably to figure out what your load is
going to be, write a test for it and run it to see if it works. Yes, I
know this sounds easier than it is.

If mod_proxy_balancer would be an option for you, contact me, I'm
looking for beta testers ;-)


More information about the seaside mailing list