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. > > 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 > > <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 > </FilesMatch> > > 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. > > > 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. > > <FilesMatch "\.htm$"> > RewriteEngine On > RewriteRule \.(htm|html|cgi|images)$ - [last] > Options FollowSymLinks > RewriteRule ^/(.*)$ http://images.webserver.com:80/$1 [r] > > SetHandler perl-script > PerlModule Apache::ASP > PerlHeaderparserHandler Apache::SearchBot > ExpiresActive On > PerlHandler Apache::ASP > PerlSetVar UseStrict 1 > PerlSetVar Debug 2 > PerlSetVar Global /tmp > </FilesMatch> > >
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. > > > Any thoughts? > > > Shawn > > > > -----Original Message----- > From: Tony Clayton [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 08, 2005 8:15 PM > To: modperl@perl.apache.org > Subject: Re: PerlTransHandler question > > Quoting shawn <[EMAIL PROTECTED]>: > > > > 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. > > 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. > > 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 > 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 > from the > same apache server instance, as you realize that this doesn't solve > your problem > 4) You also realize that the TransHandler doesn't make much sense > (AFAICT) if > assertion #2 is not true. > > If any of these assertions are false, we may need to back up a bit. > > 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 > 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 > > 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. > > 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 > > See also: > http://perl.apache.org/docs/1.0/guide/performance.html > > If your primary concern is slow clients, then you might consider > mod_gzip. > > And the obvious of course... keep your images as small as possible, or > provide > smaller, clickable thumbnails. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please notify the sender immediately by email if you have received this email by mistake and delete this email 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. Finally, the recipient should check this email and any attachments for the presence of viruses. The organisation accepts no liability for any damage caused by any virus transmitted by this email.
