1. The number of web pages per second that you can display without causing the server to slow down excessively.
2. The amount of time that the user waits for content to appear.

To fix speed type #2 there are many tricks, many of which do not seem to be widely used. Here are a few:

• Optimize the size of image files, for example by reducing the number of colors in a gif file or the amount of compression in a jpeg.
• Include the size tags for the image files so that the browser can do the layout before loading the image.
• Set $|=1 so that your script sends output as soon as it is ready.
• Your CGI should call print two or three times. This is because print is *very* slow. People tend to have many more print statements in a CGI, and they are often the cause of performance problems. The way to avoid calling print too often is to buffer up a bunch of output into a string and print that. I have seen print cause more performance problems than perl objects.
• Your first CGI print statement should generate enough content in the browser to get the reader started. The reader won't really care if the rest of the load takes a few seconds longer.
• Don't use layouts with tables nested to many levels inside of tables, at least in the first print statement. This takes a long time for the browser to render. Most browsers won't render anything at all for a table until the close of the outermost table.
• Don't use a lot of little graphic buttons. Try to keep graphics down to three images, up to seven is reasonable. Any more should be somewhere in your web page where waiting for them won't annoy the reader.
• Disk reads should not be a problem for loading modules. Any file that is often-used will get cached by any decent operating system. Loading large perl modules can be slow for other reasons, but this is fixed by using mod_perl.

To make your code friendly to porting to mod_perl, you should:

• use strict;
• Don't declare any variables outside of subroutines in the modules that you write.
• Leave time in the schedule for lots of testing and fixing things in your mod_perl program. Mod_perl is worthwhile as a performance advantage, but it requires more work to do correctly. It is much less forgiving of sloppy coding practices than CGI.
• Use a computer than can hold lots of RAM. You will be able to make speed/memory tradeoffs in mod_perl, until you run out of sockets for more RAM. In my last project I was able to justify lots of RAM because it was the cheapest way to increase performance.
• Make sure your web server is Apache running on Linux or some sort of Unix.

It should work perfectly the first time! - toma

1)I'm not sure what you mean? Like a $dbh->connect() call verse an open()? Certainly a connect() call is faster than a sleep(1000) call, the latter of which is perl-only, so it just depends.

2)Well, somewhat true. There are different loading methods that can be implemented to load-on-demand, so to speak. However, using a module usually means that its been tested and it usually anticipates more conditions than you would, so its usually the better choice(I do use usually, b/c as I said, it all varies; though if neccessary, you can edit a module down to size, to fit your purposes).

3)I don't follow here...if you're using mod_perl? Then you can have Apache cache the modules upon loading up your machine, an it won't require extra time accross different script invocations. And user-created modules are no different from standard modules--at least to Apache.

4)Well, again, guess what? It depends. Mostly, it depends how the module was designed. For instance, CGI.pm, according to CGI Programming with Perl is slower if non-OO methods are used, so OO methods are better. Bottom line: Benchmark.

5)YES! Static HTML pages are *much* faster(well, generally). This is because to create a CGI script requires creating a separate proccess on the server's machine. . . this takes time. Using mod_perl, fast cgi, etc., can take away some of this time, but on general static HTML is faster(quite a bit, usually).

Bottom line to a long post: It all depends, so BENCHMARK THE CODE. Situations change/vary, things can be true for one thing, exceptions arise, etc. Cold, hard rules are hard to come by in way of efficiency.

As for CGI and SSI, I would use SSI on mostly static pages, particularly those that are not results of any previous CGI (eg, for a quote of the day, or the like). Anything else should be done with CGI and a template solution; in most cases, the template module can be cached if you use mod_perl, so you gain a further advantage.

>2. Modules

This speed hit is only taken if you don't preload your modules. All used modules should be loaded in your apache startup. Then, they will be compiled only once. The memory (mostly) doesn't even need to be copied, it uses shared memory with copy-on-write, so it is very very fast. There is not a speed difference in loading a pre-loaded Perl module in mod_perl versus loading a C library. However, this can use a lot of RAM. I've had sites where there were two apaches, one for mod_perl, another for everything else, the mod_perl version used 6 megs per process, the other used 1 meg. It was very fast for everything that way.

>3. Modules & Apache

Yes, it caches them. It evals them. Don't use mod_perl until you're read the docs long enough to understand what this does to the namespace. Really.

1. Database accesses do slow down a script, DBI has a lot of overhead. You can increase your performance with a database specific driver (i.e. one written using the database api) but you'll loose portability.

2. In my opinion the slight overhead that modules incur is well worth the maintainability of the code, machine performance wise might not be the best solution, but manpower performance wise it is definitely worth it to use modules.

3. Apache and mod_perl cache perl modules, whether or not they are user created, a module is just a module. I beleive that scripts are even cached if they are run under Apache::Registry

4. OO code is usually a bit slower than procedural. I tend to make small scripts procedural and larger projects OO, although it sometimes just makes sense for the small scripts also.

5. Straight HTML is faster. Any other combinations you should benchmark yourself (since there are just way too many ways to combine perl and SSI to give a straight answer). If you run apache use ab, it's a great tool to help you figure out what is happening.

Other notes. use the Benchmark module and Devel::DProf to see what really effects the performance of your scripts and ab (apache benchmark) for your web comparisons.