web development in D
Robert Clipsham
robert at octarineparrot.com
Sun May 22 15:04:45 PDT 2011
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/
More information about the Digitalmars-d-learn
mailing list