Sorry that I'm am commenting but I live Perl and Mason 1 in production environments. I use Mason components for for JSON content called from AJAX calls as well as content. Mason 1 is Perlish. Just works. I would love a place to give to back. Again I have Mason/jQuery components that would really help people
Mason 2 is a complete change in methodology which I respect. But at the moment I have to serve up real life. In a hostile environment and Mason 1 and Apache 2 provide that. I do not like Moose. I prefer to keep it simple. Mason 1 and libapreq2. I have no idea what Mason 2 is targeted at at or even if it is used in production. But I assure you Mason 1 is/was amazing and still works. -Bill On 02/10/2012 09:53 PM, Paul Wallingford wrote: > 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 ------------------------------------------------------------------------------ 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
