On Sun, 22 May 2011 20:10:07 +0300, Adam D. Ruppe
<destructiona...@gmail.com> wrote:
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.
Yes, of course - the difference is negligible if the server load is low.
But if your website is getting enough hits to generate more requests than
the server can process, technology choice matters a lot.
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.
Yes, I should have added that I meant for very simple requests. The speed
advantage of a compiled language will always overtake most initialization
overheads for non-trivial requests.
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.
Is there any reason you didn't go for FastCGI or SCGI? The main advantage
I can see is that CGI is much simpler for edit-compile-test iterations.
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.
The difference here is that HTML, CSS and jQuery will only be loaded once.
I was talking about AJAX web-apps.
--
Best regards,
Vladimir mailto:vladi...@thecybershadow.net
