Clustering multiple Seaside Images behind Apache

Many Web projects start off with a few hands full of users and will probably never reach loads that really put a Smalltalk image under real pressure. However, when it comes to selcting a web framework or platform, one of the first questions people ask is “will it scale to a million users per (choose whatever time unit you want, the whole question is useless in most projects anyway)?”.

While Smalltalk and Seaside perform quite well on a typical PC or a relatively small virtual server, running only one image is not enough for projects that really are successfull.

With Seaside, the solution to scalabality is running several images behind a load balancer (either hardware or Apache with some modules for that). All that’s needed is sticky sessions and some configuration on the balancer to make a Seaside application ready fro prime time.

There are several proposed solutions available, including running Seaside images in the cloud, and just yesterday, Philippe Marschall announced a new one on the Seaside mailing list:

Have you ever wished Apache and Seaside would know each other better?
That Apache could tell Seaside where it was and vice versa? That
Seaside could tell Apache the load of the image so intelligent load
balancing decisions can be made? That you can dynamically add and
remove Seaside images from a cluster without restarting Apache or
messing with configuration files? The guys at JBoss though the same
and wrote mod_cluster

The smalltalk part of this is currently only available for Pharo, but porting it over to other dialects shouldn’t be too hard.

So for those who fear that Smalltalk and Seaside might not scale as high as they hope to need, there are several solutions available, all of which have the charme of not adding any additional complexity to their application’s architecture.

One thought on “Clustering multiple Seaside Images behind Apache

  1. Just to avoid some confusion, the clustering is provided by mod_proxy_balancer. mod_cluster “only” adds dynamic autoconfiguration. Yeah, the naming is not ideal.

    Maybe I should write less prosaic intros.

Comments are closed.