To check the relative differences between several options listed below, I made the simplest possible “Hello World” page, and benchmarked the time and memory used to serve it. To create a base line, I also measured the results for an empty Perl script that just prints “Hello World”.

The result summary is after the jump.

Let’s go through some of the numbers.

CGI::Simple, a lighter-weight CGI.pm alternative turns in the best time and memory consumption. Before considering using it, note that it has a different interface in a few places, like file upload handling, and there are still some cases that CGI.pm can handle but it can’t, like some kinds of file uploads.

Next there’s much-maligned CGI.pm, still appearing here with a respectable second-fastest start time and low memory consumption. Both CGI::Simple and CGI.pm help process an HTTP request and prepare an HTTP response, which is functionality targeted by most of the options listed here.

CGI::Application is next on the list. It explicitly doesn’t provide any of the functionality of CGI.pm itself, and I don’t think CGI.pm would even be loaded for this bare-bones “Hello World” case. CGI::Application provides basic application structure, control flow, and a callback system for plugins. As a long time user, It’s no surprise to confirm that CGi::Application is a very lightweight solution.

Mojo is next. It’s functionality includes supporting several server backends and abstracting the HTTP server response and request. This is a bit similar to what CGI.pm does, since CGI.pm also supports mod_perl and FastCGI as well has helping with the HTTP request and response. (Of course the Mojo and CGI approaches couldn’t be more different!). Mojo also provides a similar amount of functionality as HTTP::Engine. Mojo’s result shows that it can be a rather lightweight solution itself, perhaps suitable for running in a CGI environment. Overall, the performance of Mojo is impressive here.

Next up we have Mojolicious and Titanium, which had very similar speed benchmarks. Mojolicious adds dispatching and a file-extension based templating system to Mojo, including the ability to serve static pages and a simple built-in templating system. It’s perhaps similar to the amount of functionality that CGI::Application covers when combined with CGI.pm and HTML::Template, but again the approach is very different.

Of the group of systems tested here, I would say Titanium covers the largest scope of functionality, since it goes beyond usual framework offerings, including additional methods for managing database handles, config files, sessions, form validation and form filling. I often run Titanium-style apps under CGI with good performance. In a persistent environment, the smaller memory footprint would be a more significant win here, allowing more application processes to be run concurrently.

Second to last on the list we have Catalyst, the Perl framework which needs no introduction. It’s slower startup time is not particularly considered a concern here, as it is not targeted at being deployed in CGI environments. That it uses a bit more memory does show some kind of additional overhead, although for many deployments a bit extra memory per-process won’t matter.

Finally, taking far more time and still more memory, we have HTTP::Engine. Considering its scope of functionality competes with Mojo, this performance and memory overhead is disappointing. HTTP::Engine explicitly has a CGI interface, but taking 1.5 seconds and almost 15 megs of memory just to print “Hello World” is dismal. Update 12/1/2008- HTTP::Engine replaced “Moose” with “Shika” and massive speed and memory gains, apparently without any reduction in functionality. The run time of 0.19 seconds and memory usage of 6.6 megs is rather respectable.

I can already anticipate the feedback to this article saying that the startup times don’t matter because much of this is compile-time work, which doesn’t apply to persistent-environments, because compilation would only then happen once at server start-up time, and is not per-request. And there’s the perception I expect to hear echo’ed back again: No one uses straight CGI anymore, right?

As a professional website developer with over a decade of experience, nearly all the web applications I’ve written have run in CGI, and have performed just fine this way. Why do anything more complicated, when the simple solution works?

A web framework is a bit like an operating system, it’s there to prop up the layer where the real value-added work happens. For an OS, that’s the application. For a web-app, that’s the custom application logic. If your web application is going to be slow and hog memory it should because your custom application does that, not because the framework itself takes almost two seconds to boot up and uses 15 megabytes of memory before your application really gets started.

If your application is not expected to be high-traffic, several of the solutions mentioned here are candidates for running under CGI, saving the complexity and overhead of deploying in FastCGI or modperl. If you creating your applications with best practices like avoiding global variables, it will likely be easy to convert it to run under modperl or FastCGI later.

As a disclosure, some of the testing scripts I used are below. For Catalyst, Mojo, and Mojolicious, I used the default CGI scripts that came bundled with them.

CGI.pm

use CGI;
my $q = CGI->new;
print $q->header;
print "Hello from CGI\n";

CGI::Application

package HelloWorld;
use base 'CGI::Application';

sub setup {
    my $self = shift;
    $self->start_mode('hello_world');
    $self->run_modes([qw/hello_world/]);

}

sub hello_world {
    my $self = shift;
    return "Hello World\n".
}

HelloWorld->new->run;


# Titanium with Dispatching, dispatch.pl
use CGI::Application::Dispatch;
CGI::Application::Dispatch->dispatch(
    default => 'hello-world/hello_world',
);

Titanium with Dispatching, HelloWorld.pm

package HelloWorld;
use base 'Titanium';

sub setup {
    my $self = shift;
    $self->start_mode('hello_world');
    $self->run_modes([qw/hello_world/]);

}

sub hello_world {
    my $self = shift;
    return "Hello World\n";     
}
1;


# HTTP::Engine
use HTTP::Engine;
my $engine = HTTP::Engine->new(
      interface => {
          module => 'CGI',
          request_handler => 'main::handle_request',
      },
  );
$engine->run;

sub handle_request {
      my $req = shift;
      HTTP::Engine::Response->new( body => "Hello from HTTP::Engine\n\n");
}

Empty.pll

print "Hello World\n";

Here’s my take on Mojo 0.8.7, a new web framework for Perl.

The primary author of Mojo, Sebastian Riedel was once as a primary contributor to Catalyst. There are clearly some similarities, and it’s easy for me to see Mojo as an evolution of Catalyst.

One major difference with Catalyst sparked my interest in Mojo. Catalyst now depends on Moose among other things, with a very long overall dependency change. How long? I downloaded Catalyst 5.8 along with all of it’s non-core Perl module dependencies. The result was over 250 modules, not counting the Catalyst modules themselves, or anything in the Test::* name space. Bleh.

What to see for yourself? Get my “self-contained” patch out of the local::lib tracker and run the following. It will install Catalyst and all it non-core dependencies into a “Catalyst” folder. Be aware, this could take half an hour or more… (The TinyURL points a Catalyst 5.8 tarball)

perl -MCPAN -Mlocal::lib=--self-contained,Catalyst  \ 
-e 'install "http://tinyurl.com/5hbzoo"'

Leaning on dependencies can be a great thing. It works well when you are able to outsource part of your needs to an external module that is already well written, documentation and tested. I’m sure there’s some of that happening in the Catalyst dependency chain. But there’s also a good deal of duplication, as different authors solve things different ways. For example: Exporter.pm, Sub::Exporter and Moose::Exporter all serve the same function, and are dependencies somewhere along the way. Class::Accessor::Fast competes with MooseX::Emulate::Class::Accessor::Fast. And this is where a long dependency chain can start to look and feel like bloat, and it can be difficult to overcome if the owners of the dependencies don’t share the projects preferences about how to export subroutines or build accessors.

It could perhaps be said though that Mojo suffers from re-using too little. Mojo::Base is yet-another accessor-generation solution, like Class::Accessor.

The potential I see in Mojo is the summed up in the following:

• No dependency chain, for less complexity and easy deployment
• Built-in support for several backends, for portability
• A rewrite of HTTP request and response objects, as a sanely designed evolution of what CGI.pm has been used for
• No ties to a specific framework design beneath the server/response-request object layer, for flexibility and potential code sharing between frameworks based on it.

It is this last item that has allowed me to ignore the bundled Mojolicious framework for this review— It’s not required for use with Mojo and could use it’s own review.

Overall, I feel positive about the Mojo project, although I have no current plans to quit developing with Titanium-style projects myself. In theory, they could be used together. Mojo could provide the backend-server support and query object, and CGI::Application could run inside the Mojo handler() in much the same way CGI::Application apps can run in a mod_perl handler. Now, CGI::Application can already run under various servers and with different query objects, so whether or not you’d actually want to use CGI::Application with Mojo is left up to the reader.

I don’t recommend using Mojo yet— it needs more documentation and tests for my taste. It’s Mojo’s clean, scalable and extensible design that make it a project worth following. I’ll be keeping my eye on Mojo.

This post is being discussed on reddit.com