in reply to CGI::Application and HTML::Template

Hey NOP!

I'm the author of CGI::Application. First off, you should check out the mailing lists. Send a message to to subscribe for CGI::Application. The HTML::Template list is at

Regarding CGI::Application and HTML::Template "war stories" --

My company uses both modules all the time for exactly the types of projects you're describing! We've been using them, or their predecessors for nearly three years. Most of our work we do (95%) can be described as connecting relational databases to the web, in some way.

One Intranet project we've built on these two modules, contains 40 CGI::Application modules consisting of nearly 22,000 lines of code. On the same system we use 200 HTML::Template files, consisting of over 23,000 lines, in total.

You asked about run-time performance. This Intranet was designed to support 3000 concurrent users, and a total user base of 50,000, world-wide. We're using a cluster of Linux servers, Apache + mod_perl, DBI, and (of course) CGI::Application and HTML::Template. We're VERY happy with the performance of the two modules. HTML::Template has been thoroughly optimized for run-time performance, and features several types of performance tuning, including caching. CGI::Application is a very this layer, and is flexible enough to allow the programmer to optimize their code in any conceivable way!

Your other question was about “programming-time” performance -- how maintainable are applications built on CGI::Application and HTML::Template? This may be the most important software project management question for anyone to ask! The answer is, the PRIMARY GOAL of both modules is to maximize the maintainability of the software! In the case of this particular Intranet project, we’ve been evolving the software through constant releases for nearly two years, and we have not run into any problems as a result of these two modules.

Applications built on CGI::Application focus on cleanly organizing functionality. Because applications are Perl modules, you can even write POD to document functionality. The conceptualization of a CGI as a finite-state machine naturally lends itself to traditional Object-Oriented Design techniques, which further allow you to document, document, DOCUMENT your code! This has proven invaluable to us as new programmers come into our projects and old ones depart. Because the foundation is steady, transferring knowledge is greatly facilitated!

HTML::Template was designed with a singular goal: To cleanly separate functionality from design! This is the single decision which most greatly enhances your ability to maintain your web-application code! By keeping HTML out of the Perl, and Perl out of the HTML, you can bring a new programmer or a new designer into a project and they can focus, undistracted, on the task of maintaining your application! HTML::Template files look like HTML (so much so, they will even work with tools like Dreamweaver). This is on purpose! The syntax is clean to allow you to hire the best designer and the best programmer available. You should not have to settle for the best “generalist” who is most likely an expert in neither Perl nor HTML!

Furthermore, HTML::Template files easily lend themselves to documentation. By simply defining variables, loops and conditional blocks, you have a mechanism for defining a User Interface without laboring on the “creative” aspects of the UI. We have started to include HTML::Template design as a part of our detailed specification documents! This allows us to start a project with a much higher degree of specificity, which ultimately results in shorter schedules, lower costs and higher quality of software.

I hope this answers your question! If you need more details (whew!), get on the mailing list!



  • Comment on Re: CGI::Application and HTML::Template

Replies are listed 'Best First'.
Re: Re: CGI::Application and HTML::Template
by Anonymous Monk on Dec 02, 2000 at 08:08 UTC
    Hi Jesse,

    How many servers on the cluster, and is it straight, one heavy mod_perl server with no proxy front end, no mod_backhand?
    Also, what is the performance with no mod_perl?
      The cluster is front-ended with a Coyote Point Equalizer for load-balancing. The CPE is essentially a dynamic port-forwarder, designed for speed. It's pretty cheap, too -- about $4k for their low-end model which can handle something like 80,000 concurrent connections.

      Each server in the cluster also has a reverse proxy running in front of the mod_perl server. The proxy serves two important purposes. First, it provides a light-weight Apache to deal with the slow clients. This allows heavy mod_perl Apaches to get out quick, instead of dealing with slow transfers.

      Second, the proxy runs SSL, while the mod_perl servers do not! This is a cool technique we developed to get around the problems resulting from RSA licensing requirements. Essentially, we need to compile Apache as we see fit, for speed and functionality. SSL servers (especially those available in 1998, when this project started) don't allow you to recompile them (apaci is neither easy nor reliable!). By using layers implemented via reverse proxies, we can compile our own Apache + mod_perl, yet still get SSL legally.

      I hadn't heard of mod_backhand until you mentioned it. I'm still wrapping my head around it -- it seems to be a dynamic reverse proxying mechanism. My instincts are that this wouldn't provide an advantage over straight load-balancing (except in cost, which is not a big factor here). Do your experiences differ?