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

[Mariano Martinez Peck]

On Sat, Sep 12, 2009 at 8:15 PM, UZONYI Levente <leves at elte.hu> wrote:

> Hi!
>
> On Fri, 11 Sep 2009, Joseph Harrison wrote:
>
> 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?
>> 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. Additionally, I am curious
>> about
>> 64-bit Squeak and if it can work with Seaside.
>>
>>
> We are using Squeak with Seaside (2.8) and Postgresql as backend for a
> site. We got an 8 core (1.86GHz Xeon) server running Apache, (at most) 8
> images and Postgres. The images can't save since they are using the same
> image and changes file (but we don't want to save at all). A single Squeak
> image with Seaside can handle about 75-100 'hello world' requests/second.
> With this setup we measured 160-200 requests/second for an average page
> (with data fetched from database).
>
> We are using a modified version of the PostgresV2 package which gives us
> extra speed and features (we also have a partial implementation of the v3
> protocol which we are about to test in another project).
>
>
Very interesting. Can you explain me a bit more in details the improvements
you did in the PostgresV2 to improve its performance?

Thanks a lot.

Mariano


> We found that 64-bit vms are slower than 32-bit versions, so we are using
> 32-bit vms with ia32-libs.
>
> Failover isn't that good with this setup since if an image crashes, all
> users of that image lose their session data (sticky sessions). Storing state
> in a datastore could help, but we never had an image crash.
>
> 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?
>>
>
> FFI is pretty easy, writing plugins are a bit harder, but i wouldn't bother
> with this. Scaling Seaside horizontally is much easier.
>
> Cheers,
> Levente
>
>
>
>> Thank you in advance.
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20090913/e464c874/attachment-0001.htm