Vladimir Panteleev wrote: > Regular CGI still has the overhead of starting a new process for > every request.
That's a very small cost - between 1 and 5 milliseconds, depending on your hardware. Next to the network latency involved in making a request, that's literally nothing - it's less than random network variation, so it has no impact on the end user experience. It also disappears quickly if your program does any processing, since it's like a line: y = mx + b. The startup cost is b, and the speed of the language is m. If x is even slightly big, reducing m means you'll get better end results than reducing b. (unless b is *huge*... like network latency. Adding an "Expires:" header to your responses gives the biggest gains of all.) My work application runs about 40% faster on CGI than the fastest comparable product we've found in mod_php, on average, with certain CPU intensive portions being up to 5x faster. That said, an embedded webserver /is/ even faster, but it's also harder to use. The end result depends on your app. Only actually benchmarking it can tell for sure what matters. My cgi.d provides the same interface regardless of how it is called - switching to built in httpd is easy if needed. > I've had great experience with using an HTML/jQuery frontend with > a D backend >From what I've seen in my benchmarks, you would probably get a bigger usability boost by ditching jQuery than by ditching CGI. Even when cached, jQuery takes a while for the browser to parse - comparable to starting up a native process on the server.
