Well, yeah it's just that mod_perl enabled httpd processes tend to be large (independent of the size of files they're serving; it's more dependant on how much preloading you're doing and what's remaining resident you can get pretty large processes (I know 25-30M is about normal on one box I have running mp1)). If you're hitting resource limits then one of the common recommendations is to move to this sort of "tiered" setup where types of requests are routed to servers tuned to handle just that kind of request.
And when I said "cookie" you can take that in the generic sense of "send some sort of session token back". There's no reason you couldn't implement the same kind of scheme using some sort of session id in the redirected URL instead of using a cookie. The principle is the same, the mechanism's just different (and in fact might be slightly more straightforward to handle with mod_rewrite; pull the session key out, look it up in the map, return the real file if it's valid).
FastCGI would be another way to approach the problem in that you separate the extra authentication overhead out from the simple file serving httpd (you're moving to using a pool of FastCGI processes rather than a pool of mod_perl-enabled httpds).
The cake is a lie.
The cake is a lie.
The cake is a lie.
In reply to Re^3: mod_perl memory footprint
by Fletch
in thread mod_perl memory footprint
by DeveloperChris
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |