Dan McCormick wrote:
>
> All this talk of mod_proxy has me wondering: What's the conventional
> wisdom regarding the speed up or load balancing of a server running
> something like Apache::ASP, or anything else that tracks sessions?
>
> If you split things between a proxy and a mod_perl server, the first hit
> would have to go through to the mod_perl server to initiate the session,
> but subsequent requests which may not need the session info could be
> sent to the proxy. Is that possible?
>
> Further, what are the standard ways to load balance a session-tracking
> app across multiple servers when the sessions are stored in memory and a
> given user has to be consistently sent back to the same machine? Can
> round-robin DNS be counted on to send people back to the same server
> over the life of a given session?
>
They can all go through the proxy, the savings is that the proxy
will buffer down the slow internet pipes that clients have, freeing
up the modperl httpd for other things.
About load balancing, we are running the StateDir to a non caching
NFS mount point to a NetApp cluster. There is a problem with NFS
locking, and Apache::ASP can't ensure data integrety over the
network, even if patched up to use NFS locking. Seem like there
might be Linux NFS locking unresolved issues, that people see
with MySQL too.
The upshot is that in this environment, it helps to use SDBM_File,
the default, not DB_File, since DB_File gets corrupted, whereas
SDBM_File may just not save some data if there are too many
concurrent hits, but Apache::ASP will repair the parts that
are necessary, as this is all really concerning a central db that
it keeps.
Further, I have recently done some work in my dev v.19 so that
there will be fewer problems with the Session_OnEnd event, with the
fix being to have one process on one web server being responsible
for session management at any one time, so there are not conflicts
which there would otherwise be.
With sharing state files to an NFS share, the sessions can move
from server to server even if one server goes offline, which
you won't find with solutions that have clients stay on a server
saving session data locally in RAM or disk.
--Joshua
