On 2/10/2012 7:57 PM, Dave Rolsky wrote: > 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.
So you are suggesting either ditching Mason for some other framework (interesting suggestion on the Mason list) or adding more stuff to the mix of an already slow system. FWIW, I do not think it is Mason itself that is slow, but Moose certainly is. And to respond to Jonathan's question if I have experienced Moose as slow or just heard that it was, I have experienced it. I have two apps - same server. One is an old shopping cart system I wrote long ago with Perl and no additional modules. The Perl CGI program is 335KB long and caches in memory after the first invocation. Each invocation requires a new Perl interpreter start up - there is no FastCGI or mod_perl involved. It will sustain over 20 page views per second. Same server - A one page Mason 2 app that is essentially nothing. It sends a very small amount of html to the browser with a couple of lines of javascript in it. The Javascript makes a single Ajax call to the server. I was using this to test how Mason 2 handles Ajax, since I have written Ajax based sites in Mason 1 and know how it performs. This is also standard CGI and requires a new Perl interpreter each time. The pages will cache in memory after the first invocation. Both apps have the same basic environment as I want this to be a reasonably fair comparison. The Mason 2 app takes over 4 seconds to return the initial page view, and another 4+ seconds to process the AJAX call (which is handled by the same Base.mc as served the initial page). In both cases, the server is unloaded and running nothing other than the app being tested at the time. I do understand that much of this delay with Moose is startup and that by pulling various tricks, like FastCGI or mod_perl, performance can be improved past the first invocation. I have not run a comparison test using mod_perl or FastCGI yet. However, note that Jonathan's rationale for stripping out the web code and using Plack is that it allowed Mason 2 to run under a wide variety of platforms and servers, not just Apache with mod_perl. http://search.cpan.org/~jswartz/Mason-2.15/lib/Mason.pm Under acknowledgements: "Thanks to Tatsuhiko Miyagawa and the PSGI/Plack team, who freed me from ever worrying about server backends again." >> 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. And you have just made my point about documentation. The FAQ is right there on CPAN. All you have to do is a simple search. But obviously, having a few pages of documentation on CPAN is no substitute for a book, wiki, etc. http://search.cpan.org/~doy/Moose-2.0402/lib/Moose/Manual/FAQ.pod#I_heard_Moose_is_slow,_is_this_true? Has anyone profiled Moose to find out what is actually taking so much time? I know this was done with PHP5 and a lot of the slowness (which turned out to be in the way PHP4 created objects) was addressed. > But it's a possibility. Heck, you could even consider writing the CGI > script in C for speed. Or Lisp, Snobol, Prolog or assembly. The world's your oyster, but, there's a reason we use Perl - dealing with accumulators and memory registers is a pain in the tuchus. section .data str: db 'Hello world!', 0Ah str_len: equ $ - str section .text global _start _start: mov eax, 4 mov ebx, 1 mov ecx, str mov edx, str_len int 80h mov eax, 1 mov ebx, 0 int 80h > 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. As noted above, I can run a fairly large Perl CGI program that starts a new Perl interpreter each page view fairly quickly. Sure, I can turn that 20+ views per second into 200+ with mod_perl, but that program was written over 10 years ago - closer to 15 now that I think about it - before such things as mod_perl existed, and CGI was the only choice, so it is a decent benchmark to show "progress" in state of the art. I have not tested Mouse yet, but I plan to, however, the Mouse documentation states it is 4 times faster than Moose. I was going to contact the author to find out what Moose has that Mouse omits to see if anything Mason critical is missing. Of course, Jonathan would be a better choice to ask that question since he would know better than I if any missing features might cause a problem. > Those of us still on the list are totally unhip losers. Frankly, that has occurred to me, but I hope not, seeing as I am still here. I like to think that Mason is the superior solution and smugly sit back contemplating all the losers who don't know what they are missing. But, ... there is a reason I started this thread and I must say, I am a bit dismayed to find that the only ones in this discussion are me and the two authors of the software in question. I suppose that speaks for itself. (I do realize that Mason was written almost if not completely by Jonathan and Dave has contributed to Moose and is one of its proponents.) > * 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. Actually, interesting that you brought it up. Since Ajax is the way of the future, I had hoped in the back of my mind, that Mason 2 would have features that enhanced that. I am currently writing such a system and trying to use Mason's features to augment the Ajax calls and template the return results. A system with components, inheritance, etc. actually lends itself to making Ajax calls manageable in much the same way that Mason 1 made page views and templating manageable. I think people may not have realized that yet because most sites I see today might use some Ajax, but overall, are still based on page views. A site that has one page view, but everything from then on happens via Ajax would benefit greatly from Mason managing the Ajax calls. However, Mason could use some features to make the job easier. Paul Wallingford ------------------------------------------------------------------------------ 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
