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 loading Moose will incur a 5-6 second overhead on non-persistent CGI application scripts. That's just not acceptable for these one-off applications.

By contrast, when we're using a persistent process system (such as FCGI), this startup overhead is eliminated (or rather, only incurred once), and all is well. The problem we have is that we can't guarantee that all of our code will always run under a persistent process.

We investigated using Mouse as a feature-limited drop-in-replacement for Moose, but as it turns out (as mentioned in this answer) that's not a viable option. Any libraries we write to work with Moose will fail to work with Mouse in subtle but important ways. And we really don't want to fork all of our modules so that we can support both Moose in a persistent environment and Mouse for "vanilla" CGI.

Given that, we have the following options:

1. Fork our in-house modules to work with either Moose or Mouse, as appropriate. (Yuck!)
2. Only develop our modules for FCGI/Moose. Don't support "vanilla" CGI anymore. If we have to write scripts that aren't persistent, they won't be able to leverage our in-house modules.
3. Don't use either Moose or Mouse, but some other object framework.

Which option is best? We are leaning towards 2 right now, and we'll just suck it up if we have to get something running as a vanilla CGI. How about other frameworks? Is there anything more lightweight we should be looking at?

Answer 1

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 2

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 3

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.

Answer 4

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 5

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 6

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.