perl-asp mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fagyal Csongor <>
Subject Re: Apache::ASP with Worker MPM
Date Tue, 05 Dec 2006 13:15:41 GMT
Tom Haapanen wrote:

> On 2006-12-05 06:47, Fagyal Csongor wrote:
>> What I have been running lately is an Apache2.2 with the worker MPM 
>> as a  proxy, and a good-old Apache1.3 with mod_perl+Apache::ASP as 
>> the "real" server. The mod_perl server serves the dynamic ASP pages, 
>> while the front servert the static content. This is a very typical 
>> configuration IMHO.
>> I could once (something like two years ago?) make Apache::ASP run 
>> with Apache 2.0, but that was a long time ago... since then, I stick 
>> to the above config - which I recommend to you if you do not want to 
>> waste too much time on figuring out all the stuff about Apache2.x and 
>> mod_perl (even though it shouldn't be too hard).
>> For the record: we do somewhere around 6M-8M pageviews per month (see 
>> at, 
>> which peeks to approx. 500-700k pageviews per day in busy periods. 
>> This is a 1.8Ghz Core2 with 3G RAM, in a shared environment (with two 
>> other rather busy sites running on the same server). CPU utilization 
>> reaches 50% of all available CPU time, tops (I guess half of that is 
>> coming from the ASP site).
> Thanks ... it sounds like your config works well for you.  However, 
> since 95% of our page views are dynamic, I'm not sure it would gain 
> much.  The only thing I can think of there is serving all the images 
> off Apache 1.3.

Usually a webpage (at least in our case) consists of the main .asp 
(.pet, etc.) file plus the additional stuff, like .js, .css and image 
files. The ration is usually around 1:10 (of course that can vary a 
lot). It is a huge benefit that these hits do not hit the heavyweight 
mod_perl server. Also, the front proxy server can have keepalive 
switched on, runs threaded, very lightweight, only using small memory 
footprint as compared to the huge mod_perl server.

Also keep in mind that you will end up having a lot of mod_perl-ed 
Apache instances running unnecessarily because of (realtively) slow 
clients, which keep your Apache waiting. Again, this is a typicla 
reverse proxy configuration.

Before we started to use this config, we always had memory problems, 
having 200+ Apache instances running, which is an overkill. Now we can 
serve dynamic hits with only 30 Apache1.3 instances, while having 
somewhere around 400 Apache2.0 available connections.

I also have another website running on a dual 2.4GHz Xeon, in a similar 
config, with 4G RAM - that handles 2M pageviews per day (that is over 
20M HTTP requests).
This results in 2000+ active connections at peek to the front server, 
while we only have somewhere around 120 instances of the backen server 

> Our CPU load isn't too bad (dual Opteron 242 currently) since the 
> database is on a separate server, but there are still times that the 
> number of httpd processes are maxed out and the browser has to wait 
> for a connection.  So the new hardware will be dual Opteron 270s (dual 
> core) so I have no worries about CPU load -- I'd just rather run 4-6GB 
> rather than 8-10GB of RAM.

Well, see above :)
You can easily decrease the number of instances needed if you make your 
incoming connections independent of the speed of the remote client.

Just take a look at your /server-status/. Especially if you have big 
files to serve, you will see connections lingering there. That is what 
eats up your resources.

> But maybe the images on a separate server process are the answer ... 
> there are close to 10x as many requests for images as for pages.  
> Mostly small GIFs but also a lot of larger JPEGs.  Need to give this 
> idea some thought as an alternative.  Thanks!

Even though I do not know your application, I am pretty sure this would be a possible alternative
for you.

See this:

There are many white pages and how-to-s on this subject around. I can also give you an example
httpd.conf snippet if you are interested.

- Fagzal

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message