Re^2: mod_perl memory footprint

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

Comment on Re^2: mod_perl memory footprint

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]