It's a no-brainer, if you're worried mainly about performance. Basic story: mod_perl embeds a perl interpreter in Apache. No starting up a separate perl interpreter when you start a CGI script! Secondly, Apache::DBI allows database connection pooling, and pretty intelligently. It's a *big* speed gain, but there is increased memory usage.

If you code cleanly, and follow the guidelines you've already read, you shouldn't have much of a problem. Eventually, the thing to do is move away from thinking in terms of CGI scripts and writing mod_perl handlers; then, basically, you've got a big suite of Perl apps that groks HTTP ... mondo powerful. Why, you could even write a great website around that sort of technology!

perl -e 'print "How sweet does a rose smell? "; chomp ($n = <STDIN>); 
+$rose = "smells sweet to degree $n"; *other_name = *rose; print "$oth
+er_name\n"'
[download]

Contrary to the w3c advise you shouldnt use em for font sizes, and you should rather use px. Reason 1: If you use em then as screens become more advanced with better resultion and bigger sizes then you font gets smaller as in the examples on this page. Reason 2: People with eye proplems set their screen res smaller because they want the text to get bigger - thats the whole point of screen res. Eugene

Both em and px will shrink as the resolution increases. The difference is that em is based on the user's preferred font size and is thus a better choice from the user's point of view.

This is exactly backwards. Increasing screen resolution makes pixels smaller on the screen. All modern operating systems and browsers have type display controls independent of screen resolution and that's how those with special requirements should handle it.

If you develop all your code under a mod_perl environment, it should be a no-brainer to simply transfer the code to a non-mod_perl site; it should work without changes.

The reverse is not true; non-mod_perl code can easily fail under a mod_perl environment if the developement did not plan ahead for it.

Mind you, this assumes you don't use some of the more specialized features of mod_perl; if you do start using those, there is an immediate divergence of what you can do in mod_perl and what you can do in non-mod_perl, and maintaining both at this point would be hopeless (or rather difficult).

We've done a benchmark of mod_perl / FastCGI against regular CGIs, and the results where roughly that the same script runs around twice as fast under mod_perl or FastCGI than as a CGI. These results were got without changing the CGI at all, i.e. they might even get better if you tweak the script to take advantage of special characteristics of mod_perl and FastCGI. These two seem to offer similar performances.