On Thu, 9 Feb 2012, Paul Wallingford wrote: > 1) Different configurations for the web server side. How do I make this > work with: > - Apache / mod_perl (for production) > - Apache /Fast CGI (for production) > - Standard CGI (for development or servers I cannot change significantly) > - other servers such as AOL, etc.
Use Catalyst, Dancer, or some other framework that supports all of these (and other) deployment modes. > 6) Moose is slow. So slow, that even the Moose people address it in > their FAQ. What can I do to speed it up? What if I can only run on a > standard CGI server that does not have mod_perl? Is it possible to use > Mouse instead? Will Mason2 have a conniption? Are there things I can > do with Mason so that it will not utilize some of the slower Moose features? Moose doesn't have a FAQ, so I'm not sure what you're referring to. While Moose can make compile time slower, it's runtime speed is comparable to writing your own objects from scratch in most cases, and the runtime speed cost is based only on the features you use. One possibility is to use the Plack tools to start a daemon on a high port, and write a CGI shim to talk to it. Of course, you'd effectively be reinventing FastCGI, and it's a lot simpler to configure the frontend server to proxy the requests if you can. But it's a possibility. Heck, you could even consider writing the CGI script in C for speed. However, if you're really, really stuck using CGI, Moose is not a good choice. I'm not sure how good Mouse is either. It still has a bit of overhead. Perl may not even be that good a choice. Starting a new Perl interpreter for each request is a huge amount of overhead. > Also, I noticed that with Mason 1, it was easy enough to pick up, that a > lot of people used it and the list had a lot of traffic. Traffic on the > list has dropped to a tiny trickle since Mason2 came out and I think > that is unfortunate. In my mind, that means one of two things: Mason 2 > is so easy that no one has any questions about it, or it is so > difficult, that people try it and quickly get frustrated and give up, > moving on to the likes of PHP and such. I suspect it is the latter. Here's some other possibilities ... * Nobody is using Mason 1 _or_ 2. They've all moved on to Template::Declare, Quicksilver, and Ruby on Rails. Rails is for cool people. Those of us still on the list are totally unhip losers. * Mason 1 is very stable, and it has good documentation. People are happy with it for now, and so aren't jumping to use a new templating system, even one named Mason 2. * The list was a lot more active in the days when people used Mason as their entire web framework, often paired with mod_perl. I can't count the number of threads we've had about mod_perl issues. Nowadays, the action has moved on to other places, like the Catalyst list. People still use Mason 1 and/or 2, but it's a much smaller part of their development stack. This, BTW, describes me. I use Mason 1 solely for templating on new projects. If I switch to Mason 2 that won't change. * There are more Perl templating systems than ever, and this has reduced the overall user base for each system. * There's also a lot more client-side templating going on. People are using Perl to write a simple JSON-delivering REST backend and writing templates in Mustache or whatever other horrible JS templating tool they can find (they all seem terrible, sadly), so server-side templating has become less relevant in some use cases. This may be me in the near future. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/ ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
