A local network connection, though, may be fast enough so that real processing time makes a difference.*

The big slowdown for perl CGI is the time it takes to load the interpreter and program code/modules, since CGI reloads everything for each request, but if your perl code is relatively small, and system load is low, disk caching etc may help bring down the load time if you run the same process repeatedly. (having a shared perllib instead of a static perl binary may help too, I guess).

If your perl program (including the modules it uses) is relatively large, or you've got a lot of requests to handle, using a system (like fastcgi) where you have the process (or multiple processes) running in a loop, handling one request after another without reloading is usually a great benefit, easily capable of increasing the performance 10 to 100 times. Especially since continual processes can make caching of (intermediate) processing a lot easier and faster.

* (update) AFAIK on linux at least, local (loopback) network connections can be shortcut - ignoring much of the network subsystem - that means they can be a lot faster than the maximum speed of the actual network system. In any case, I would guess that on many systems, a connection to localhost would not be dependent on the actual network hardware.

I think what you just said is: Apache 1.3 is slow, so there is no benefit to making your cgi scripts faster by moving to C++.

I would have to say that most often, "well written" compiled C++ is going to be faster than Perl... though things like mod_perl and fastcgi help level the playing field. What I would like to see is some solid benchmarking of the time to write a moderately complex cgi in C++ versus Perl. In my experience it will typically take at least three times as long to write the C++... at least. This is where the true savings come into play, since these days programmers (typically) cost more than hardware.

That's the rub.

As I understand it, the received wisdom is that a constant performance factor doesn't really help you anyway when scaling (you're walking an exponential curve - a constant factor won't help that much). What helps you is having rapid development, so you can remove bottlenecks as you find them (and move onto the next bottleneck).

Basically, what you're after is (horizontal) scalability, not performance. And you can achieve the former more rapidly in a dynamic language (perl, python, pick your poison) than a stricter language (C++, java, C#).

Some notes from a talk by youtube on this: http://kylecordes.com/2007/07/12/youtube-scalability/. In particular: "YouTube is coded mostly in Python. Why? “Development speed critical”

(Of course, there are limits. Having 30 servers instead of 300 is useful. But tweaking for performance (whether that be writing fast, less maintainable perl code or moving stuff to C/C++) generally makes your system less flexible, so is something you want to delay as long as possible).

The most likely reasons for the difference are that the network slowness of a remote test drowns out small speed differences (you said C++ was 4 times as fast, but I bet the actual time difference is quite small), or that your remote host has a faster version of perl than your local machine (or a slower C++ compiler).

There is nearly always a performance advantage to writing things in C, but not a scalability one. Scalability has to do with being able to add more machines without changing your application.

Is language really irrelevant to CGI performance on a typical webserver?

1. Hello World.
2. Print a list of 500 random numbers.
3. Read in and reverse a file.

you could make it instantaneously-fast, or even remove it, and it wouldn't have a significant impact on the global performance at all.

Hi, probably my comment comes a bit late. I consider the study should drop completely Apache server which is less performant as lightppd and you should focus on comparing remote application running on lightppd. It is obvious an interpreted language as Python will never do as well as C++ did, does and will do forewer... ;-)