[Seaside] Question about Comanche & Seaside

[Nevin Pratt]

Julian Fitzell wrote:

> Bergel Alexandre wrote:
> > I have discover these both app this week end, and I have naturally 
> some questions...
> >
> > Does Comanche and Seaside are scalable. How many connections could 
> be supported ?
> >
> > Regards,
> > Alexandre
> >
>
> Welcome!
>
> I personally would use Apache (with IAModLisp) instead of Comanche if
> possible, if only because it's more well tested and gives more
> flexibility in terms of other modules like SSL, and makes it easier to
> mix static and dynamic content.  That said, I haven't had any stability
> problems with Comanche, just haven't tested it on anything large.
>

I see multiple sides to the "scalability" issue:

1. Scalability in terms of supportable web connections/hits per second.
2. Scalability in terms of readily-available support modules, like SSL 
or other "security" features.
3. Scalability in terms of the business-rule functionality performed by 
the site.

For example, if you are a large industrial company that sells wafer-fab 
equipment and chip-creation support products, your site likely will have 
very little traffic (compared to, say, eBay, yahoo, amazon.com, cnn.com, 
google, etc.).  Consequently, investing a lot of resources to support 
multi-hundred hits per second, etc., is going to be a waste of resources.

On the other hand, the required "functionality" of your wafer-fab site 
might be large, as your site might actually be a very complicated site 
with business-rule hooks into GL, AP, AR, Bill-of-materials drill-downs, 
just-in-time ordering systems, etc.

And finally, your wafer-fab site might not even care about SSL, 
encryption, and the like, since the final customer order would likely be 
a face-to-face meeting.

So, as usual, it just depends.

I personally think that Comanche is unsurpassed for the third type of 
scalability-- no need for Apache at all if that is what you mean by 
"scalability".

As for the first type of "scalability", if all you are doing is serving 
static pages, Apache is the clear performance winner over Comanche. 
 However, if you wish to also "wire" those pages into a Squeak backend 
to make them dynamic pages, then including Apache in the mix could 
potentially add to the overhead as well as just add another layer that 
can break-- in that case, why not just let Squeak do it all?

So, "it just depends".

I personally think that most site creators have grandiose dreams of site 
popularity that never materialize, and so they have a tendency to 
over-engineer for the first type of scalability, and it typically proves 
to be a waste of time.  In other words, I would be inclined to just use 
Comanche, unless it can be demonstrated that Comanche just isn't sufficient.

As for the comment that Apache makes it easier to mix static and dynamic 
content, I firmly disagree with that statement, and indeed, I think it 
is just the opposite-- unless by "dynamic content" you mean the typical 
"dynamic content" approach used by the rest of the world (cgi, perl, 
JSP, etc.), rather than letting Smalltalk do it.  In that case, of 
course, it is a true statement.

So, "it just depends".

Nevin