> > in my case, i need to do authorization. do i need > > extra mod_perl front-end server to do this? how does > > this perform?
the beauty of mod_perl is that you can step in and out of the process wherever you need to. The down side is that mod_perl uses a lot of memory, so you try to keep your mod_perl processes busy for as short a time as possible, so that they can handle more requests. The "standard" way of doing this is by having light weight apache-only (or nginx or whatever takes your fancy) processes sitting in front of your mod_perl servers. They can handle all of the static files, and can proxy the requests that need mod_perl to the backend mod_perl servers. So for an image which needs to be authorized, you can use mod_perl to handle the authorization phase, and then step out of the process to allow Apache to serve the file itself. Yes, this would mean hitting a back end mod_perl server, but it would still be quick as the image itself only has to be transferred to your proxy front end. As far as performance goes, depends on how complicated your authorization is. If you check the time of day, it'll be a lot quicker than if you check 100 rows in the DB. However, the Perl code itself has already been compiled into C and is fast. Not quite as fast as the native apache handler, but still damn fast. > > > > also, will serving the file from backend mod_perl > > server to the front-end proxy a such bad idea? I am > > thinking that the modperl server will spit out the > > file to the proxy without have it tieup with the > > upload and let the proxy handle the file upload. am i > > right about this? ( couldn't find much detail on proxy > > to back it up at this moment ) > > from what i recall, perlbal will do a subrequest to a backend modperl > server for auth, then handle the file upload itself. > Using perlbal is certainly one way to go. http://www.danga.com/perlbal/ It has worked very well for LiveJournal, but requires an extra degree of "logic planning" to integrate it with your site. I would say keep it simple. Do the easy stuff first. If your site is extremely busy and the simple stuff STILL isn't enough, THEN look at solutions like perlbal. > you don't want to do any large file handling, or even general static > file handling, under mp if at all possible. let it handle content > generation and authorization as the 'brains' -- thats what it does > best. use other apps like perlbal, nginx, whatever to handle your > static files and large uploads. This last statement I have a quibble about : using mod_perl to handle file uploads. I may be wrong here, so I'd welcome reasoned disagreement, but the way I understand it: - a proxy front end handles the slow upload of data from the client - it forwards it (internal network, thus fast) to your backend mod_perl server, which can then process it (eg add it to the DB, resize the image, store it where it needs to be stored), and return the data to the proxy. - the proxy sends the data back to the client across the internet, which is slow So: - My image uploads require processing, so I need some form of Perl - I already have that available in mod_perl. - The mod_perl processes aren't being kept tied up for a long period, because the proxy is handling the slow bit: the transfer. - The only downside is that a large image upload plus processing could cause the size of the process to grow a lot, reducing the number of processes that you can run at once. - So use Apache2::SizeLimit to cull too-large processes, or if you know the request is a big one, cull the process manually by calling $r->child_terminate - Keep your upload processing mod_perls on one box, so that if you are flooded with uploads, just the upload functionality on your site is taken out, rather than your entire site I'd be interested in hearing about other approaches. Clint
