You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Dan McCormick <da...@metro.net> on 2000/04/27 17:22:52 UTC
speed up/load balancing of session-based sites
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?
Dan
Re: speed up/load balancing of session-based sites
Posted by Joshua Chamas <jo...@chamas.com>.
Dan McCormick wrote:
>
> Are you using Apache::ASP to generate sessions?
>
> Has anyone tried using Tie::DBI to store Apache::ASP sessions in a db?
> That might solve problems with NFS sharing issues, though it might also
> bog things down.
>
If you just want a simple $Session holder, you can always define
the $Session object as an Apache::Session in your global.asa
Script_OnStart, and it will be available for every script.
This could then be easily database driven.
The reason why I have not done a db version of the Apache::ASP
session is that the session management logic is non trivial,
when you are talking about realtime session garbage collection,
and the handling of the Session_OnEnd event.
--Joshua
Re: speed up/load balancing of session-based sites
Posted by Adi <ad...@certsite.com>.
"Jeffrey W. Baker" wrote:
>
> On Fri, 28 Apr 2000, Adi wrote:
>
> > "Jeffrey W. Baker" wrote:
> > >
> > > On Fri, 28 Apr 2000, Dan McCormick wrote:
> > >
> > > > "Jeffrey W. Baker" wrote:
> > > > >
> > > > > On my sites I use a central database for storing the session objects, and
> > > > > all of the https servers access this central resource. Obviously if it
> > > > > goes down, everything is toast, but the same can be said of the database
> > > > > that stores all of the customer information, etc.
> > > > >
> > > > > -jwb
> > > >
> > > > Are you using Apache::ASP to generate sessions?
> > > >
> > > > Has anyone tried using Tie::DBI to store Apache::ASP sessions in a db?
> > > > That might solve problems with NFS sharing issues, though it might also
> > > > bog things down.
> > >
> > > No, I use Apache::Session - jwb
> >
> > Dan,
> >
> > I suggest you switch to Apache::Session. If you've got a site that gets
> > heavy traffic (which sounds like is the case if you're thinking about load
> > balancing), you definitely want a true DBMS handling your session data, not
> > just a Berkeley DB_File.
>
> I wouldn't buy that one on its own merits. I think that each site should
> evaluate their performance situation and see what backing store works for
> them. Sleepycat DB (nee Berkeley DB) 3.x, using balanced tree storage, is
> a damn fast storage mechanism. If you only have a single web server, dbm
> files are often the fastest blob storage mechanism. With that said,
> remote DBMS storage scales best with more than a single web server. Much
> better than NFS.
>
Good point, I didn't think of blob data. Storable is relatively slow
compared to dbm? How hard do you think it would be to take DBM code and
write it into simply a data serializer (like Storable's nfreeze)? That
would be the best of both worlds, eh?
I was under the impression that Sleepycat is a much better solution for
embedding into an application, where all data is kept in memory. I wouldn't
think .db files could come close to a caching DBMS like MySQL, unless the
.db file is on a caching filesystem.
Another plus for using MySQL to store sessions is that version 3.23 (alpha)
has entirely in-memory heap tables. This is a perfect fit for session data,
since sessions typically last a very short time, and one can assume the
database restart to session turnover ratio is very low.
-Adi
Re: speed up/load balancing of session-based sites
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
On Fri, 28 Apr 2000, Adi wrote:
> "Jeffrey W. Baker" wrote:
> >
> > On Fri, 28 Apr 2000, Dan McCormick wrote:
> >
> > > "Jeffrey W. Baker" wrote:
> > > >
> > > > On my sites I use a central database for storing the session objects, and
> > > > all of the https servers access this central resource. Obviously if it
> > > > goes down, everything is toast, but the same can be said of the database
> > > > that stores all of the customer information, etc.
> > > >
> > > > -jwb
> > >
> > > Are you using Apache::ASP to generate sessions?
> > >
> > > Has anyone tried using Tie::DBI to store Apache::ASP sessions in a db?
> > > That might solve problems with NFS sharing issues, though it might also
> > > bog things down.
> >
> > No, I use Apache::Session - jwb
>
> Dan,
>
> I suggest you switch to Apache::Session. If you've got a site that gets
> heavy traffic (which sounds like is the case if you're thinking about load
> balancing), you definitely want a true DBMS handling your session data, not
> just a Berkeley DB_File.
I wouldn't buy that one on its own merits. I think that each site should
evaluate their performance situation and see what backing store works for
them. Sleepycat DB (nee Berkeley DB) 3.x, using balanced tree storage, is
a damn fast storage mechanism. If you only have a single web server, dbm
files are often the fastest blob storage mechanism. With that said,
remote DBMS storage scales best with more than a single web server. Much
better than NFS.
> I used to use Apache::ASP for session management but switched to
> Apache::Session for this reason. I think Apache::ASP is a great solution
> for low-traffic sites, but Apache::Session is a must for high-volume and/or
> load-balanced sites.
>
> Apache::Session incorporates its own Tie::DBI implementation to manage
> sessions. (is this correct, Jeffrey?) I don't know how successful you'd be
> taking a hash already tied to a DB_File (via Apache::ASP) and then trying to
> tie it to a DBMS via Tie::DBI. At best, you'd have two copies of your
> session data, but most likely it wouldn't work.
Apache::Session is similar to Tie::DBI in that it knows how to take your
perl structures, put them in a backing store, and get them back out. It
is unlike Tie::DBI in that it also knows how to put your data in flat
files, berkeley DBs, and whatever else you need.
"Apache::Session is a persistence framework"
-jwb
Re: speed up/load balancing of session-based sites
Posted by Adi <ad...@certsite.com>.
"Jeffrey W. Baker" wrote:
>
> On Fri, 28 Apr 2000, Dan McCormick wrote:
>
> > "Jeffrey W. Baker" wrote:
> > >
> > > On my sites I use a central database for storing the session objects, and
> > > all of the https servers access this central resource. Obviously if it
> > > goes down, everything is toast, but the same can be said of the database
> > > that stores all of the customer information, etc.
> > >
> > > -jwb
> >
> > Are you using Apache::ASP to generate sessions?
> >
> > Has anyone tried using Tie::DBI to store Apache::ASP sessions in a db?
> > That might solve problems with NFS sharing issues, though it might also
> > bog things down.
>
> No, I use Apache::Session - jwb
Dan,
I suggest you switch to Apache::Session. If you've got a site that gets
heavy traffic (which sounds like is the case if you're thinking about load
balancing), you definitely want a true DBMS handling your session data, not
just a Berkeley DB_File.
I used to use Apache::ASP for session management but switched to
Apache::Session for this reason. I think Apache::ASP is a great solution
for low-traffic sites, but Apache::Session is a must for high-volume and/or
load-balanced sites.
Apache::Session incorporates its own Tie::DBI implementation to manage
sessions. (is this correct, Jeffrey?) I don't know how successful you'd be
taking a hash already tied to a DB_File (via Apache::ASP) and then trying to
tie it to a DBMS via Tie::DBI. At best, you'd have two copies of your
session data, but most likely it wouldn't work.
-Adi
Re: speed up/load balancing of session-based sites
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
On Fri, 28 Apr 2000, Dan McCormick wrote:
> "Jeffrey W. Baker" wrote:
> >
> > On my sites I use a central database for storing the session objects, and
> > all of the https servers access this central resource. Obviously if it
> > goes down, everything is toast, but the same can be said of the database
> > that stores all of the customer information, etc.
> >
> > -jwb
>
> Are you using Apache::ASP to generate sessions?
>
> Has anyone tried using Tie::DBI to store Apache::ASP sessions in a db?
> That might solve problems with NFS sharing issues, though it might also
> bog things down.
No, I use Apache::Session - jwb
Re: speed up/load balancing of session-based sites
Posted by Dan McCormick <da...@metro.net>.
"Jeffrey W. Baker" wrote:
>
> On my sites I use a central database for storing the session objects, and
> all of the https servers access this central resource. Obviously if it
> goes down, everything is toast, but the same can be said of the database
> that stores all of the customer information, etc.
>
> -jwb
Are you using Apache::ASP to generate sessions?
Has anyone tried using Tie::DBI to store Apache::ASP sessions in a db?
That might solve problems with NFS sharing issues, though it might also
bog things down.
Dan
Re: speed up/load balancing of session-based sites
Posted by Tobias Hoellrich <th...@Adobe.COM>.
At 05:43 PM 5/7/00 -0400, Greg Stark wrote:
>I've written some pretty heavy database driven sites that do some pretty
>complicated things and I've *never* found it really necessary to have a server
>side session database. In theory you might find it convenient to cache big
>complex data structures for the session, but in practice most people use it
>for storing things like usernames and shopping cart contents.
>
>My suggestion is to put the state information in the cookie directly. Include
>a crypto hash (with a secret) to sign the cookie and be done with it. If the
>information is sensitive then encrypt the whole thing.
>
>Then your sessions are completely stateless, they can migrate between mod_perl
>processes, even across servers. They can even survive server reboots. And They
>don't require additional infrastructure to store the database of sessions.
>
> ...
And with all the paranoia about cookies (not to forget attachments and
I_LOVE_YOUs) what do you do for all those people who have cookies disabled?
I've always tried to support the user as good as possible whether cookies
are enabled or not - and I don't see a way how you would associate a
user-session with state-information in your case?
Cheers
Tobias
Re: speed up/load balancing of session-based sites
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
On 7 May 2000, Greg Stark wrote:
>
> > > > 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?
> >
> > On my sites I use a central database for storing the session objects, and
> > all of the https servers access this central resource. Obviously if it
> > goes down, everything is toast, but the same can be said of the database
> > that stores all of the customer information, etc.
>
> I've written some pretty heavy database driven sites that do some pretty
> complicated things and I've *never* found it really necessary to have a server
> side session database. In theory you might find it convenient to cache big
> complex data structures for the session, but in practice most people use it
> for storing things like usernames and shopping cart contents.
>
> My suggestion is to put the state information in the cookie directly. Include
> a crypto hash (with a secret) to sign the cookie and be done with it. If the
> information is sensitive then encrypt the whole thing.
>
> Then your sessions are completely stateless, they can migrate between mod_perl
> processes, even across servers. They can even survive server reboots. And They
> don't require additional infrastructure to store the database of sessions.
>
> I keep meaning to write this up as an Apache:: module, but it's pretty trivial
> to cons up an application-specific version. The only thing this doesn't
> provide is a way to deal with large data structures. But generally if the
> application is big enough to need such data structures you have a real
> database from which you can reconstruct the data on each request, just store
> the state information in the cookie.
Your post does a significant amount of hand waving regarding people's
requirements for their websites. I try to keep an open mind when giving
advice and realize that people all have different needs. That's why I
prefixed my advice with "On my sites..."
On my sites, I use the session as a general purpose data sink. I find
that I can significantly improve user experience by keeping things in the
session related to the user-site interaction. These session object
contain way more information than could be stuffed into a cookie, even if
I assumed that all of my users had cookies turned on. Note also that
sending a large cookie can significantly increase the size of the
request. That's bad for modem users.
Your site may be different. In fact, it had better be! :)
-jwb
Re: speed up/load balancing of session-based sites
Posted by Greg Stark <gs...@mit.edu>.
> > > 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?
>
> On my sites I use a central database for storing the session objects, and
> all of the https servers access this central resource. Obviously if it
> goes down, everything is toast, but the same can be said of the database
> that stores all of the customer information, etc.
I've written some pretty heavy database driven sites that do some pretty
complicated things and I've *never* found it really necessary to have a server
side session database. In theory you might find it convenient to cache big
complex data structures for the session, but in practice most people use it
for storing things like usernames and shopping cart contents.
My suggestion is to put the state information in the cookie directly. Include
a crypto hash (with a secret) to sign the cookie and be done with it. If the
information is sensitive then encrypt the whole thing.
Then your sessions are completely stateless, they can migrate between mod_perl
processes, even across servers. They can even survive server reboots. And They
don't require additional infrastructure to store the database of sessions.
I keep meaning to write this up as an Apache:: module, but it's pretty trivial
to cons up an application-specific version. The only thing this doesn't
provide is a way to deal with large data structures. But generally if the
application is big enough to need such data structures you have a real
database from which you can reconstruct the data on each request, just store
the state information in the cookie.
--
greg
Re: speed up/load balancing of session-based sites
Posted by Joshua Chamas <jo...@chamas.com>.
Adi wrote:
>
> > How many writes and session ties per second does this system
> > handle, and what kind of db are you using. Currently the NetApp
> > NFS file sharing approach seems to max out around 40 Apache::ASP
> > style session creations per second. This involves writing to a
> > central internal session for session tracking, and the creation of
> > the relevant db files.
> >
> > I ask because I'm looking at going with your approach to handle greater
> > loads, and wondering where you max out at with MySQL/Oracle (?), & what
> > kind of hardware you are running.
> >
> > -- Joshua
>
> I don't have any exact figures, but it is very high. I run MySQL on a
> single processor Linux box with a 500Mhz K6-2 with 128M RAM. Even if it's
> <40/sec on that hardware, it is a scalable solution. All decent DBMSes are
> multi-threaded and scale with number of CPUs. Is the NetApp NFS approach as
> scalable ? I don't know enough about it to compare...
>
> Sorry for not providing exact benchmark numbers..
>
No, because of limits of network i/o, and lack of reliable
NFS file locking, this solution does not scale. If there
were reliable network locking, the solution would likely
scale to the speed of the network and the disk i/o of the
NFS cluster. Solaris supposedly has good NFS locking, and
this might then be a solution if we patched Apache::ASP again
with the NFS fnctl locking, not flock().
--Joshua
Re: speed up/load balancing of session-based sites
Posted by Adi <ad...@certsite.com>.
"Jeffrey W. Baker" wrote:
>
> On Fri, 28 Apr 2000, Adi wrote:
>
> > Joshua Chamas wrote:
> > > How many writes and session ties per second does this system
> > > handle, and what kind of db are you using. Currently the NetApp
> > > NFS file sharing approach seems to max out around 40 Apache::ASP
> > > style session creations per second. This involves writing to a
> > > central internal session for session tracking, and the creation of
> > > the relevant db files.
> > >
> > > I ask because I'm looking at going with your approach to handle greater
> > > loads, and wondering where you max out at with MySQL/Oracle (?), & what
> > > kind of hardware you are running.
> > >
> > > -- Joshua
> >
> > I don't have any exact figures, but it is very high. I run MySQL on a
> > single processor Linux box with a 500Mhz K6-2 with 128M RAM. Even if it's
> > <40/sec on that hardware, it is a scalable solution. All decent DBMSes are
> > multi-threaded and scale with number of CPUs. Is the NetApp NFS approach as
> > scalable ? I don't know enough about it to compare...
> >
> > Sorry for not providing exact benchmark numbers..
>
> It ought to be a lot higher than 40/sec on that hardware. On low class
> hardware a year ago, I was getting number an order of magnitude higher
> than that with the database on the local machine. See here:
>
~300 req/sec, good to hear! I am sort of in the dark, as we haven't had
time to benchmark anything yet.
Thanks -Adi
Re: speed up/load balancing of session-based sites
Posted by Joshua Chamas <jo...@chamas.com>.
"Jeffrey W. Baker" wrote:
>
> > Sorry for not providing exact benchmark numbers..
>
> It ought to be a lot higher than 40/sec on that hardware. On low class
> hardware a year ago, I was getting number an order of magnitude higher
> than that with the database on the local machine. See here:
>
> http://forum.swarthmore.edu/epigone/modperl/feespaysmox
>
Thanks Jeff, that's just what I was looking for:
Performance on a Celeron 333/128MB/Linux/mySQL box:
Create new empty session: 385 requests/second
Create new session and write to it: 233 requests/second
Retrieve old session: 400 requests/second
Retrieve old session and read from it: 400 requests/second
Retrieve old session, read it, write to it: 256 requests/second
Has anyone done similar benchmarks with Apache::Session
hooked into Oracle?
Thanks,
Joshua
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
Re: speed up/load balancing of session-based sites
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
On Fri, 28 Apr 2000, Adi wrote:
> Joshua Chamas wrote:
> > How many writes and session ties per second does this system
> > handle, and what kind of db are you using. Currently the NetApp
> > NFS file sharing approach seems to max out around 40 Apache::ASP
> > style session creations per second. This involves writing to a
> > central internal session for session tracking, and the creation of
> > the relevant db files.
> >
> > I ask because I'm looking at going with your approach to handle greater
> > loads, and wondering where you max out at with MySQL/Oracle (?), & what
> > kind of hardware you are running.
> >
> > -- Joshua
>
> I don't have any exact figures, but it is very high. I run MySQL on a
> single processor Linux box with a 500Mhz K6-2 with 128M RAM. Even if it's
> <40/sec on that hardware, it is a scalable solution. All decent DBMSes are
> multi-threaded and scale with number of CPUs. Is the NetApp NFS approach as
> scalable ? I don't know enough about it to compare...
>
> Sorry for not providing exact benchmark numbers..
It ought to be a lot higher than 40/sec on that hardware. On low class
hardware a year ago, I was getting number an order of magnitude higher
than that with the database on the local machine. See here:
http://forum.swarthmore.edu/epigone/modperl/feespaysmox
-jwb
PS: I love epigone because it produces wonderfully pronouncable mangled
URLs.
Re: speed up/load balancing of session-based sites
Posted by Adi <ad...@certsite.com>.
Joshua Chamas wrote:
>
> "Jeffrey W. Baker" wrote:
> >
> > >
> > > 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.
> >
> > On my sites I use a central database for storing the session objects, and
> > all of the https servers access this central resource. Obviously if it
> > goes down, everything is toast, but the same can be said of the database
> > that stores all of the customer information, etc.
> >
>
> How many writes and session ties per second does this system
> handle, and what kind of db are you using. Currently the NetApp
> NFS file sharing approach seems to max out around 40 Apache::ASP
> style session creations per second. This involves writing to a
> central internal session for session tracking, and the creation of
> the relevant db files.
>
> I ask because I'm looking at going with your approach to handle greater
> loads, and wondering where you max out at with MySQL/Oracle (?), & what
> kind of hardware you are running.
>
> -- Joshua
I don't have any exact figures, but it is very high. I run MySQL on a
single processor Linux box with a 500Mhz K6-2 with 128M RAM. Even if it's
<40/sec on that hardware, it is a scalable solution. All decent DBMSes are
multi-threaded and scale with number of CPUs. Is the NetApp NFS approach as
scalable ? I don't know enough about it to compare...
Sorry for not providing exact benchmark numbers..
-Adi
Re: speed up/load balancing of session-based sites
Posted by Joshua Chamas <jo...@chamas.com>.
"Jeffrey W. Baker" wrote:
>
> >
> > 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.
>
> On my sites I use a central database for storing the session objects, and
> all of the https servers access this central resource. Obviously if it
> goes down, everything is toast, but the same can be said of the database
> that stores all of the customer information, etc.
>
How many writes and session ties per second does this system
handle, and what kind of db are you using. Currently the NetApp
NFS file sharing approach seems to max out around 40 Apache::ASP
style session creations per second. This involves writing to a
central internal session for session tracking, and the creation of
the relevant db files.
I ask because I'm looking at going with your approach to handle greater
loads, and wondering where you max out at with MySQL/Oracle (?), & what
kind of hardware you are running.
-- Joshua
Re: speed up/load balancing of session-based sites
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
On Fri, 28 Apr 2000, Joshua Chamas wrote:
> 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.
On my sites I use a central database for storing the session objects, and
all of the https servers access this central resource. Obviously if it
goes down, everything is toast, but the same can be said of the database
that stores all of the customer information, etc.
-jwb
Re: speed up/load balancing of session-based sites
Posted by Joshua Chamas <jo...@chamas.com>.
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
Re: speed up/load balancing of session-based sites
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 27 Apr 2000, Dan McCormick wrote:
> 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?
Anything that actually uses the session data to do something specific to
this user will have to go through to the backend mod_perl server. Generic
pages without user customization could be served from the proxy cache
though.
> 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?
Most of the commercial load-balancing tools support the concept of
"sticky" load-balancing, which routes people back to the same box each
time. If you can't do that, you have to share the sessions across all app
servers, probably by putting them into a database.
> Can round-robin DNS be counted on to send people back to the same
> server over the life of a given session?
It should work, but round-robin DNS has its own shortcomings (no failover
support) that usually send people to NAT-based approaches for high-traffic
commercial sites.
- Perrin