13 messages in com.googlegroups.pylons-discussRe: Pylons Evaluation -Questions
FromSent OnAttachments
voltron27 Apr 2007 11:44 
Shannon -jj Behrens27 Apr 2007 16:49 
Cliff Wells27 Apr 2007 17:21 
Shannon -jj Behrens27 Apr 2007 17:27 
voltron27 Apr 2007 20:50 
Cliff Wells27 Apr 2007 23:03 
voltron28 Apr 2007 02:43 
Dan28 Apr 2007 05:06 
voltron28 Apr 2007 08:27 
Cliff Wells28 Apr 2007 16:19 
Dan28 Apr 2007 19:48 
Shannon -jj Behrens01 May 2007 16:38 
Shannon -jj Behrens01 May 2007 16:40 
Subject:Re: Pylons Evaluation -Questions
From:Dan (dan-@public.gmane.org)
Date:04/28/2007 05:06:47 AM
List:com.googlegroups.pylons-discuss

IMHO. I never implemented memcache, but the distributed memory concept is *not* by itself scalable architecture. The key is session data. Typically (as in default Pylons setup) session data is tied to physical hardware... your web server. To make use of memcache, one would first need to implement scalable architecture, such as the 'share nothing' approach.

Again, I'm not claiming to be an expert on the 'share nothing' architecture, but my understanding is that 'share nothing' stores all data in the database... even session data. This way, it doesn't matter what web server in your farm takes users requests. They will all ask the database (the db will be your bottleneck) but at least they will *mostly* know how to access and store data.

So the basic point to my post is that scalable architecture is more about theory than specific tools. The theory behind building scalable web applications is a growing subject in system engineering that I find interesting. You can check a decent article about myspace.com struggles at - [1]http://www.baselinemag.com/article2/0,1540,2084131,00.asp

'memcache' is a tool, when applied to a scalable architecture, could provide performance improvements.

Dan

Cliff Wells wrote:

On Fri, 2007-04-27 at 17:27 -0700, Shannon -jj Behrens wrote:

On 4/27/07, Cliff Wells [2]<clif@public.gmane.org> wrote:

Out of curiosity, how is this ugly? This should be mostly handled transparently by the proxy (i.e. sends same sessions to same backend).

If one Web server dies, all the users using that Web server lose their sessions. That sucks. It also limits the effectiveness of the load balancer. It can only redistribute *new* users instead of each new request.

Ah. Makes sense. I guess reading books *does* help!

or b) use a session server (less ugly).

And what do you recommend for this?

If I had to make the decision today, I'd probably use memcache.

mmm. Memcached rocks.

I've not seen this approach, so I'm curious (or maybe the proxy acts as a session server, so we're talking about the same thing?).

What do you mean the proxy acts as a session server? I don't know of any load balancers who can act as session servers.

I wasn't sure exactly what you meant by "session server", but now I do. So you are correct. I was thinking perhaps you meant "external process that maintains sessions across backends" in which case some load balancers do.

By the way, this topic is covered nicely in "Scalable Internet Architectures" and "Building Scalable Web Sites".

(weird, de ja vu ;)

If only I had time to read actual books rather than bug people on the net for answers...

Cliff

--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss-/JYPx@public.gmane.org To unsubscribe from this group, send email to pylons-discuss-unsubscribe-/JYPx@public.gmane.org For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---

References

Visible links 1. http://www.baselinemag.com/article2/0,1540,2084131,00.asp 2. mailto:clif@public.gmane.org