Mailing List Archive

[mod_backhand-users] mod_backhand and mod_perl
Hi,

I am considering using mod_backhand in a rather simple arrangement. I
have an Oracle database server and a single Apache server running both a
lite Apache instance and a mod_perl Apache instance. For awkward but
currently necessary reasons, the mod_perl Apache is the front-end server
and images and text are served from the lite Apache back-end via
mod_proxy. We're adding a second Apache server to this configuration and
mod_backhand looks like a very cool way to hand off work to the second
server.

I've searched the archives and the internet, and although I've found
mention of mod_perl and mod_backhand working together, I haven't found
anything that tells me if this is a good idea or not. Or anything on how
to compile mod_backhand and mod_perl into Apache simultaneously.

Configuration is Apache 1.3.14 and mod_perl 1.24_01 on Solaris 2.6.

Any and all thoughts are appreciated!

Bob Foster
System Administrator
Dissemination, Inc.
Hotresponse.com
(541) 617-5021
bob@hotresponse.com
[mod_backhand-users] mod_backhand and mod_perl [ In reply to ]
Bob Foster wrote:
> I am considering using mod_backhand in a rather simple arrangement. I
> have an Oracle database server and a single Apache server running both a
> lite Apache instance and a mod_perl Apache instance. For awkward but
> currently necessary reasons, the mod_perl Apache is the front-end server
> and images and text are served from the lite Apache back-end via
> mod_proxy. We're adding a second Apache server to this configuration and
> mod_backhand looks like a very cool way to hand off work to the second
> server.

That is very strange... Running mod_perl on the frontend and mod_proxy on the
backend? I have several installations where mod_backhand is on the front end
and mod_perl is on the backend and it works great.

> I've searched the archives and the internet, and although I've found
> mention of mod_perl and mod_backhand working together, I haven't found
> anything that tells me if this is a good idea or not. Or anything on how
> to compile mod_backhand and mod_perl into Apache simultaneously.
>
> Configuration is Apache 1.3.14 and mod_perl 1.24_01 on Solaris 2.6.

Configuring mod_backhand and mod_perl in Apache 1.3.14 should be very straight
forward. I would compile mod_backhand and mod_perl as static modules on
Solaris -- weird problems seem to crop up on otherwise (Solaris specific).

So, unpack apache and mod_backhand in seperate directories and in the
mod_backhand directory run ./precompile /path/to/source/of/apache

Then just install mod_perl however you like and pass the
--enable-module=backhand through to APACI. mod_perl can be tricky the first
time to get all the appropriate options passed to Apache's configure.

> Any and all thoughts are appreciated!

Be careful before you make these blanket statements ;-)

--
Theo Schlossnagle
Senior Systems Engineer
33131B65/2047/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
[mod_backhand-users] mod_backhand and mod_perl [ In reply to ]
Bob,

The Backhand HTTPRedirectToIP 127.0.0.1:8080 will not work. That actually
sends a HTTP redirect! Also, it doesn't take an argument. So it will
redirect the user (_not_ proxy them) to the host's IP address. This isn't
what you want.

Here is how the hack for single host accelerating works:

(1) You ned to run a mod_perl instance without mod_backhand enabled on a
private interface or the loopback interface (127.0.0.1 is fine). If you want
to put it on port 8080, that is fine, but I prefer to put it on the same port
as my externally accessible web server (80) it eliminates many complications.
So a "Listen 127.0.0.1:80" in the mod_perl httpd.conf is what you want.

(2) You want to run a lean and mean apache with only the modules you need
(not mod_perl) on the front end listening to the external interface on port
80. I put a entry on all of my /etc/hosts files (on all my machines) that
aliases "myip" to the machines IP address. In your external apache
httpd.conf, you can put Listen myip:80

(3) Configure your frontend webserver to up the TCP buffers (to accelerate
things a little). To do this add "SendBufferSize x" to your external Apache
httpd.conf (x is usually 65536 or 131072).

(4) Now for the hack. mod_backhand will only redirect to its peers (or to
itself). So, you need to convince mod_backhand that _itself_ is 127.0.0.1.
So, in your external httpd.conf file, instead of the normal "MulticastStats
225.220.221.20:4445,1", put "MulticastStats 127.0.0.1 225.220.221.20:4445,1"
This will tell the local mod_backhand instance to advertise itself as
127.0.0.1. [.if you use a different multicast or broadcast address, that is
fine] To verify that it is working, visit /backhand/ and verify that there is
one machine and its IP is 127.0.0.1 and its port is 80.

(5) Tell mod_backhand to proxy to the best server _even if it is the local
machine_. To do this, add the line: "BackhandSelfRedirect On"

Now, assuming you use the "Backhand" directives for only your mod_perl
scripts, mod_backhand will not activate for all other content (letting the
external apache answer) and proxy to itself (at 127.0.0.1:80) for mod_perl
content.

Also, be sure to turn on KeepAlives on the mod_perl server! You will no
longer run out of children and mod_backhand will keep pools of open
connections so that you don't have to reconnect for every request.

Bob Foster wrote:
> Theo Schlossnagle wrote:
> >If you have only one machine, and you ran Apache/mod_backhand on the front
> >interface and Apache/mod_perl on the 127.0.0.1 or backend interface, you
>
> This is what I'd like to try first! However, after spending several hours
> reading the FAQ and other documentation, and trying a bunch of things, I
> realize that I'm going to need more help.
>
> I established the mod_perl backend with the command:
> Listen 127.0.0.1:8080 Is this the correct way to do that? I can
> run perl-status from a browser on this same box and see it fine.
>
> I added the following on the mod_backhand frontend:
> <Directory /cgi-bin/>
> Backhand HTTPRedirectToIP 127.0.0.1:8080
> </Directory>
> This MUST be wrong but it was my best guess. NOTHING ever gets redirected
> to the backend.

--
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
[mod_backhand-users] mod_backhand and mod_perl [ In reply to ]
Bob Foster wrote:
> >
> > (4) Now for the hack. mod_backhand will only redirect to its peers (or
> >to
> >itself). So, you need to convince mod_backhand that _itself_ is
> >127.0.0.1.
> >So, in your external httpd.conf file, instead of the normal
> >"MulticastStats
> >225.220.221.20:4445,1", put "MulticastStats 127.0.0.1
> >225.220.221.20:4445,1"
> >This will tell the local mod_backhand instance to advertise itself as
> >127.0.0.1. [.if you use a different multicast or broadcast address, that is
> >fine] To verify that it is working, visit /backhand/ and verify that
> >there is
> >one machine and its IP is 127.0.0.1 and its port is 80.

If you want to do this with multiple machines, you should assign a private
network to the machines in addition to their existing network. Of course, you
should use something in RFC1918 described space. Try 192.168.73.2 (through
30). Then you don't bind to 127.0.0.1, you bind to 192.168.73.x:80 (where x
is the last octet of that particular machine). All of the machines will see
each other's internal IP addresses and be able to proxy requests to them.

Best described by the page: http://www.backhand.org/ApacheCon2000/US/img11.htm

> #Backhand byCPU
> # If I add the line above, the child process faults every time with this
> message
> # [notice] child pid 6354 exit signal Segmentation fault (11)

Yikes! That shouldn't happen.

> AcceptStats 208.44.73.0/27 # This works. I hope it's right. We use
> 208.44.73.2 through 30

Yup... That's correct.

> My only comment for the broadcast/multicast section is that the
> documentation needs some fleshing out for folks like me who don't
> understand this aspect of networking well. I will try to write up my
> assumptions on what should be said here and after you review/correct them,
> you may want to include them in "Help: configuring mod_backhand."

Okay. I will look into this.

--
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