Concurrency question

Howdy folks,

I'm currently evaluating Seaside for a project and have a question.  How does it handle concurrent connections?  I understand that the underlying Squeak VM does not use OS threading, and so the system does not take advantage of SMP.  That is OK with me.  However, I'm curious if Seaside will still be able to handle the situation where we get one or more LONG http requests.  Will these cause undo lag to other users trying to connect.

To give some background for my concern, I've been using Rails, which is strictly single threaded, so a long response to a single request can cause other users to be blocked out from that rails instance.  I'm hoping Seaside will not have this problem.

Thanks in advance,

Jeffrey Straszheim
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Jeffrey,

Welcome to Seaside!

You are right that most implementations of Smalltalk are single-
threaded. There is, however, a built-in process scheduler ("green  
threads") that allows code to be forked. If your long-running request  
is compute bound and you reduce its priority or yield periodically  
then other requests should be handled. If your long-running request is  
waiting on an external resource (the typical example is credit card  
verification), you might be able to code things so that that  
particular request is in a separate OS thread or takes advantage of a  
non-blocking socket wait. I believe that these comments apply to  
Squeak's implementation of Seaside (and possibly the VW implementation  
as well).

In GemStone each VM is also single-threaded but you can have multiple  
VMs attached to the same object space. Here the typical approach is to  
use Apache to round-robin requests to separate VMs so that blocking is  
less of an issue. See http://seaside.gemstone.com and http://gemstonesoup.wordpress.com 
  for more info.

James


On Feb 17, 2008, at 12:00 PM, Jeffrey Straszheim wrote:

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

James Foster wrote:
> In GemStone each VM is also single-threaded but you can have multiple
> VMs attached to the same object space. Here the typical approach is to
> use Apache to round-robin requests to separate VMs so that blocking is
> less of an issue. See http://seaside.gemstone.com and
> http://gemstonesoup.wordpress.com for more info.
That sounds a little more complex than I want to deal with for my first
Seaside app (baby steps for me).  What I want to ensure is that while a
long running thread is handling one HTTP request, other arriving HTTP
requests will still be honored -- they are not in Rails, for instance,
which *requires* you to run multiple instances to have any hope of low
lag for clients (and even then, if all of your instances are busy,
everyone else waits).

I fully understand the difference between green threads and os level
threads, and blocking vs. non-blocking I/O.  I just want to know what
Seaside actually does.

Thanks for your reply.

--
Jeffrey Straszheim
http://straszheim.50megs.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2008/2/18, Jeffrey Straszheim <[hidden email]>:
Seaside does the same thing the underlying platform does. It really
depends what is causing your http request to be long running.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Jeffrey,

        most Smalltalks will use one OSProcess for the VM and from there it will
make its own instances of the Process class  managed by the VM itself. That has
the advantage of making them very cheap to create. Smalltalk can create a lot of
processes (a few thousands) quite stable.

        I'm not sure about what you mean with LONG http request. Time to load?
KBs of http? session duration?

        Seaside web apps use to scale with pretty much the same structure as
ruby. You should make them scale horizontally by making N smalltalk images run
you application(s) and a load balancer with sticky sessions in front of them.

        The rule of thumb for Seaside says you should use few concurrent
sessions per images and lot of images to balance the load of the user sessions.

        The 'few' number actually should be dictated by your application and the
smalltalk you choose. For Squeak use to be near 10.

        cheers,

Sebastian Sastre

 

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi!

Jeffrey Straszheim <[hidden email]> wrote:
Let me try to give a straight and simple answer for *Squeak*, hopefully
factually correct.

Seaside in Squeak normally runs using KomHttpServer. KomHttpServer
spawns the handling of each HTTP request in a Squeak Process of its own
(green thread). This means that yes, Seaside is fully concurrent. The
low level Socket code in Squeak is aynchronous, and while it could be
improved (I think Dan Shafer has written quite a lot of details about
that on the Squeak Swiki) it works quite good IMHO.

BUT... if your response handling code uses say the current ODBC via FFI
to make calls that take a lot of time - then those calls will block the
whole VM. But unless you do that - then yes, it is concurrent.

Now, as a sidenote - setting up multiple images using HAProxy was quite
simple, I just did that for a customer.

And going even more off topic - given Igor's new Hydra VM we could
probably create a more scalable SMP-capable solution. :)

regards, Göran
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Jeffrey Straszheim wrote:
>
> I fully understand the difference between green threads and os level
> threads, and blocking vs. non-blocking I/O.  I just want to know what
> Seaside actually does.
Jeffrey,

In Squeak, HTTP requests for _different_ sessions are processed
concurrently via green threads (a thread is forked for each HTTP
request). HTTP requests for the _same_ session are serialized via a
session-specific Semaphore.

You do not _have_ to run multiple vms to handle concurrent requests in
Seaside...

Hope this helps,

Dale
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Dale Henrichs wrote:
> In Squeak, HTTP requests for _different_ sessions are processed
> concurrently via green threads (a thread is forked for each HTTP
> request). HTTP requests for the _same_ session are serialized via a
> session-specific Semaphore.
Interesting.  Is is possible to create multiple sessions for the same
physical user?

The reason I ask is I'm currently designing an interactive application,
which has been prototyped in Rails.  However, it requires asynchronous
updates from the server frequently.  Currently I'm making an Ajax
connection to poll the server every 3 seconds.

Obviously this won't scale.

I'm interested in trying out the "long polling" comet technique
(described here: http://en.wikipedia.org/wiki/Comet_%28programming%29).  
This basically involves making a background Ajax request to the server,
and just *waiting* until an event occurs.

Meanwhile, however, the user may be doing stuff on other parts of the
page, and making Ajax requests that will need to be serviced.

Is there a good way to do this in Seaside?

(Note: currently I know *nothing* about Seaside except having read
through one of the tutorials.  I want to know if it will meet my needs
before I crack down to learn it.)

Thanks in advance, and thanks to everyone who replied.

--
Jeffrey Straszheim
http://straszheim.50megs.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Jeffrey Straszheim wrote:
> Dale Henrichs wrote:
>> In Squeak, HTTP requests for _different_ sessions are processed
>> concurrently via green threads (a thread is forked for each HTTP
>> request). HTTP requests for the _same_ session are serialized via a
>> session-specific Semaphore.
> Interesting.  Is is possible to create multiple sessions for the same
> physical user?
Let's be clear here. When you hit Seaside with an URL like
http://example.com/seaside/examples/counter, Seaside creates a unique
session with an ID that will be embedded in all of the dynamic URLs
generated from there on out for that session. If the same physical users
opens a new tab in the same browser and enters the
http://example.com/seaside/examples/counter again, they will have a
separate Seaside session created, that is totally independent from the
other session.

If the user had clicked on the ++ link for example, she would see an URL
like the following
http://example.com/seaside/examples/counter?_s=lhDEQmkRhiXILSEU&_k=hySRdyan 
in the browser. If she copied that URL and mailed it to a colleague (or
pasted it into a separate tab in the browser), then both of them could
issue simultaneous requests against the same session and those requests
would be serialized by the server.

I am less familiar with the ins and outs of Ajax, so I'll let someone
else field the rest of your questions.

Dale
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 19/02/2008, Jeffrey Straszheim <[hidden email]> wrote: How Seaside can be responsible for this? An Ajax request is sent from
browser side. And surely if it sent, Seaside will be happy to serve
it.

> Is there a good way to do this in Seaside?


--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > I'm interested in trying out the "long polling" comet technique
> > (described here: http://en.wikipedia.org/wiki/Comet_%28programming%29).
> > This basically involves making a background Ajax request to the server,
> > and just *waiting* until an event occurs.

There is a comet package in the official seaside squeaksource repository.
There are some comet applications examples ...

To launch the web server, instead of WAKom (for normal web server)
you'll have to lauch WAListener...Something like:
WAListener startOn: 8888.
Then browse ot localhost:8888...


> > (Note: currently I know *nothing* about Seaside except having read
> > through one of the tutorials.  I want to know if it will meet my needs
> > before I crack down to learn it.)
> >

Do you already have an image ? if no, I suggest you take a squeak web
one made by Damien - Thr last betais here:
http://squeak.ofset.org/squeak-web/beta/sq3.10-7159web08.02.1.zip

I don't remember if comet is loaded, but if no, open monticello, then
the seaside repository and you should find comet.

hth

Cédrick

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I think I understand.  It sounds like it will work perfectly for me.  
Thanks.

Dale Henrichs wrote:
--
Jeffrey Straszheim
http://straszheim.50megs.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

cdrick wrote:
> Do you already have an image ? if no, I suggest you take a squeak web
> one made by Damien - Thr last betais here:
> http://squeak.ofset.org/squeak-web/beta/sq3.10-7159web08.02.1.zip
>
> I don't remember if comet is loaded, but if no, open monticello, then
> the seaside repository and you should find comet.
>  
Thanks.  I'll check it out.

--
Jeffrey Straszheim
http://straszheim.50megs.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Is there a good way to do this in Seaside?

There is a package called Comet in the Seaside repository. Instead of
WAKom you need to use a streaming server (such as WAListener).

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli wrote:
> There is a package called Comet in the Seaside repository. Instead of
> WAKom you need to use a streaming server (such as WAListener).
>  
Well, I'm planning to use the "make a new connection after each
response" method, so I don't think I'll need a fancy server.  Of course,
I have zero experience in this.

--
Jeffrey Straszheim
http://straszheim.50megs.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside