Seaside for large, high-traffic sites.
Locked
Seaside for large, high-traffic sites.
 
|
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. 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? Thank you in advance. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside for large, high-traffic sites.
|
|
Hi,
just take a look at the GLASS image of GemStone. Here you've got Seaside running inside GemStone/S, a mix of a great Smalltalk VM and an ODBMS. That's a very powerful and convenient environment. http://seaside.gemstone.com/ Regards mue > 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. > > 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? > > Thank you in advance. -- ** ** Frank Mueller / Oldenburg / Germany ** _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Frank,
To reaffirm Frank's suggestion, you should investigate GLASS. As to performance, Please see http://gemstonesoup.wordpress.com/category/scalability/ where Dale describes his tests that handle a mean of 350 requests per second. As to robustness, GemStone is a very strong, industrial- strength database used by a number of large companies, including one in your home town. James Foster On Sep 11, 2009, at 4:44 AM, Frank Mueller wrote: > Hi, > > just take a look at the GLASS image of GemStone. Here you've got > Seaside running inside > GemStone/S, a mix of a great Smalltalk VM and an ODBMS. That's a > very powerful and convenient > environment. > > http://seaside.gemstone.com/ > > Regards > > mue > >> 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. >> >> 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? >> >> Thank you in advance. > > -- > ** > ** Frank Mueller / Oldenburg / Germany > ** > > > _______________________________________________ > 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 |
|
|
I seem to have gotten confused in the names. Frank is replying to
Joseph and we don't know where Joseph is located. Sorry, Frank! --James On Sep 11, 2009, at 5:40 AM, James Foster wrote: > Frank, > > To reaffirm Frank's suggestion, you should investigate GLASS. As to > performance, Please see http://gemstonesoup.wordpress.com/category/scalability/ > where Dale describes his tests that handle a mean of 350 requests > per second. As to robustness, GemStone is a very strong, industrial- > strength database used by a number of large companies, including one > in your home town. > > James Foster > > On Sep 11, 2009, at 4:44 AM, Frank Mueller wrote: > >> Hi, >> >> just take a look at the GLASS image of GemStone. Here you've got >> Seaside running inside >> GemStone/S, a mix of a great Smalltalk VM and an ODBMS. That's a >> very powerful and convenient >> environment. >> >> http://seaside.gemstone.com/ >> >> Regards >> >> mue >> >>> 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. >>> >>> 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? >>> >>> Thank you in advance. >> >> -- >> ** >> ** Frank Mueller / Oldenburg / Germany >> ** >> >> >> _______________________________________________ >> 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 > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside for large, high-traffic sites.
|
|
In reply to this post by Joseph Harrison
You can get good performance out of a VisualWorks image running
Seaside. The Opentalk based HTTP server we use has been tested at over 100 requests per second (I ran those tests on some fairly low end hardware a couple of years ago). At 05:34 AM 9/11/2009, you 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. > >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? > >Thank you in advance. > >_______________________________________________ >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 |
|
|
In reply to this post by Joseph Harrison
On Fri, Sep 11, 2009 at 11:34 AM, Joseph Harrison <[hidden email]> wrote:
I have some questions about Seaside scalability. Ramon has interesting post about scaling Seaside/squeak: http://onsmalltalk.com/scaling-seaside-more-advanced-load-balancing-and-publishing.
I have also been experimenting with Nginx as load balancer and static files web server, all on the Amazon ec2 instances, but there is nothing in real production as of yet. As for database Gemstone is natural choice, as log as it can fit in your budget. If not, maybe something very lightweight ansd simple like CouchDB can fit the bill.
Am I setting myself up for a lot of pain, or is it really practical to use these Well, I guess there will be some pain and experimenting involved, since it is obviously not something that has been done on huge number of sites. Nevertheless, I think Seaside is viable option for high activity sites.
rush _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside for large, high-traffic sites.
|
|
Also there is Magma ODBMS released with high availability and
scalability functional. On Fri, Sep 11, 2009 at 14:59, Davorin Rusevljan <[hidden email]> wrote: > ng involved, since it is obviously not something that ha _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside for large, high-traffic sites.
|
|
In reply to this post by Joseph Harrison
2009/9/11 Joseph Harrison <[hidden email]>:
> 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 ;-) Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside for large, high-traffic sites.
|
|
In reply to this post by Joseph Harrison
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). 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 > [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 |
Re: Seaside for large, high-traffic sites.
|
|
On Sat, Sep 12, 2009 at 8:15 PM, UZONYI Levente <[hidden email]> wrote: Hi! 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. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Offtopic (Was: Re: Seaside for large, high-traffic sites.)
|
|
Hi!
On Sun, 13 Sep 2009, Mariano Martinez Peck wrote: > 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 > Just saw that the squeaksource repository is writeable, so I uploaded the code there, the package comment explains the modifications. Cheers, Levente _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Offtopic (Was: Re: Seaside for large, high-traffic sites.)
|
|
2009/9/13 UZONYI Levente <[hidden email]>:
> Hi! > > On Sun, 13 Sep 2009, Mariano Martinez Peck wrote: > >> 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 >> > > Just saw that the squeaksource repository is writeable, so I uploaded the > code there, the package comment explains the modifications. +1 way to go Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside for large, high-traffic sites.
|
|
In reply to this post by Levente Uzonyi-2
UZONYI Levente wrote:
> ... (we also have a partial implementation of the > v3 protocol which we are about to test in another project). What is the motivation to support the v3 protocol? Speed? Compatibility? Did you choose to build from scratch or just tweak the V2 code? -- Yanni _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside for large, high-traffic sites.
|
|
In reply to this post by Joseph Harrison
Hi Joseph,
> 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 Benchmarks for a Magma application client in various network configurations can be found here: http://wiki.squeak.org/squeak/5606 Scaling with Seaside using Magma as a back-end is achieved via the manner you described, multiple db-sessions per image * multiple images hosting one application. Read scale is added or subtracted dynamically by merely starting or stopping additional server images anywhere on the network. Since each server image hosts its own copy of the repository (all synchronized in nearly real-time) highly-available 24x7 operation is enjoyed as well. Write scale is increased by linking multiple, multi-server, repositories, although not in as dynamic a manner as read-scale can be adjusted.. - Chris _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Offtopic (Was: Re: Seaside for large, high-traffic sites.)
|
|
In reply to this post by Levente Uzonyi-2
On Sun, Sep 13, 2009 at 1:09 PM, UZONYI Levente <[hidden email]> wrote: Hi! Thanks Levente! I wanted to see your changes to see if there is something that I can also apply to SqueakDBX. I liked your proxy for rows which override the doesNotUnderstand: Actually, I remember that in Smalltalks 2008 Marcelo Cortez suggest me a similar solution for that. I am a bit complicated right now but I get deeper with this as soon as possible. Thanks for sharing this. Best, Mariano Cheers, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Re: Seaside for large, high-traffic sites.
|
|
In reply to this post by Yanni Chiu
Hi!
On Mon, 14 Sep 2009, Yanni Chiu wrote: > UZONYI Levente wrote: >> ... (we also have a partial implementation of the >> v3 protocol which we are about to test in another project). > > What is the motivation to support the v3 protocol? Speed? Compatibility? > Did you choose to build from scratch or just tweak the V2 code? Our main motivation is speed. We started tweaking the v2 code (as you can see in the repository) but realized that we can achieve more with a different design. So we decided to write the code from scratch and it was obvious to use the v3 specification. Our current v3 implementation doesn't give more features than the v2, we only implemented the simple query protocol. The only functional advantage we have in v3 is that we know the transaction status of a connection, which comes handy with our connection pool. Cheers, Levente > > -- > Yanni > > _______________________________________________ > 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 |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |