From: "Perrin Harkins" <[EMAIL PROTECTED]>
To: "Greg Cope" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: 13 May 2000 01:57
Subject: Re: speed up/load balancing of session-based sites - POT
: On Sat, 13 May 2000, Greg Cope wrote:
: > : Likewise with
On Sat, 13 May 2000, Greg Cope wrote:
> : Likewise with sessions. Even if you load balance across multiple machines
> : you don't need to access a session database on every request. Most load
> : balancing systems have something so they'll send the seme "session"
> : (typically ip address) to the
POT = Possibly Off topic
: Likewise with sessions. Even if you load balance across multiple machines
: you don't need to access a session database on every request. Most load
: balancing systems have something so they'll send the seme "session"
: (typically ip address) to the same backend server
On Thu, 11 May 2000, Leslie Mikesell wrote:
[...]
> else that could be done on that hardware. However I recently inherited
> another system that is falling on its face at a much lighter load. It
> appears to be using tmp files to sort some ORDER BY clauses that
> I haven't had time to fix yet.
On Thu, 11 May 2000, Leslie Mikesell wrote:
> According to Mark Imbriaco:
> > > > "Perrin" == Perrin Harkins <[EMAIL PROTECTED]> writes:
> > > Perrin> I think every RDBMS I've seen, includig MySQL, guarantees
> > > Perrin> atomicity at this level.
> > >
> > > Look, Mummy, the funny m
According to Mark Imbriaco:
> > > "Perrin" == Perrin Harkins <[EMAIL PROTECTED]> writes:
> > Perrin> I think every RDBMS I've seen, includig MySQL, guarantees
> > Perrin> atomicity at this level.
> >
> > Look, Mummy, the funny man said MySQL and RDBMS in the same sentence :)
>
> Plea
On 10 May 2000, Stephen Zander wrote:
> > "Perrin" == Perrin Harkins <[EMAIL PROTECTED]> writes:
> Perrin> I think every RDBMS I've seen, includig MySQL, guarantees
> Perrin> atomicity at this level.
>
> Look, Mummy, the funny man said MySQL and RDBMS in the same sentence :)
Please
> "Perrin" == Perrin Harkins <[EMAIL PROTECTED]> writes:
Perrin> I think every RDBMS I've seen, includig MySQL, guarantees
Perrin> atomicity at this level.
Look, Mummy, the funny man said MySQL and RDBMS in the same sentence :)
--
Stephen
"There are those who call me... Tim"
Hi,
Pardon my ignorance, what is storable.
Murali
-Original Message-
From: Rodney Broom <[EMAIL PROTECTED]>
To: Perrin Harkins <[EMAIL PROTECTED]>; Jeremy Howard
<[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: 10 May 2000 13:13
Subject: Re: sp
According to G.W. Haywood:
> Hi there,
>
> On Tue, 9 May 2000, Leslie Mikesell wrote:
>
> > I'm more concerned about dealing with large numbers of simultaneous
> > clients (say 20,000 who all hit at 10 AM) and I've run into problems
> > with both dbm and mysql where at a certain point of write a
> > Murali said:
> > > a) NFS mount a server which will store all session data
Just a note, NFS in specific can be very problematic. It takes some real
tuning to get it just right. As for distributed data; session data ~should~
be small, under a kB. So you could move it around in almost any fassi
On Tue, 9 May 2000, Jeremy Howard wrote:
> Murali said:
> > 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 thi
Murali said:
> 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 r
On Tue, 9 May 2000, Leslie Mikesell wrote:
> > We use a custom written session handler that uses Storable for
> > serialization. We're storing complete results for complex select
> > statements on pages that require "paging" so that the complex select only
> > happens once. We store user objects
On Tue, 9 May 2000, Jeffrey W. Baker wrote:
> If you are using an RDBMS which has atomic operations, you can turn off
> locking in Apache::Session with no effect.
I think every RDBMS I've seen, includig MySQL, guarantees atomicity at
this level.
> On the subject of locking, I think that the daem
Hi there,
On Tue, 9 May 2000, Leslie Mikesell wrote:
> I'm more concerned about dealing with large numbers of simultaneous
> clients (say 20,000 who all hit at 10 AM) and I've run into problems
> with both dbm and mysql where at a certain point of write activity
> you basically can't keep up. T
> I'm more concerned about dealing with large numbers of simultaneous
> clients (say 20,000 who all hit at 10 AM) and I've run into problems
> with both dbm and mysql where at a certain point of write activity
> you basically can't keep up. These problems may be solvable but
> timings just below
According to Tom Mornini:
> > 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?
>
> I can't imagine why anyone wou
On Tue, 9 May 2000, Gunther Birznieks wrote:
> As far as I knew Apache::Session has never even had anything to do with
> cookies. It is a persistent storage mechanism where the session "handle" is
> a uniquely generated ID.
>
> What you are interested in is a Session "manager" which understands
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
> -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
>
>
>
Autarch wrote:
>
> On Mon, 8 May 2000, Perrin Harkins wrote:
>
> > Some apps that use Apache::Session, like Embperl and Mason, have chosen
> > to rely on cookies. They implement the cookie part themselves.
> > Apache::Session has nothing to do with cookies.
>
> I don't know about Embperl but M
On Mon, 8 May 2000, Perrin Harkins wrote:
> Some apps that use Apache::Session, like Embperl and Mason, have chosen
> to rely on cookies. They implement the cookie part themselves.
> Apache::Session has nothing to do with cookies.
I don't know about Embperl but Mason a) doesn't do anything wit
indrek siitan wrote:
> > As far as I knew Apache::Session has never even had anything to
> > do with cookies. It is a persistent storage mechanism where the
> > session "handle" is uniquely generated ID.
>
> and where do you think the session ID is kept?
>
> yup. right. in a cookie.
Well, no, a
Hi,
> As far as I knew Apache::Session has never even had anything to
> do with cookies. It is a persistent storage mechanism where the
> session "handle" is uniquely generated ID.
and where do you think the session ID is kept?
yup. right. in a cookie.
Rgds,
Tfr
--==< [EMAIL PROTECTED]
At 10:13 PM 5/8/00 +0100, Greg Cope wrote:
>: 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
>d
On Mon, 8 May 2000, Leslie Mikesell wrote:
> > 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 informat
: 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
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 structur
On Mon, 8 May 2000, Adi wrote:
> 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 d
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
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
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
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
> > > 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 sa
ore you "use" any other DBI,DBD::* modules in
the startup.pl or the httpd.conf file.
sang
-Original Message-
From: Igor Chudov @ home [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 28, 2000 5:11 PM
To: Jeffrey W. Baker
Cc: [EMAIL PROTECTED]
Subject: Re: speed up/load balancing
"Igor Chudov @ home" wrote:
>
> Joshua Chamas wrote:
> > 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 rea
On Fri, 28 Apr 2000, Igor Chudov @ home wrote:
> My persistent oracle connections are cached properly with mod_perl and
> are no problem.
Are you loading Apache::DBI before you use Apache::Session? Also make
sure that whatever params you give in your connects (or
connect_on_init) match those yo
"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:
>
"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::AS
"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
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 i
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.
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 lo
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 resour
"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
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
"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
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
"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 informatio
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?
> >
> > I
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,
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 possi
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 th
54 matches
Mail list logo
