|
Peter Mueller wrote:
>
> Modify the below lines in httpd.conf and restart httpd. I believe there's a
> 'persistence=seconds' flag in LVS that you can set that should correspond to
> what you put in httpd.conf?
I played with all of this when I first was trying to figure out what was going
on.
I expected that if the connection was persistent, then all hits would be
downloaded
in the same connection and there would be only one ActConn in the ipvsadm table.
There wasn't. I think I got a pile of InActConns spread between the
real-servers.
I've just upgraded to apache_1.3.19 as my old apache didn't survive the upgrade
to glibc-2.2.2.
I now see several ActConn spread around the real-servers. If these are
(netscape)
persistent connections, then I would expect them to be reused if I did a reload,
but the number of Act Conn increases by the same number each reload
(ipvs-1.0.7-2.2.19).
while netstat -an | grep 80 on the real-servers shows the connections going from
FIN_WAIT to LISTEN. The client shows 4 connections in CLOSE_WAIT while the
director
has 12 ActConns.
(Julian is this right?)
If a client with persistent http connects through an LVS to real-servers with
httpds
which can maintain a persistent httpd connection and the client asks for a web
page
full of gifs, then I expect the html page will be first downloaded (opening a
persistent
connection to the real-server). The client will then issue several commands of
the type
"GET /foo.gif"
If these requests go over the established connection, then the ActConn counter
on ipvsadm
won't change (will stay at 1).
However this doesn't happen. The counters go up as seen by ipvsadm. Each gif
must
be requested through a new connection.
so I still don't understand what's going on
Any ideas anyone?
Joe
> <from httpd.conf>
> #
> # KeepAlive: Whether or not to allow persistent connections (more than
> # one request per connection). Set to "Off" to deactivate.
> #
> KeepAlive On
> #
> # MaxKeepAliveRequests: The maximum number of requests to allow
> # during a persistent connection. Set to 0 to allow an unlimited amount.
> # We recommend you leave this number high, for maximum performance.
> #
> MaxKeepAliveRequests 100
>
> #
> # KeepAliveTimeout: Number of seconds to wait for the next request from the
> # same client on the same connection.
> #
> KeepAliveTimeout 15
>
> > -----Original Message-----
> > From: Joseph Mack [mailto:mack@xxxxxxxxxxx]
> > Sent: Monday, April 30, 2001 4:38 PM
> > To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> > Subject: Re: success: LV-NAT working
> >
> >
> > On Tue, 1 May 2001, Alois Treindl wrote:
> >
> > > I am running an astrology site; a typical request is to a CGI which
> > > creates an astrological drawing, based on some form data;
> > this drawing
> > > is stored as a temporary GIF file on the server.
> > > A html page is output by the CGI which contains a reference
> > to this GIF.
> >
> > I see. Funny this hasn't come up before.
> >
> > I was testing something like this the other day and decided
> > that the way I
> > was doing it, the info was coming from the client (passing
> > the URL to the
> > httpd) rather than the URL coming from the server page. It
> > seemed to be
> > the best explanation for what I was seeing. I was just
> > retrieving a page
> > that was already there, rather than asking for a gif to be
> > generated first
> > then retrieved.
> >
> > All this is speculation and can be revised in the face of
> > more evidence.
> > Do you find that you can't retrieve the gif sometimes? What
> > if you refresh
> > n times where n is the number of real-servers, do you eventually get
> > the gif?
> >
> > > So either we make sure that the new client request for the GIF hits
> > > the same realserver which ran the CGI (i.e. have
> > persistence) or we must
> > > create the GIF on a shared directory, so that each
> > realserver sees it.
> >
> > Very interesting
> >
> > Joe
> >
> > --
> > Joseph Mack mack@xxxxxxxxxxx
> >
> >
> > _______________________________________________
> > LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> > Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> > or go to http://www.in-addr.de/mailman/listinfo/lvs-users
> >
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
