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