[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [Mason] www.masonhq.com back to work? Paul Wallingford Fri Feb 10 22:00:36 2012

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 

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.


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.


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
         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.
Mason-users mailing list