Re: speed up/load balancing of session-based sites

[Differentiated Software Solutions Pvt. Ltd.]

Hi,

Reading thorough this interesting posting, I want to focus back on tying
session data across a network.

We are facing a similar problem on our service, which is currently based on
a single server. We're enabled the app. so that it is mirrored on a periodic
basis across a range of servers. Any server can service the first call, but
we would like to ensure that the subsequent calls are serviced by the same
server who answered the first http call. If not, then I have store what the
user had done in the previous calls and this should be accessible to all the
servers.

As I understand from this discussion we have 2 methods involving creating a
session-server which will store all session data.
a) NFS mount a server which will store all session data
b) Have a DB in this server which stores this data. Through a network
connect to the DB and retrieve the info.

My questions
a) Is NFS mount unreliable... esp if the number of hits in each server will
go upto 20 per second. Does this place a limit on the number of servers
which can be connected to the session server.
b) There's lots of chat about Oracle connection slow. Is this a general user
experience. We've got our app. written using Postgres. We had problems
(quite severe) in the initial days. We've somewhat stabilized by getting to
know all quirks of postgres. For a very high-hit site is it wise to switch
to Oracle.
We've solved lots of performance problems, but still find Pg reliability a
bit questionable.
c) How are Oracle connections across network.
Other than having a common session server (which will also hit limits if too
many site-servers) are there any other ways to have a really scaleable
solution to this problem.
Isn't cookies much more scaleable that the session server.

Thanks,

Murali

-----Original Message-----
From: Leon Brocard <[EMAIL PROTECTED]>
To: 'Jeffrey W. Baker' <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: 09 May 2000 16:54
Subject: RE: speed up/load balancing of session-based sites


>> -----Original Message-----
>> From: Jeffrey W. Baker [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, May 08, 2000 9:19 PM
>> To: Leslie Mikesell
>> Cc: Jeffrey W. Baker; Greg Stark; [EMAIL PROTECTED]
>> Subject: Re: speed up/load balancing of session-based sites
>>
>>
>> On Mon, 8 May 2000, Leslie Mikesell wrote:
>>
>> > According to Jeffrey W. Baker:
>> >
>> > > > 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..."
>> >
>> > Can anyone quantify this a bit?
>> >
>> > > 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! :)
>> >
>> > Have you timed your session object retrieval and the cleanup code
>> > that becomes necessary with server-session data compared to
>> > letting the client send back (via cookies or URL) everything you
>> > need to reconstruct the necessary state without keeping temporary
>> > session variables on the server?  There must be some size where
>> > the data values are as easy to pass as the session key, and some
>> > size where it becomes slower and more cumbersome.  Has anyone
>> > pinned down the size where a server-side lookup starts to win?
>jwb wrote:
>
>> I have really extensive benchmarks for every part of
>> Apache::Session.  These will be released with version 1.5,
>> which also includes more than fifty new unit tests.
>
>Cool. Strict benchmarking and testing is severely lacking in general
>in Perl modules.
>
>Apache::Session rocks, however the name doesn't describe the functionality
>of the module (it has nothing to do with Apache). Are there any plans
>to change it to "Persistent::Session" or some other name? I'm sure
>people are overlooking it because of this.
>
>Leon
>--
>Leon Brocard   |   perl "programmer"   |   [EMAIL PROTECTED]
>