Python Tornado server is blisteringly fast when set up properly.

On Wed, Apr 21, 2010 at 2:14 AM, Cliff Wells <cliff@develix.com> wrote:
> On Mon, 2010-04-19 at 23:08 -0500, Ryan Malayter wrote:
>> On Mon, Apr 19, 2010 at 11:17 AM, Cliff Wells <cliff@develix.com> wrote:
>> > 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.
>>
>> The built-in web server in Python had terrible concurrency behavior in
>> our tests, especially when database calls were involved. Not sure why
>> waiting for a DB response would block or severely hamper other
>> requests, but it certainly seemed to be the case.
>
> If by "built-in" you are referring to BaseHTTPServer in the standard
> library, then I am not surprised.   First of all, it is single-threaded,
> so if you have a blocking operation (e.g. accessing a database) then it
> will not be able to serve any other requests until that operation
> finishes.   If you utilize the ThreadingMixin (or something better),
> then it can handle concurrent requests.   That being said, it's still
> quite simplistic and Python's threading model isn't the best.   If you
> want real performance you'll have to look beyond the standard library.
> Depending on your needs, I'd suggest Tornado (async) or CherryPy
> (threaded).
>
>>  The other Python
>> development servers were of course not considered. I didn't look much
>> for other pure-Python servers, as Apache and mod_wscgi was popular and
>> seemed to be the path of least resistance. I looked a bit at Twisted,
>> but it was clearly too much added complexity for too little gain.
>>
>> > 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.
>>
>> Nanoweb exists for PHP, but it actually has to fork to service a PHP
>> request. Go figure. As for .NET, there is no real choice besides IIS
>> except mod_mono or FastCGI.
>>
>> >
>> > 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.
>>
>> I already agreed with you about the *protocol* not being an issue.
>> It's the architecture of the back-end service that matters. In my
>> (admittedly limited experience), all of the dynamic-language HTTP
>> servers I've tried have concurrency behavior, and/or require running a
>> bunch of instances to utilize mutli-core hardware because of
>> underlying issues in the language interpreter. I used the imprecise
>> word "slow" to encompass that for the sake of brevity.
>>
>> Managing and monitoring say, two dozen Mongrel instances on one box
>> seems, well, stupid. If you need lots of single-threaded back-end
>> processes, FastCGI is widely supported, has good existing process
>> management tools, and is designed for the task. It's also probably
>> more manageable as you scale up, which is why I made the suggestion.
>> If scale and performance isn't a concern, why would the OP ask about
>> load-balancing?
>
> Well, this is a different concern altogether.  You made a blanket
> statement claiming "most interpreted HTTP servers are slow, single
> threaded, and generally don't work great at scale", which I consider
> patently false.   Now you've shifted to "FastCGI is easier to manage".
> This may be true, depending on your application stack and experience.
> It may also be more difficult if your stack doesn't natively support it
> or requires 3rd party libraries to be integrated.
> Had the discussion been about a particular application or framework and
> you claimed that this particular stack was simpler using FastCGI, then I
> would have probably had no argument (unless I also used that particular
> stack and felt otherwise, of course).   I personally don't find it
> difficult to deploy and manage load-balanced HTTP servers (on the
> contrary, I find them more transparent than FastCGI), but clearly this
> is going to be a matter of personal preference and experience.
>
> Regards,
> Cliff
>
> --
> http://www.google.com/search?q=vonage+sucks
>
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx
>

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