
jwieland at gmail
Apr 23, 2009, 1:41 PM
Post #8 of 9
(2238 views)
Permalink
|
Matt S Trout wrote: > On Wed, Apr 22, 2009 at 05:50:02PM -0700, Jason Wieland wrote: > >> Baseline: Just using the webserver (apache or nginx) to download a >> static file >> Static Catalyst: Running the same query but going through Catalyst to >> retrieve the same static file (using Static::Simple) >> Noop Catalyst: Processing a request on a empty controller >> > > So, you've benchmarked Hello World. Why do you care? > > I've worked on a lot of large scale Catalyst applications, and done a > fair amount of optimisation work, and I have *never* found Catalyst to > be the bottleneck in my performance testing. Better still, because > the teams had used Catalyst they had more time at the end of the > project for performance testing and optimisation and it was easier > to clean up the code because the architecture of the application was > flexible. That really, massively beats caring about how fast Hello > World is :) > I completely agree, one of my most recent projects was creating http://notify.me pure Catalyst we get 10k+ hits a day, rapid development, no issues, its a joy. Catalyst is wonderful technology for all the reasons above and previous emails, hats off to the developers. However I'm working on a different project for an ISP (ondemand anti-phishing protection) which requires us to handle a peak of 10,000 reqs/second and response that takes no less then 250milliseconds. We have an backend engine that can do that all what we need to put in front is a restful web layer. Because of the beauti of Catalyst got this working in a day or two. However to scaling is not going to work in the current state. I'm not using any of Catalyst plugins, just the vanilla Catalyst and its MVC framework. I don't know if it would be better to hack through Catalyst and remove the parts I don't need for this project. Or write another very simple webframework re-create the parts of Catalyst I do use. > I'd point out that BBC iPlayer is built on Catalyst and DBIx::Class > - are you going to tell me you're going to need to scale further than > they do? :) > > >> Also completely unrelated. I could not get Catalyst working on the >> mpm_worker_module. Is Catalyst not thread safe? >> > > Catalyst is threadsafe. Your DBD:: may not be, or something else you > load. But FastCGI is a much better production environment than mod_perl > anyway. > Not using a DBD:: Just try out the base Catalyst example, created when you start a new project. I do agree fastcgi is a better production environment though. Just did the modperl stuff for comparisons and also there are some old timers in the office that are determined to think modperl has to be faster then fcgi. Not withstanding the benefits of a two tiered response layer. Thanks for everyone's time and responses. Jason Wieland
|