On 22/05/2011 22:40, Adam D. Ruppe wrote:
Vladimir Panteleev wrote:
But if your website is getting enough hits to generate more
requests than the server can process, technology choice matters a
lot.
Yeah. I've never had that happen, so I don't really know. If it
happens, it's easy enough to change later. (it was a two line change
just now to switch it to built-in webserver - none of the actual
app code needs to change at all)
Is there any reason you didn't go for FastCGI or SCGI?
The biggest reason is they are harder to implement, and it's
premature optimization. I didn't want to spend a lot of extra
time writing code that would never be needed!
FastCGI has an interface available that emulates CGI - that's not
exactly harder to implement! ;)
Secondary benefits are simplicity and reliability. A CGI process
can segfault without affecting anyone else. It can go completely
wild on memory, and it doesn't matter because it's short-lived
anyway. It can deployed to any server with ease - just copy
the binary in there. Worst case, you add a couple lines to
.htaccess.
Same for FCGI, for the most part, except it's a long running process.
You can set it up to periodically re-spawn if you like, or it will
automatically re-spawn when you exit (error or otherwise).
Apache (or IIS) also handles logging and other details for a CGI
program.
Same for FCGI.
It's just simpler in a lot of ways.
That's debatable! :D
--
Robert
http://octarineparrot.com/
