RE: PerlTransHandler question

[prev] [thread] [next] [Date index for 2005/03/10]

On Wed, 2005-03-09 at 17:53 -0700, shawn wrote:
> Thanks for the detailed response; all your assumptions are correct
> almost... Maybe if I give a bit more detail on the structure someone
> could suggest a better strategy.
>=20
> I have one apache server with mod_perl enabled. I have done a fair bit
> of tuning and preloading so it runs quite well, one of its main
> functions is to allow users to upload images, it then cuts the images =
up
> into different sizes and places them in different directories. =
Although
> recently users have been uploading large pdf catalogs which they claim
> are very important..... Currently this server is the only server =
running
> and serves up every page
>=20
> <FilesMatch "\.htm$">
> 	SetHandler perl-script
> 	PerlModule Apache::ASP
> 	PerlHeaderparserHandler Apache::SearchBot
> 	ExpiresActive On
> 	PerlHandler Apache::ASP
> 	PerlSetVar UseStrict 1
> 	PerlSetVar Debug 2
> 	PerlSetVar Global /tmp=09
> </FilesMatch>
>=20
> My main problem is then when general browsers start to download these
> pdfs they hold a mod_perl connection open for way to long. There for I
> have set up images.webserver.com which is just a small apache server
> that is not using mod_perl and that is what is listed in my previous
> message.
>=20
>=20
> I am aware that I could just change the links to the pdfs but that is
> allot of code changes and may cause problems with the image upload =
code
> etc. My desired solution is to keep the mod_perl as the front end and
> have something else serve up the images, I have been fooling around =
with
> mod_rewrite but havent been able achive the desired effect. I have =
tried
> variations of the following.
>=20
> <FilesMatch "\.htm$">
> 	RewriteEngine On
> 	RewriteRule \.(htm|html|cgi|images)$ - [last]
> 	Options FollowSymLinks
> 	RewriteRule ^/(.*)$ http://images.webserver.com:80/$1 [r]
>=20
> 	SetHandler perl-script
> 	PerlModule Apache::ASP
> 	PerlHeaderparserHandler Apache::SearchBot
> 	ExpiresActive On
> 	PerlHandler Apache::ASP
> 	PerlSetVar UseStrict 1
> 	PerlSetVar Debug 2
> 	PerlSetVar Global /tmp=09
> </FilesMatch>
>=20
>=20

Why is your rewrite rule inside the FilesMatch? Surely it should be
outside if you want it to match images (or anything other than just .htm
files :)

> Another reason why I would like the mod_perl server to be the front =
end
> is because it has ssl enabled and there will be problems with the cert
> across different server.
>=20
>=20
> Any thoughts?
>=20
>=20
> Shawn
>=20
>=20
>=20
> -----Original Message-----
> From: Tony Clayton [mailto:tony@xxxxxxx.xx]=20
> Sent: Tuesday, March 08, 2005 8:15 PM
> To: modperl@xxxx.xxxxxx.xxx
> Subject: Re: PerlTransHandler question
>=20
> Quoting shawn <shawn@xxxxx.xxx>:
>=20
>=20
> > So far this working on my development environment, but what I am
> really
> > wondering about is if this will actually take the load off mod_perl?
> > (it's a little hard for me to tell without significant traffic) Will
> the
> > mod_perl server execute the page and release the connection and not
> care
> > how long the images server is taking? If anyone has a better =
solution
> or
> > an idea I would love to hear it.
>=20
> OK, this is a little confusing... it's hard to tell what you are doing
> here.
> First, I'm not sure I'd assume that a CPU usage spike can be blamed on
> apache
> serving up images.  That should be mostly disk reads and I wouldn't
> expect it
> to effect CPU much.  Good monitoring, logging, and load-testing might =
be
> in
> order.
>=20
> Second, I'm going to assert a few assumptions on what you are doing:
> 1) you are running (at least) two apache/mod_perl webservers... one =
for=20
> serving
> static content and one for serving mod_perl requests
> 2) You have installed this TransHandler on both web servers, for
> whatever
> reason, which is why you have the if statement
> 3) You are therefore NOT running images.webserver.com and =
webserver.com=20
> from the
> same apache server instance, as you realize that this doesn't solve=20
> your problem
> 4) You also realize that the TransHandler doesn't make much sense
> (AFAICT) if
> assertion #2 is not true.
>=20
> If any of these assertions are false, we may need to back up a bit.
>=20
> If these assertions are all true, then I see what you are trying to do
> (and in
> theory it could work), but it's worth mentioning the following:
> - you could send images.webserver.com in the original content, thus=20
> avoiding the
> browser redirect and eliminating the need for the TransHandler
> - I'm not sure why you would need/want mod_perl on the static content
> server
> - you could alternatively use mod_rewrite
>=20
> Note also that if you are on an OS with copy-on-write memory pages =
(ie:
> linux)
> then you can keep the apache children thin and light by preloading =
your
> mod_perl modules in the parent.  If children are thin and light, you =
can
> run
> more of them for the same bang/buck.  If you are really diligent at
> preloading
> things, then you may find that the original apache/mod_perl is light
> enough.
>=20
> You might want to consider running two apaches together:
> 1) apache/mod_ssl/mod_proxy/mod_gzip/mod_mmap_static server as a
> front-end
> 2) proxying to the apache/mod_perl backend
>=20
> See also:
>    http://perl.apache.org/docs/1.0/guide/performance.html
>=20
> If your primary concern is slow clients, then you might consider
> mod_gzip.
>=20
> And the obvious of course... keep your images as small as possible, or
> provide
> smaller, clickable thumbnails.
>=20

This email and any files transmitted with it are confidential and =
intended solely for the=20
use of the individual or entity to whom they are addressed. Please =
notify the sender=20
immediately by email if you have received this email by mistake and =
delete this email=20
from your system. Please note that any views or opinions presented in =
this email are solely
 those of the author and do not necessarily represent those of the =
organisation.=20
Finally, the recipient should check this email and any attachments for =
the presence of=20
viruses. The organisation accepts no liability for any damage caused by =
any virus=20
transmitted by this email.=20