Mailing List Archive: [mod_backhand-users] Lots of questions

[mod_backhand-users] Lots of questions

Aug 28, 2001, 3:51 PM

Post #1 of 9 (2040 views)

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C12FF2.81588DE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello folks,

I have a ton of questions. Probably best to just get started.

1) Does mod_backhand do a true "http 1.1" connection from the apache mod =
backhand server to the remote server?

2) Is there a way to have mod backhand backhand a request to a server =
which is NOT running mod backhand? It looks as if the backhand servers =
are "discovered" when they broadcast the performance data. If the =
performance data is never broadcast from a server (because mod backhand =
is not installed) can mod backhand still backhand the request to that =
server. Also, please note I mean backhand (proxy) not http redirect to =
the other server!

3) The reason for both the above questions is I would like mod_backhand =
to backhand to some NT IIS web servers. Obviously they cannot run =
mod_backhand as it only runs on unix.

4) Is there any plans to update mod_backhand to work with the new apache =
2.0 module api?

5) It looks as if mod_backhand supports SSL connections to the backhand =
server, and then backhands using standard http (without ssl). Is this =
correct? If this is the case, is any sort of SSL header information =
forwarded to the secondary servers? I.E. if a connection comes in via =
https to server 1 which backhands via http to server 2 is there anyway =
for a script or cgi program on server2 to check that the connection (to =
server 1) used ssl? Ideally It would be nice if this were done in such =
a way that all current cgi scripts which check for SSL information would =
still work properly without modification. Effectively faking server 2 =
cgi scripts into thinking that ssl was performed directly to them. In =
this way people developing scripts would not need to have any special =
knowledge of the setup of the server systems and would be able to hand =
ssl as normal.

6) if #5 is done in apache only setups, what are the forwarded ssl =
headers and sample values so I could write an ISAPI filter on NT IIS to =
make use of the SSL header infor on NT scripts.

7) is there a real advantage to spliting up "heavy weight" apache =
processes from "light weight" ones and forwarding to light weight =
processes from heavyweight ones? Isn't a new apache process needed for =
each client connection to the mod backhand machine, and then one for =
each backhanded request. (of course with some benefit to the http 1.1 =
upgrade) I.E. I am going to use two apache processes to do the work =
that could be just as easily accomplished with one?

8) Basically what I am hoping to do here is have a heavy weight apache =
process running mod backhand forward all requests for *.asp pages to an =
NT server. Any request that is not for an *.asp page should be serviced =
by the same server running the heavy weight apache process. Is this =
possible? How would I accomplish it? Is there any benefit to having a =
separate "heavy weight" apache process which would handle mod backhand, =
ssl, user/pass authentication, mod re-write, logging, etc, and then =
light weight processes which would serve .htm pages and handle normal =
linux php, cgi, perl processes?

Thanks for all your help everyone.

rob

------=_NextPart_000_0007_01C12FF2.81588DE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3315.2870" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello folks,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>    I have a ton of =
questions. =20
Probably best to just get started.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>1) Does mod_backhand do a true "http =
1.1"=20
connection from the apache mod backhand server to the remote=20
server?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>2) Is there a way to have mod backhand =
backhand a=20
request to a server which is NOT running mod backhand?  It looks as =
if the=20
backhand servers are "discovered" when they broadcast the performance=20
data.  If the performance data is never broadcast from a server =
(because=20
mod backhand is not installed) can mod backhand still backhand the =
request to=20
that server.  Also, please note I mean backhand (proxy) not http =
redirect=20
to the other server!</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>3) The reason for both the above =
questions is I=20
would like mod_backhand to backhand to some NT IIS web servers.  =
Obviously=20
they cannot run mod_backhand as it only runs on unix.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>4) Is there any plans to update =
mod_backhand to=20
work with the new apache 2.0 module api?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>5) It looks as if mod_backhand supports =
SSL=20
connections to the backhand server, and then backhands using standard =
http=20
(without ssl).  Is this correct?  If this is the case, is any =
sort of=20
SSL header information forwarded to the secondary servers?  I.E. if =
a=20
connection comes in via https to server 1 which backhands via http to =
server 2=20
is there anyway for a script or cgi program on server2 to check that the =

connection (to server 1) used ssl?  Ideally It would be nice if =
this were=20
done in such a way that all current cgi scripts which check for SSL =
information=20
would still work properly without modification.  Effectively faking =
server=20
2 cgi scripts into thinking that ssl was performed directly to =
them.  In=20
this way people developing scripts would not need to have any special =
knowledge=20
of the setup of the server systems and would be able to hand ssl as=20
normal.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>6) if #5 is done in apache only setups, =
what are=20
the forwarded ssl headers and sample values so I could write an ISAPI =
filter on=20
NT IIS to make use of the SSL header infor on NT scripts.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>7) is there a real advantage to =
spliting up "heavy=20
weight" apache processes from "light weight" ones and forwarding to =
light weight=20
processes from heavyweight ones?  Isn't a new apache process needed =
for=20
each client connection to the mod backhand machine, and then one for =
each=20
backhanded request.  (of course with some benefit to the http 1.1=20
upgrade)  I.E. I am going to use two apache processes to do the =
work that=20
could be just as easily accomplished with one?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>8)  Basically what I am hoping to =
do here is=20
have a heavy weight apache process running mod backhand forward all =
requests for=20
*.asp pages to an NT server.  Any request that is not for an *.asp =
page=20
should be serviced by the same server running the heavy weight apache=20
process.  Is this possible?  How would I accomplish it?  =
Is there=20
any benefit to having a separate "heavy weight" apache process which =
would=20
handle mod backhand, ssl, user/pass authentication, mod re-write, =
logging, etc,=20
and then light weight processes which would serve .htm pages and handle =
normal=20
linux php, cgi, perl processes?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks for all your help =
everyone.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>rob</FONT></DIV></BODY></HTML>

------=_NextPart_000_0007_01C12FF2.81588DE0--

[mod_backhand-users] Lots of questions [ In reply to ]

jesus at omniti

Aug 28, 2001, 9:19 PM

Post #2 of 9 (2009 views)

Permalink

Rob Butler wrote:
> 1) Does mod_backhand do a true "http 1.1" connection from the apache mod
> backhand server to the remote server?

It can. IT will upgrade the connection to keep-alive if necessary. If the
request coming in is HTTP/1.0, it will leave it as such. If the incoming
request is HTTP/1.1, then it uses HTTP/1.1 on the back end. I think the only
thing it doesn't currently support is POST requests using Chunked-Encoding for
the post data. There is a patch from Kevin that incorporates this, I just
have not had time to integrate it and the demand has not been there.

> 2) Is there a way to have mod backhand backhand a request to a server
> which is NOT running mod backhand? It looks as if the backhand servers
> are "discovered" when they broadcast the performance data. If the
> performance data is never broadcast from a server (because mod backhand
> is not installed) can mod backhand still backhand the request to that
> server. Also, please note I mean backhand (proxy) not http redirect to
> the other server!

Someone wrote a stand alone broadcaster at one point. I don't know where it
is. It would be fairly trivial to pull the code out of back_util.c and
platform.c to make a standalone deamon that has does the deed (minus Apache
related stats).

So, no. But if I was sufficiently annoyed, I would write one.

> 3) The reason for both the above questions is I would like mod_backhand
> to backhand to some NT IIS web servers. Obviously they cannot run
> mod_backhand as it only runs on unix.

Hmm.. I wouldn't be tempted to write one for Windows. But someone else can
:-) Ideally someone would write it to run on Windows so it acutally give the
load of the machine, etc. But, you could have a unix box spoof the windows
machines just fine.

> 4) Is there any plans to update mod_backhand to work with the new apache
> 2.0 module api?

Yes. and No. I am not going anywhere near Apache 2.0 until it is well into
Beta stage. I don't want to write something then rewrite it. Also, there
will be several design changes to cope better with the different MPMs.

> 5) It looks as if mod_backhand supports SSL connections to the backhand
> server, and then backhands using standard http (without ssl). Is this
> correct? If this is the case, is any sort of SSL header information
> forwarded to the secondary servers? I.E. if a connection comes in via
> https to server 1 which backhands via http to server 2 is there anyway
> for a script or cgi program on server2 to check that the connection (to
> server 1) used ssl? Ideally It would be nice if this were done in such
> a way that all current cgi scripts which check for SSL information would
> still work properly without modification. Effectively faking server 2
> cgi scripts into thinking that ssl was performed directly to them. In
> this way people developing scripts would not need to have any special
> knowledge of the setup of the server systems and would be able to hand
> ssl as normal.

It should do just what you want. If it doesn't, it should be a fairly trivial
modification to mod_backhand to make it do that. I would need to know what is
not working before I would attempt tackling that.

> 6) if #5 is done in apache only setups, what are the forwarded ssl
> headers and sample values so I could write an ISAPI filter on NT IIS to
> make use of the SSL header infor on NT scripts.

I don't know where the SSL headers are set. I just looked in mod_ssl and I
don't see where it sets any headers. If I am to assume that the client sets
these headers, then they will definitely be passed back unmodified.

Any which way it is doable with a little effort.

> 7) is there a real advantage to spliting up "heavy weight" apache
> processes from "light weight" ones and forwarding to light weight
> processes from heavyweight ones? Isn't a new apache process needed for
> each client connection to the mod backhand machine, and then one for
> each backhanded request. (of course with some benefit to the http 1.1
> upgrade) I.E. I am going to use two apache processes to do the work
> that could be just as easily accomplished with one?

This is a clissic approach to solve a problem of "spoon feeding a client"...
Yes, one of each is required to serve a request. The idea is that the backend
(heavy-weight) servers the request to the frontend instance immediately (it
reads all available data and then the backend instance is free to serve
another request. All the while the frontend is "spoon feeding" the data to a
slow client. This allows you to not tie up a backend process with a slow
client. You can also have the mod_backhand instance serve things like mages
that take no "effort" without proxying them at all.

> 8) Basically what I am hoping to do here is have a heavy weight apache
> process running mod backhand forward all requests for *.asp pages to an
> NT server. Any request that is not for an *.asp page should be serviced
> by the same server running the heavy weight apache process. Is this
> possible? How would I accomplish it? Is there any benefit to having a
> separate "heavy weight" apache process which would handle mod backhand,
> ssl, user/pass authentication, mod re-write, logging, etc, and then
> light weight processes which would serve .htm pages and handle normal
> linux php, cgi, perl processes?

First, the benefit of having a light/heavy apache set up on that system...
Dunno. Test it out and see. I find that setting the socket send buffers high
in Apache often eliminates the need for lightweight frontend Apache servers.

Is it possible? definitely. If it is just one NT server in the back, then it
is possible out of the box. You can have the mod_backhand server advertise
itself as the NT server with "MulticastStats NT_IP_addr broadcastaddr:port".
Tuen on self redirection "BackhandSelfRedirect On". And then you are done.

Things are are chosen to be backhanded (like .asp) will be proxied to the
local machine (which is actually the NT machine). If you have more than one
NT machine you want to balance over, then you (or someone) will beed to write
either a backhand resource broadcaster for Windows or you (or someone) will
need to write a standalone backhand broadcaster that will spoof for other
machines. NOTE: spoofing on the hardware level is not required -- backhand is
very trusting. It is really more just lying than spoofing :-)

--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7

[mod_backhand-users] Lots of questions [ In reply to ]

sean-apache-modbackhand-users at chittenden

Aug 28, 2001, 9:48 PM

Post #3 of 9 (2020 views)

Permalink

--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> > 6) if #5 is done in apache only setups, what are the forwarded ssl
> > headers and sample values so I could write an ISAPI filter on NT IIS to
> > make use of the SSL header infor on NT scripts.
>=20
> I don't know where the SSL headers are set. I just looked in mod_ssl and=
I=20
> don't see where it sets any headers. If I am to assume that the client s=
ets=20
> these headers, then they will definitely be passed back unmodified.
>=20
> Any which way it is doable with a little effort.

I'm 99% sure that SSL only sets ENV variables and no HTTP
headers. What you can do is write a quick module that takes the ENV
variables and translate them into HTTP key/vals that are forwarded back.
-sc

--=20
Sean Chittenden

--J/dobhs11T7y2rNN
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Comment: Sean Chittenden <sean@chittenden.org>

iEYEARECAAYFAjuMdBIACgkQn09c7x7d+q0vEQCgwiBc9WgeIl++86ux/sMAOBa+
IpwAn0Lp+qdNBqR+plof98DQ+xU937Lv
=05Ti
-----END PGP SIGNATURE-----

--J/dobhs11T7y2rNN--

[mod_backhand-users] Lots of questions [ In reply to ]

james at rcpt

Aug 28, 2001, 11:23 PM

Post #4 of 9 (2033 views)

Permalink

--SLDf9lqlvOQaIe6s
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 29, 2001 at 12:19:47AM -0400, Theo E. Schlossnagle wrote:
> > 4) Is there any plans to update mod_backhand to work with the new apache
> > 2.0 module api?
>=20
> Yes. and No. I am not going anywhere near Apache 2.0 until it is well in=
to
> Beta stage. I don't want to write something then rewrite it. Also, there
> will be several design changes to cope better with the different MPMs.

=2E.. which, having taken a look at the Apache-dev mailing lists, is someth=
ing=20
being decided upon right now (or at least, last weekend). 2.0.25 may be the=
=20
beta, if it is tarballed.

<chomp>
> Dunno. Test it out and see. I find that setting the socket send buffers=
=20
> high in Apache often eliminates the need for lightweight frontend Apache=
=20
> servers.

Unless there are other constraints, such as memory usage, etc, which is=20
an overhead on every pache child, and not needed for 80% of requests. As=20
an examlpe, mod_jrun under apache with 12 - 18 virtual hosts makes an=20
overhead of several MB per child (for no good reason). This isn't needed=20
for 99% of requests, so you could spawn a lot more children to handle=20
the non-mod-jrun traffic, and proxy to a sufficiently equipped apache=20
when needed. Indeed, someone was reocmmending this for mod_perl at=20
ApacheCon Europe 2000 (Can't remember who off the top of my head: Ryan??).

Anyway, just my thoughts...

James
--=20
James Bromberger <james_AT_rcpt.to> www.james.rcpt.to

Remainder moved to http://www.james.rcpt.to/james/sig.html

--SLDf9lqlvOQaIe6s
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7jIpGpfJwKAkXqeQRAgzpAJ0Sc6wcwoXIcRcgIrOYtmIPcBsvTACeJ/7P
MZMw2HBQA6N09dZtGPdlbWg=
=sh9b
-----END PGP SIGNATURE-----

--SLDf9lqlvOQaIe6s--

[mod_backhand-users] Lots of questions [ In reply to ]

jesus at omniti

Aug 28, 2001, 11:33 PM

Post #5 of 9 (2020 views)

Permalink

James Bromberger wrote:
> overhead of several MB per child (for no good reason). This isn't needed
> for 99% of requests, so you could spawn a lot more children to handle
> the non-mod-jrun traffic, and proxy to a sufficiently equipped apache
> when needed. Indeed, someone was reocmmending this for mod_perl at
> ApacheCon Europe 2000 (Can't remember who off the top of my head: Ryan??).

Many people talk about this as it is common practice. The person who probably
_recommended_ it was Stas :-)

--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7

[mod_backhand-users] Lots of questions [ In reply to ]

Robert.Butler5 at verizon

Aug 29, 2001, 5:56 PM

Post #6 of 9 (2012 views)

Permalink

Theo,

Thanks for the answers. I really appreciate it. I have a few
more questions and responses to your answers below.

> > 1) Does mod_backhand do a true "http 1.1" connection from the
apache mod
> > backhand server to the remote server?

>It can. IT will upgrade the connection to keep-alive if necessary.
>If the request coming in is HTTP/1.0, it will leave it as such. If
the
>incoming request is HTTP/1.1, then it uses HTTP/1.1 on the back end.
I think
>the only thing it doesn't currently support is POST requests using
>Chunked-Encoding for the post data. There is a patch from Kevin that
incorporates this,
>I just have not had time to integrate it and the demand has not been
there.

Well, lets just add a little demand! hehe

> > 3) The reason for both the above questions is I would like
mod_backhand
> > to backhand to some NT IIS web servers. Obviously they cannot run
> > mod_backhand as it only runs on unix.

>Hmm.. I wouldn't be tempted to write one for Windows. But someone
else can
>:-) Ideally someone would write it to run on Windows so it acutally
give the
>load of the machine, etc. But, you could have a unix box spoof the
windows
>machines just fine.

This is something that I may be interested in doing in my spare-spare
time. I'm already busy doing so much in my spare time. hehe See
below for more questions on this topic.

> > 4) Is there any plans to update mod_backhand to work with the new
apache
> > 2.0 module api?

>Yes. and No. I am not going anywhere near Apache 2.0 until it is
well into
>Beta stage. I don't want to write something then rewrite it. Also,
there
>will be several design changes to cope better with the different
MPMs.

Apache 2.0.16 is now in public beta. Granted it is the first public
beta, but the module api's should be fairly solid since so much of
even the core of apache 2.0 uses them. So, could you please get mod
backhand ready for apache 2.0? (please, please, please)

> > 5) It looks as if mod_backhand supports SSL connections to the
backhand
> > server, and then backhands using standard http (without ssl). Is
this
> > correct? If this is the case, is any sort of SSL header
information
> > forwarded to the secondary servers? I.E. if a connection comes in
via
> > https to server 1 which backhands via http to server 2 is there
anyway
> > for a script or cgi program on server2 to check that the
connection (to
> > server 1) used ssl? Ideally It would be nice if this were done in
such
> > a way that all current cgi scripts which check for SSL information
would
> > still work properly without modification. Effectively faking
server 2
> > cgi scripts into thinking that ssl was performed directly to them.
In
> > this way people developing scripts would not need to have any
special
> > knowledge of the setup of the server systems and would be able to
hand
> > ssl as normal.

>It should do just what you want. If it doesn't, it should be a
fairly trivial
>modification to mod_backhand to make it do that. I would need to
know what is
>not working before I would attempt tackling that.

> > 6) if #5 is done in apache only setups, what are the forwarded ssl
> > headers and sample values so I could write an ISAPI filter on NT
IIS to
> > make use of the SSL header infor on NT scripts.

>I don't know where the SSL headers are set. I just looked in mod_ssl
and I
>don't see where it sets any headers. If I am to assume that the
client sets
>these headers, then they will definitely be passed back unmodified.

>Any which way it is doable with a little effort.

This looks promising. If this is the case then very little would have
to be done on the NT end to fake ASP apps into thinking the SSL was
done directly to the NT box instead of being passed through backhand.
NT IIS has a few features that would have to be faked out in order for
ASP apps to be completely fooled. Simple things like checking the
port from asp would have to be set to 443 instead of 80 if the
backhanded request was originally asp. (because iis is only listening
on port 80, and not ssl enabled for real) I'll have to look into
apache mod perl and php more to see if they have any similar features
which would have to be faked out. (Or maybe you could... please?) I
am not very familiar with linux / apache yet.. But I'm learning
fast..

> > 7) is there a real advantage to spliting up "heavy weight" apache
> > processes from "light weight" ones and forwarding to light weight
> > processes from heavyweight ones? Isn't a new apache process
needed for
> > each client connection to the mod backhand machine, and then one
for
> > each backhanded request. (of course with some benefit to the http
1.1
> > upgrade) I.E. I am going to use two apache processes to do the
work
> > that could be just as easily accomplished with one?
>
>This is a clissic approach to solve a problem of "spoon feeding a
client"...
>Yes, one of each is required to serve a request. The idea is that
the backend
>(heavy-weight) servers the request to the frontend instance
immediately (it
>reads all available data and then the backend instance is free to
serve
>another request. All the while the frontend is "spoon feeding" the
data to a
>slow client. This allows you to not tie up a backend process with a
slow
>client. You can also have the mod_backhand instance serve things
like mages
>that take no "effort" without proxying them at all.

Correct me if I am wrong, but apache 2.0 is multithreaded even on
Linux (redhat 7.1) correct? So this problem / concern of heavy /
light processes would be eliminated when apache 2.0 comes out correct?
Because only 1 apache "process" would be running with multiple
threads, and no children. Thus the additional memory footprint would
be reduced, and the costs of spawning additional children would no
longer exist. (yes, there would be the cost of creating additional
threads though)

Also, the faking of SSL to other apache processes on the same machine
would no longer be a concern because they would actually be serviced
by the process that did the ssl. Although if the requests were
backhanded to other machines the faked ssl backhand would still have
to be looked into / done.

>I find that setting the socket send buffers high
>in Apache often eliminates the need for lightweight frontend Apache
servers.

Yes, I saw this in the backhand_course_notes.pdf. Very cool!

>Is it possible? definitely. If it is just one NT server in the
back, then it
>is possible out of the box. You can have the mod_backhand server
advertise
>itself as the NT server with "MulticastStats NT_IP_addr
broadcastaddr:port".
>Tuen on self redirection "BackhandSelfRedirect On". And then you are
done.

>Things are are chosen to be backhanded (like .asp) will be proxied to
the
>local machine (which is actually the NT machine). If you have more
than one
>NT machine you want to balance over, then you (or someone) will beed
to write
>either a backhand resource broadcaster for Windows or you (or
someone) will
>need to write a standalone backhand broadcaster that will spoof for
other
>machines. NOTE: spoofing on the hardware level is not required --
backhand is
>very trusting. It is really more just lying than spoofing :-)

This is something I may do. I have a few questions / concerns that I
would like you to review if you don't mind.

It looks like the server stats are broadcase using a method similar to
the following

1) obtain stats (somehow, who cares for now)
2) convert everything in serverstat to network byte order except for
hostname, mtime, connect.
3) copy this structure to a buffer
4) blast this buffer to the network through a socket

Now in step 4 it looks like two different socket methods are used. if
the first byte of the network IP address is >=224 and <= 239 then
multicast sockets are used. Otherwise normal udp datagram sockets are
used.

The arriba looks like it is calculated by looping many times
calculating a formula and determining the time it took to complete
that work. It looks like on a mutlithreaded posix environment this
formula is calculated 1 time each on 12 different threads (ideally to
load up all cpu's) then all this information is thrown away and the
calculation is done again on one thread and this is the arriba.

I would implement this by allowing the admin to select the number of
threads to use for calculating the arriba. That way if they were
backhanding to all NT servers they could choose a higher thread number
to exercise all the processors. But if they were backhanding to NT
and Unix boxes they could set the value to one to simulate what unix
was doing.

step 2 of the process above concerns me. This is because the time_t
structure and the sockaddr_in structure are not converted to network
byte order before being put onto the network. This is fine if all the
backhanded machines are the same hardware / os type, but concerns me
when a mixed hardware / os type is used. Perhaps the
serverstat_endian_convert macro could be changed to also convert the
time_t and sockaddr_in structures to network byte order

On NT time_t is a long int
and sockaddr_in is

struct sockaddr_in{
short sin_family;
unsigned short sin_port;
struct in_addr sin_addr;
char sin_zero[8];
};

For the sockaddr_in it would probably be best to expand the structure
manually and convert the fields of the structure to network byte
order. That way if the definition of sockaddr_in were different
across machines it would not be an area for concern.

Lastly, here is what I thought I would use for values in the
serverstat structure on NT

serverstat field = value

hostname = hostname from NT registry as set by admin
mtime = calculated by IIS filter when serverstat struct is updated
(IIS filter is similar to apache module)
sockaddr_in = setting from NT registry set by admin
arriba = calculated on first startup. Stored in registry afterwards.
removing from registry would cause re-calculation
aservers = 1. Always one on NT only 1 process, it's always available.
(always 1 on apache 2.0?)
nservers = 1. Always one on NT only 1 process. (always 1 on apache
2.0?)
load = ?? to be determined
load_hwm = ?? to be determined
cpu = cpu idle time from NT performance counters (maybe slow?)
ncpu = find using NT api, or setting from registry set by NT admin
tmem = find using NT performance coutners (mabye slow?) or set by NT
admin in registry
amem = find using NT performance counters (only way possible)
numbacked = counted by NT IIS filter
tatime = calculated by NT IIS filter

For numbacked and tatime. What is the period for those values. Is
numbacked incremented forever, or is it the count over the last minute
or some other time period. Same for tatime. Is it the average for
all backhanded processes ever, or just for the last xxx seconds.

this message would be rebroadcast every x seconds where x would be set
by the administrator, but have to correspond to whatever was set in
mod_backhand byage setting

Well, let me know what you think. Idea's / suggestions / corrections
definetly appreciated.

Thanks for all your help Theo.

Rob

[mod_backhand-users] Lots of questions [ In reply to ]

jesus at omniti

Sep 11, 2001, 12:05 PM

Post #7 of 9 (2016 views)

Permalink

Sorry it took so long to get back to you... I have been very busy.

On Wednesday, August 29, 2001, at 08:56 PM, Rob Butler wrote:
> Apache 2.0.16 is now in public beta. Granted it is the first public
> beta, but the module api's should be fairly solid since so much of
> even the core of apache 2.0 uses them. So, could you please get mod
> backhand ready for apache 2.0? (please, please, please)

All in due time. This is not a priority on my list. When I find a good
personal use for Apache 2.0, I will port mod_backhand.

> This looks promising. If this is the case then very little would have
> to be done on the NT end to fake ASP apps into thinking the SSL was
> done directly to the NT box instead of being passed through backhand.
> NT IIS has a few features that would have to be faked out in order for
> ASP apps to be completely fooled. Simple things like checking the
> port from asp would have to be set to 443 instead of 80 if the
> backhanded request was originally asp. (because iis is only listening
> on port 80, and not ssl enabled for real) I'll have to look into
> apache mod perl and php more to see if they have any similar features
> which would have to be faked out. (Or maybe you could... please?) I
> am not very familiar with linux / apache yet.. But I'm learning
> fast..

Good luck.

> Correct me if I am wrong, but apache 2.0 is multithreaded even on
> Linux (redhat 7.1) correct? So this problem / concern of heavy /
> light processes would be eliminated when apache 2.0 comes out correct?
> Because only 1 apache "process" would be running with multiple
> threads, and no children. Thus the additional memory footprint would
> be reduced, and the costs of spawning additional children would no
> longer exist. (yes, there would be the cost of creating additional
> threads though)

That is very theoretical :-) I don't want to start a flame war (and I
think this list is small enough), but Linux's threading support is
pathetic compared to Solaris, IRIX, and Windows. Last time I check the
prefork MPM for Apache 2.0 still out performs the threading one on Linux.

> Also, the faking of SSL to other apache processes on the same machine
> would no longer be a concern because they would actually be serviced
> by the process that did the ssl. Although if the requests were
> backhanded to other machines the faked ssl backhand would still have
> to be looked into / done.

I am confused.. this is already the case.

> This is something I may do. I have a few questions / concerns that I
> would like you to review if you don't mind.
>
> It looks like the server stats are broadcase using a method similar to
> the following
>
> 1) obtain stats (somehow, who cares for now)
> 2) convert everything in serverstat to network byte order except for
> hostname, mtime, connect.

hostname is a string. So, it needs no endian conversion. mtime is set
on reception of a message, so it is essentially ignored. What is
connect? You mean contact? contact is stored in network byte order...
No need to convert it..

> 3) copy this structure to a buffer
> 4) blast this buffer to the network through a socket

Yup

> Now in step 4 it looks like two different socket methods are used. if
> the first byte of the network IP address is >=224 and <= 239 then
> multicast sockets are used. Otherwise normal udp datagram sockets are
> used.

Correct. Messages to multicast addresses use IP Multicast and other
addresses use IP broadcast.

> The arriba looks like it is calculated by looping many times
> calculating a formula and determining the time it took to complete
> that work. It looks like on a mutlithreaded posix environment this
> formula is calculated 1 time each on 12 different threads (ideally to
> load up all cpu's) then all this information is thrown away and the
> calculation is done again on one thread and this is the arriba.
>
> I would implement this by allowing the admin to select the number of
> threads to use for calculating the arriba. That way if they were
> backhanding to all NT servers they could choose a higher thread number
> to exercise all the processors. But if they were backhanding to NT
> and Unix boxes they could set the value to one to simulate what unix
> was doing.

12 was chosen so that the calculation would be reasonable even on
machines with more than 8 processors.

> step 2 of the process above concerns me. This is because the time_t
> structure and the sockaddr_in structure are not converted to network
> byte order before being put onto the network. This is fine if all the
> backhanded machines are the same hardware / os type, but concerns me
> when a mixed hardware / os type is used. Perhaps the
> serverstat_endian_convert macro could be changed to also convert the
> time_t and sockaddr_in structures to network byte order
>
> On NT time_t is a long int
> and sockaddr_in is

I may address this in a future version of mod_backhand to force it to be
a 64bit unsigned integer.

> struct sockaddr_in{
> short sin_family;
> unsigned short sin_port;
> struct in_addr sin_addr;
> char sin_zero[8];
> };

Looks right.

> For the sockaddr_in it would probably be best to expand the structure
> manually and convert the fields of the structure to network byte
> order. That way if the definition of sockaddr_in were different
> across machines it would not be an area for concern.

We don't need to expand it, but storing it in network byte order is
desired.

> Lastly, here is what I thought I would use for values in the
> serverstat structure on NT
>
> serverstat field = value
>
> hostname = hostname from NT registry as set by admin

Please use FQDN (with Internet Domain Name)... it is a web server after
all

> mtime = calculated by IIS filter when serverstat struct is updated

But, unimportant as the mod_backhand instances will set this as the
packets are received.

> (IIS filter is similar to apache module)
> sockaddr_in = setting from NT registry set by admin

yup

> arriba = calculated on first startup. Stored in registry afterwards.
> removing from registry would cause re-calculation

cool.

> aservers = 1. Always one on NT only 1 process, it's always available.
> (always 1 on apache 2.0?)
> nservers = 1. Always one on NT only 1 process. (always 1 on apache
> 2.0?)

I would set these to 0/0 as they don't really apply.

> load = ?? to be determined

This could be very useful.. you want the average number of threads in
the runqueue over the last second or couple of seconds.

> load_hwm = ?? to be determined

Don't bother... This is set on the receiving host.

> cpu = cpu idle time from NT performance counters (maybe slow?)

Get it when you can (once every 5,10,15 minutes)... This info could be
useless for decisions of load balancing. So, we don't use candidacy
functions that rely on those metrics.

> ncpu = find using NT api, or setting from registry set by NT admin
> tmem = find using NT performance coutners (mabye slow?) or set by NT
> admin in registry
> amem = find using NT performance counters (only way possible)

Good.

> numbacked = counted by NT IIS filter
> tatime = calculated by NT IIS filter

Ignore these. You are not backhanding on those machines.

> For numbacked and tatime. What is the period for those values. Is
> numbacked incremented forever, or is it the count over the last minute
> or some other time period. Same for tatime. Is it the average for
> all backhanded processes ever, or just for the last xxx seconds.

tatime and numbacked are not applicable.

> this message would be rebroadcast every x seconds where x would be set
> by the administrator, but have to correspond to whatever was set in
> mod_backhand byage setting

1 second interval.

> Well, let me know what you think. Idea's / suggestions / corrections
> definetly appreciated.

Good luck.

--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7

[mod_backhand-users] Lots of questions [ In reply to ]

Robert.Butler5 at verizon

Sep 13, 2001, 4:28 PM

Post #8 of 9 (2014 views)

Permalink

Hey Theo,

Just wanted to clear a few things up.

(cut)
> > Correct me if I am wrong, but apache 2.0 is multithreaded even on
> > Linux (redhat 7.1) correct? So this problem / concern of heavy /
> > light processes would be eliminated when apache 2.0 comes out
correct?
> > Because only 1 apache "process" would be running with multiple
> > threads, and no children. Thus the additional memory footprint
would
> > be reduced, and the costs of spawning additional children would no
> > longer exist. (yes, there would be the cost of creating
additional
> > threads though)
>
> That is very theoretical :-) I don't want to start a flame war (and
I
> think this list is small enough), but Linux's threading support is
> pathetic compared to Solaris, IRIX, and Windows. Last time I check
the
> prefork MPM for Apache 2.0 still out performs the threading one on
Linux.

Isn't the threading support much better in the 2.4 linux kernel? So
shouldn't it be more capable now?

(cut)
> hostname is a string. So, it needs no endian conversion. mtime is
set
> on reception of a message, so it is essentially ignored. What is
> connect? You mean contact? contact is stored in network byte
order...
> No need to convert it..

How is contact stored in network byte order? It's a struct that
contains other data primitives, and structures. Doesn't is need to be
converted to network byte order? Shorts and longs should be converted
to network byte order before being broadcast right? Also, what
information is held in contact? Is it the IP of the server that the
receiver should backhand too?

struct sockaddr_in{
short sin_family;
unsigned short sin_port;
struct in_addr sin_addr;
char sin_zero[8];
};
struct in_addr {
union {
struct { u_char s_b1,s_b2,s_b3,s_b4; } S_un_b;
struct { u_short s_w1,s_w2; } S_un_w;
u_long S_addr;
} S_un;
#define s_addr S_un.S_addr /* can be used for most tcp &
ip code */
#define s_host S_un.S_un_b.s_b2 /* host on imp */
#define s_net S_un.S_un_b.s_b1 /* network */
#define s_imp S_un.S_un_w.s_w2 /* imp */
#define s_impno S_un.S_un_b.s_b4 /* imp # */
#define s_lh S_un.S_un_b.s_b3 /* logical host */
};

(cut)
> > On NT time_t is a long int
> I may address this in a future version of mod_backhand to force it
to be
> a 64bit unsigned integer.

It's the same size on NT as on Linux so that's fine. Since mtime is
set by the receiver as you say it's byte order does not matter. As
long as the machines are all the same architecture this will be fine,
but as soon as the architechture changes things will not work the
same. For instance time_t on an linux/alpha is 64 bits according to
some sites I have visited. So if you had an alpha trying to backhand
to some intel machines backhand would have problems.

(cut)
> > aservers = 1. Always one on NT only 1 process, it's always
available.
> > (always 1 on apache 2.0?)
> > nservers = 1. Always one on NT only 1 process. (always 1 on
apache
> > 2.0?)
>
> I would set these to 0/0 as they don't really apply.

I think I may set these to 1/1. Personally I think 1/1 more
realistically represents what is really happening, and it will also
safeguard any "custom" backhand functions which divide by nservers.
aservers could be 0, but nservers would never be 0 if backhand is
broadcasting, because backhand is in a server, or else it's not
broadcasting.

>
> > load = ?? to be determined
>
> This could be very useful.. you want the average number of threads
in
> the runqueue over the last second or couple of seconds.
>
Still looking into this.

(cut)
> > ncpu = find using NT api, or setting from registry set by NT admin
> > tmem = find using NT performance coutners (mabye slow?) or set by
NT
> > admin in registry
> > amem = find using NT performance counters (only way possible)

for the amem and tmem are you counting only "real" installed memory,
or are you also counting virtual memory?

(cut)
> > this message would be rebroadcast every x seconds where x would be
set
> > by the administrator, but have to correspond to whatever was set
in
> > mod_backhand byage setting
>
> 1 second interval.

Is this what backhand does? or is the time configurable?

Thanks for your help Theo. Once I get a few things checked out, and
finish up some other things I am going to get started writing this
broadcaster for NT.

Rob

[mod_backhand-users] Lots of questions [ In reply to ]

jesus at omniti

Sep 13, 2001, 6:04 PM

Post #9 of 9 (2028 views)

Permalink

On Thursday, September 13, 2001, at 07:28 PM, Rob Butler wrote:
> Isn't the threading support much better in the 2.4 linux kernel? So
> shouldn't it be more capable now?

If you say so... I don't find it any better.

> How is contact stored in network byte order? It's a struct that
> contains other data primitives, and structures. Doesn't is need to be
> converted to network byte order? Shorts and longs should be converted
> to network byte order before being broadcast right? Also, what
> information is held in contact? Is it the IP of the server that the
> receiver should backhand too?

yes, yes, yes. I typically store all network addresses (IPs and ports)
in network byte order by default. Intel machines are just an
annoyance. :-)

> It's the same size on NT as on Linux so that's fine. Since mtime is
> set by the receiver as you say it's byte order does not matter. As
> long as the machines are all the same architecture this will be fine,
> but as soon as the architechture changes things will not work the
> same. For instance time_t on an linux/alpha is 64 bits according to
> some sites I have visited. So if you had an alpha trying to backhand
> to some intel machines backhand would have problems.

I agree. I have two alpha machines and an Intel machine in the same
backhand cluster working fine. I'll have to dig a little deeper on that.

>> I would set these to 0/0 as they don't really apply.
> I think I may set these to 1/1. Personally I think 1/1 more
> realistically represents what is really happening, and it will also
> safeguard any "custom" backhand functions which divide by nservers.
> aservers could be 0, but nservers would never be 0 if backhand is
> broadcasting, because backhand is in a server, or else it's not
> broadcasting.

I completely disagree here. 1/1 implies that you have 0 percent
utilization. It is supposed to represent that number of connections
that remain available on the server. You cannot have 1000000 open TCP
connections on an NT server. So, to do it correctly the denominator
should be the maximum number of possible connections and the numerator
should be the number of current connections that exist to the web server.

1/1 implies that you have valid information and it is simply
misrepresenting the real situation. 0/0 are "impossible numbers" and
imply that the metrics are unusable. Any code that doesn't check for a
0 in the denominator of a calculation is broken and should be fixed.

> for the amem and tmem are you counting only "real" installed memory,
> or are you also counting virtual memory?

Not virtual. Real memory installed. Or perhaps the amount of RAM
available to programs when absolutely no programs are running (the NT
kernel takes some space).

> Is this what backhand does? or is the time configurable?

This is what backhand does and the time is not configurable. Of course,
that doesn't mean it shouldn't be :-) It sounds like a good thing to
have configurable, but an extremely low number is needed to keep the
resource information fresh.

> Thanks for your help Theo. Once I get a few things checked out, and
> finish up some other things I am going to get started writing this
> broadcaster for NT.

Great. I would be more than happy to include it in the distribution
once you have it working.

--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7