How can I improve Moose performance in non-persistent CGI processes?

Question

Moose is a fantastic object framework. The trouble is that, taken together with its dependencies, it\'s very big. Our profiling indicates that on our platform, simply

Answer 1

My preference would be to drop vanilla CGI support. FCGI hosting is really cheap these days and there's no reason to pander to vanilla CGI (IMO) because it just reinforces the opinion that Perl is slow. But if you can't avoid it then you can use something like Object::Tiny. But if you need Roles, constraints, meta-programming and all the other loveliness that Moose provides, you're out of luck unless you drop vanilla CGI.

Answer 2

My suggestion is to go with option #2 and then help us refactor Moose so that CGI becomes viable. fREW is currently working on the Moose test suite in order to enable the MooseX::Antlers project which should reduce most of the overhead that means Moose is unusable for a CGI environment.

Matt Trout (mst), the man currently behind MooseX::Antlers, has expressed a desire to be able to run apps in a CGI environment if neccessary. I'd suggest stick with FCGI for now and pester him for what you can do to help out!

Answer 3

Jonathan Rockway wrote about APP::Peristent (which, oddly, isn't in CPAN) a few months ago. I haven't used it, but based on his above-linked blog post, it looks to provide a fairly transparent server-client architecture that you could wrap the actual processing of your CGI in.

Answer 4

There is also another option - PPerl.

I have never used it, but it definitely looks interesting. And the person who wrote it (Matt Sergeant aka baud) - it gives you practically guarantee of good quality code.

Answer 5

The basic idea of App::Persistent, pperl, SpeedyCGI and probably some others is that the process of compiling your Perl program to byte code is only done once and some sort of caching is used on invocations after that. Since Moose is said to have quite a compile-time penalty, I'd try this approach first.

I have successfully used pperl for drawing lots of MRTG graphs on an ancient system around 2001. The Perl program was executed for every graph which was quite an overhead -- this probably comparable to your CGI scenario.

Answer 6

You could write a back end server application using Moose, and then write very small, simple CGI scripts that query the back end.

+-------+    +--------------+
| Small |===>|  Persistent  |
|  CGI  |<===| Moose Server |
+-------+  ^  +--------------+
           |
         Socket
       Connection

This is more-or-less what FCGI does, so it may make more sense to just use FCGI.

On the other hand, there may be real benefits in having a non-cgi back end server that can have ANY abstract interface bolted on as needed.

For example, if you use TCP (or UDP) sockets, then you could have a native desktop application hit the same back end as your CGI.

What the best fit is in your case really depends on your specific situation. Depending on the details of the situation, I can see myself deciding to use this approach or any of the approaches you outline above.