On Sunday, April 18, 2010, Cliff Wells <cliff@develix.com> wrote:
> On Sun, 2010-04-18 at 21:25 -0500, Ryan Malayter wrote:
>> On Thursday, April 15, 2010, cls <nginx-forum@nginx.us> wrote:
>> > I'm a little confused by "fastcgi".  What are the benefits of using
>> fastcgi as my proxy "protocol" rather than standard HTTP?
>> >
>> Most interpreted HTTP servers are slow, single threaded, and generally
>> don't work great at scale. Not sure about perl, but this is definitely
>> true for Ruby, .net, and others.
>
> There are plenty of fast HTTP servers written in interpreted languages.
> In fact, I can not think of a single example that has your described
> limitations nor what these suggested limitations may have to do with
> HTTP versus FastCGI.   The slowness of the application will matter far
> more than the protocol used.

It's not the protocol, it is the design. Most dynamic-language web
servers I've used seem to be focused on being a development sever, and
not a production HTTP server. I am thinking of things like Cassini or
one if the many Python web servers.

Is there a stable, simple perl-based HTTP sever that can handle a lot
of concurrent requests? I don't think such a thing exists for PHP,
.NET, or Python, maybe perl is different.

--
RPM

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx