Re: mod_perl memory footprint

Prefacing that this is vague hand wavy mode here, but maybe do something like this:

Reverse proxy in front of all of this that routes between a pool of fat mod_perl authenticating servers and larger pool of dumb large file servers
New requests that need authentication come in to the mp servers
If a client is authorized you cook up a temporary download path somewhere the dumb server can handle and redirect the client there (with some sort of session key cookie returned to the client an stuck in a DBM file)
The dumb file server uses mod_rewrite to check the request's cookie against the DBM file (changing to a 404 if it's not found, or serving the file if it is)
A separate reaper process cleans out the DBM file periodically to age out old sessions (or possibly the file servers are still mp enabled and you have a Log handler do the cleanout)

That divides the "heavy" mp workers from the (potentially larger) pool of longer task workers. It also leaves you open to later migrate static file serving off onto separate boxen.

Update: Wording tweaks. Didn't read as well post caffeine . . .

The cake is a lie.
The cake is a lie.
The cake is a lie.

Comment on Re: mod_perl memory footprint

Replies are listed 'Best First'.
Re^2: mod_perl memory footprint by alexm (Chaplain) on Jul 26, 2008 at 18:50 UTC
The reverse proxy would only be needed if the login servers must remain hidden. Otherwise, having login.example.com set a domain cookie for .example.com, which is the authentication token for static.example.com, should be enough. Many popular sites use the separate login server approach.	[reply]
Re^2: mod_perl memory footprint by DeveloperChris (Initiate) on Jul 27, 2008 at 01:45 UTC
I assume that "fat mod_perl authenticating servers" means yes the memory footprint is significant enough to cause issues. At this point I would prefer to keep the existing authentication system which is a simple md5 hash. The perl handler was to decode and test the hash to see if it is still valid. Then if so allow the server to continue to the "real" uri Cookies introduce a whole new level of problems. Considering that our media server are ip based and many browsers and media players etc wont send a cookie to an ip address. That is why we never used cookies to begin with. otherwise we could have done that from the originating server. Given that would fastcgi be a better choice. I could authenticate the user then respond with a X-sendfile header. once authentication is done the socket is dropped and I no longer need to worry about the "memory overhead" allowing the trim apache server(or lighttpd) to process the request as per normal	[reply]
Re^3: mod_perl memory footprint by Fletch (Bishop) on Jul 27, 2008 at 05:13 UTC
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.	[reply]