md wrote: > Hello, > > I'm working on a dynamic site that I originally > thought I would do with mod_perl. Now after reviewing > the requirements and available hardware, I wonder if > mod_perl will be my best solution. > > The machine will not be a huge box (though I wasn't > provided much in the way of specs) and will only have > 256M of RAM. There will be static content, incuding > 5-10 images per page. The client has only given me > sparse information, but claimed that he currently had > 4,000 unique visitors a day and wanted to move to > 10,000-15,000 unique visitors per day (he didn't give > me page view stats). I may or may not be able to set > up multiple instances of Apache. > > Given limited hardware (esp. RAM), am I better off to > go with mod_perl (larger Apache processes with limited > RAM) or CGI (smaller apache processes but the usual > cons)?
Don't get mislead by the memory requirements. If your code will run 10 times faster you will need *at least* 10 times less servers to do the job. But it's not uncommon to get even better speedups. So chances are that mod_perl will be a win in any case. Read the guide for restricting the memory used, shared memory, etc., and you are all set. It includes some numbers, showing how much memory you really need if you follow the guidelines. The only situation when mod_cgi could be a win over mod_perl is when you have almost zero code loaded and most of your operations are CPU or IO/bound, so mod_perl's precompilation/caching won't help much. but that's a very rare situation. In any case we are talking about registry scripts, aren't we? In that case it takes very little time to turn it on and off and test what is better. Unless you are talking about writing full fledged mod_perl API handlers, which is only when your should plan/analyze before you code. __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
