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/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
