Two things.
1) For the resource collection/broadcast process, can't you give it
a higher priority and make this artifact go away?
2) This brings up a great point of discussion that I've long
wondered about. Proxying vs. backhanding everything. Let's say that the
pages that you're generating are over 8KB in size (the kernel's network
socket buffer size) and that my Apache processes are about 35MB in size.
That being the case, I would think that you would want to:
* use backhand on everything
* make everything an app server
* increase the network buffer size to something insane like 100KB
and hope that your pages/images are smaller than 100KB
* bank on the fact that after the Apache process writes to the
socket (which should be able to buffer the entire page), that the apache
process will be able to disconnect from the socket and go about serving more
incoming requests
Or, is the recommended solution to:
* use a row of proxy servers
* have the proxy servers backhand the requests to a row of app
servers
* the proxy servers act as a buffer between the requesting client
(home user w/ slow modem) and the server (what's the read buffer on
mod_backhand anyway? small or large? I think I remember seeing it in the
code as 8K, but that was about a month ago that I was looking at it, so
correct me if I'm wrong)
* a row of app servers that serve/create the content
Right now I'm doing the second option, but am toying with the idea
presented in the first. Does anyone have any experience with the first or
know of any side effects of increasing the buffer size to something close to
100KB?
-sc
-----Original Message-----
From: Theo E. Schlossnagle [mailto:theos@cnds.jhu.edu]
Sent: Friday, August 04, 2000 11:26 PM
To: Sean Chittenden
Cc: backhand-users@lists.backhand.org
Subject: Re: FW: [mod_backhand-users] Another New Candidacy Function:
byChooseMeOverLocal
Sean Chittenden wrote:
> True true. I always group byCost and addPrediction together.
That
> said, I've included the config that we use (works very well right now!),
and
> am curious to know if there is some mix/match ideal that you
> personally/academically/professionally prefer?
>
> <Location />
> Backhand byAge 2
> BackhandFromSO libexec/byHostname.so byHostname (app)
> Backhand byRandom
> Backhand byLogWindow
> Backhand byCost
> Backhand addPrediction
> </Location>
That looks pretty good to me. You might want to set Age up to something
high.. Maybe 10... on busy systems, the resource information collectiona
nd broadcasting process has a tendency to not get scheduled for a long
time. You can get a strange artifact in that you will wind up with a
COMPLETELY blank candidacy list in the end and the apache instance will
just pass the request right through (this could be bad).
> Does anyone know of a way to improve this? Here's the quickie
> drawing:
>
> | High availability
> V
> |Proxy w/ mod_backhand (w/ backhand config above)
> V
> |App w/ mod_backhand (but no proxying/relaying of requests in config)
If your App servers are TOO heavy weight, you might try making the Proxy
servers App servers and putting them all in the front line with
mod_backhand to balnce amongst themselves. If your App servers (each
apache child) have database connections and you can only afford (money
or resources) to have a specific quantity, then your existing set up is
the right way to go.
--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
1) For the resource collection/broadcast process, can't you give it
a higher priority and make this artifact go away?
2) This brings up a great point of discussion that I've long
wondered about. Proxying vs. backhanding everything. Let's say that the
pages that you're generating are over 8KB in size (the kernel's network
socket buffer size) and that my Apache processes are about 35MB in size.
That being the case, I would think that you would want to:
* use backhand on everything
* make everything an app server
* increase the network buffer size to something insane like 100KB
and hope that your pages/images are smaller than 100KB
* bank on the fact that after the Apache process writes to the
socket (which should be able to buffer the entire page), that the apache
process will be able to disconnect from the socket and go about serving more
incoming requests
Or, is the recommended solution to:
* use a row of proxy servers
* have the proxy servers backhand the requests to a row of app
servers
* the proxy servers act as a buffer between the requesting client
(home user w/ slow modem) and the server (what's the read buffer on
mod_backhand anyway? small or large? I think I remember seeing it in the
code as 8K, but that was about a month ago that I was looking at it, so
correct me if I'm wrong)
* a row of app servers that serve/create the content
Right now I'm doing the second option, but am toying with the idea
presented in the first. Does anyone have any experience with the first or
know of any side effects of increasing the buffer size to something close to
100KB?
-sc
-----Original Message-----
From: Theo E. Schlossnagle [mailto:theos@cnds.jhu.edu]
Sent: Friday, August 04, 2000 11:26 PM
To: Sean Chittenden
Cc: backhand-users@lists.backhand.org
Subject: Re: FW: [mod_backhand-users] Another New Candidacy Function:
byChooseMeOverLocal
Sean Chittenden wrote:
> True true. I always group byCost and addPrediction together.
That
> said, I've included the config that we use (works very well right now!),
and
> am curious to know if there is some mix/match ideal that you
> personally/academically/professionally prefer?
>
> <Location />
> Backhand byAge 2
> BackhandFromSO libexec/byHostname.so byHostname (app)
> Backhand byRandom
> Backhand byLogWindow
> Backhand byCost
> Backhand addPrediction
> </Location>
That looks pretty good to me. You might want to set Age up to something
high.. Maybe 10... on busy systems, the resource information collectiona
nd broadcasting process has a tendency to not get scheduled for a long
time. You can get a strange artifact in that you will wind up with a
COMPLETELY blank candidacy list in the end and the apache instance will
just pass the request right through (this could be bad).
> Does anyone know of a way to improve this? Here's the quickie
> drawing:
>
> | High availability
> V
> |Proxy w/ mod_backhand (w/ backhand config above)
> V
> |App w/ mod_backhand (but no proxying/relaying of requests in config)
If your App servers are TOO heavy weight, you might try making the Proxy
servers App servers and putting them all in the front line with
mod_backhand to balnce amongst themselves. If your App servers (each
apache child) have database connections and you can only afford (money
or resources) to have a specific quantity, then your existing set up is
the right way to go.
--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7