On Sun, 2010-04-18 at 22:21 -0500, Ryan Malayter wrote:
> 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.

Can you name one of these Python web servers? I've only used a few
(CherryPy, Tornado, FAPSWS), but these easily handle thousands of
requests per second. Some frameworks, like Django and Pylons, come
with a "development" server that's designed for testing, but that is
special-purpose software, not some general statement about the
capabilities of Python web servers.

See http://nichol.as/benchmark-of-python-web-servers for a nice summary
of the current breed of Python HTTP servers. Note that some of the
servers (notably Tornado and Twisted) don't perform as well as they
could since the benchmarks here are WSGI-oriented and WSGI and async
don't mix well.

> 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.

Python certainly has them. I can't speak for Perl, PHP, or .NET, but I
don't see any reason it wouldn't be reasonable to write one. If they
don't exist, I assume the reason would be their long-term integration
with larger HTTP servers (Apache, IIS) which would make development of a
standalone server appear moot.

The key thing to remember here is that a standalone "hello, world"
program can easily achieve thousands of requests per second with any of
these servers, but the minute you start querying databases, handling
sessions, etc, your performance will fall through the floor regardless
of whether your use FastCGI or HTTP. If you are basing your
scalability planning around FastCGI vs HTTP then you are worrying about
the wrong part of the stack.

Regards,
Cliff

--
http://www.google.com/search?q=vonage+sucks


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