Re: Session and Multi Server Architecture

Per Jessen wrote:

Stut wrote:

Of course, processing power, network capacity and memory are all very cheap these days, so it's easy to put on the Microsoft hat and be wasteful.

In my mind you're exchanging traffic over a local network (probably 1Gbps) for a less resilient load balancing system. By locking users to particular machines you don't allow for the possibility that you'll end up with a large number of users on any given server while others lie idle.

There's no question of locking users to particular machines, nor of uneven distribution. LVS will distribute evenly or according to weights.

Indeed, but you must see that making the decision of which server to use per request will result in a more even distribution than deciding once per session.

Personally I'd always opt for a solution where my hardware will be utilised as evenly as possible regardless of user patterns.

Certainly.

I'll be using memcache as a simple cache. I hate sessions and avoid them for anything but the most trivial sites. The main sites I work with no longer use sessions because they add a pointless layer of complexity to any application that need to scale beyond a single machine.

Well, we have no problem using sessions on our web-cluster (with LVS session persistency).

Good for you.

Do you write your apps specifically for use with memcached? I did think of that, but I thought people would prefer not have their apps tied directly to memcached. I guess it's a matter of choice.

No, but that's purely a result of the way I approach any programming problem. I try to deal in layers of abstraction at every level. Coincidentally I'm modifying my cache layer today to support memcache as a backend option since the current file-based backend is experiencing scalability problems due to recent traffic increases. Since the app is purposefully layered and modular I don't need to touch anything other than this layer. Having said that I don't see a problem with depending on a particular piece of software as a dependency of the application. Your app already requires PHP, and most likely requires a bunch of extensions to be present so I don't see a major problem in adding memcache to that list, especially if it means you can use it much more efficiently by assuming it's available. Since I'm just replacing a file-based cache with memcache I'm certain it won't be as efficient as it would be if I dove into the rest of the code and changed it to use memcache directly. For a start I'd be able to make use of requesting multiple keys at once which is not going to be possible with the way it works at the moment, but it will get past the scalability limits currently being tapped. -Stut -- http://stut.net/