Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Dan Jones writes "Ah the irony. The week Facebook is being asked to cough up source code to satisfy an alleged patent infringement, the company releases an open source Web server. The Web server framework that Facebook will offer as open source is called Tornado, was written in the Python language and is designed for quickly processing thousands of simultaneous connections. Tornado is a core piece of infrastructure that powers FriendFeed's real-time functionality, which Facebook maintains. While Tornado is similar to existing Web-frameworks in Python, it focuses on speed and handling large amounts of simultaneous traffic."

Most Python web servers use threading or multiple processes to handle concurrent requests and are not implemented as event driven systems. Most Python web applications are not designed to be implemented on event driven systems but rely on the ability to block during handling of web requests, something which the former allows but which doesn't work well with event driven systems as it blocks the main event loop and prevents anything else happening. So, it is not similar to other Python web servers or frameworks.

It should be further highlighted that WSGI for Python is effectively designed for that blocking model and it isn't really a good idea to be using it with a server based on event driven systems model and which uses multiple processes as well. Attempting to do so can have undesirable effects such as described in 'http://blog.dscpl.com.au/2009/05/blocking-requests-and-nginx-version-of.html'. Some seem to hope that WSGI 2.0 will support asynchronous systems but reality is that it almost definitely will not, so they should stop dreaming.

So, although these sorts of high performance servers are interesting, their applicability to most existing Python web applications is limited because in practice the web application has to be designed around the event driven system model and you can't really use standardised Python WSGI interface and components that build on that.

This doesn't mean that these type of servers aren't useful, they just aren't going to solve everyones problems and will principally remain a niche solution for things that need to main many long lived connections.

As to the benchmarks they give, it is very much just a pissing competition and nothing more. The bulk of web sites would never even handle enough hits to trouble the limits of the other hosting solutions they compare to. For larger sites, they are never going to use a single machine anyway, but use a cluster of machines to spread load and for redundancy. Yes, it may provide more head room for individual machines, but again we aren't talking about a situation which the majority would even have to deal with.

Actually, for tight loops, CPython (the main implementation) is a whopping 200x slower than C.

Reasons why tight loop speed doesn't matter:- This isn't the kernel. Tight loops don't occur much. If you're polling or spinlocking, stop it and go read up on select, or switch up to a high-performance async library like Twisted. If you're doing number-crunching, use things like comprehensions or multiprocessing.Pool.map to accelerate your math. (Or use both; the former gets a speed boost in implementation, while the latter is concurrent across multiple processors.)- Programs are usually not CPU-bound. Profilers tell all, really. Games are usually GPU-bound, unless they're written without a separate sound thread, in which case they get I/O-bound. Webservers are usually I/O-bound, and spend most of their time in select/epoll/etc. waiting for connections.- Implementations can and will get fast, eventually. Unladen Swallow is one thing being talked about, but PyPy is also worth mentioning. The former is a bunch of CPython improvments, the latter is a JIT Python interpreter that matches C code for tight loop speed.

I know this is not a popular idea with a lot of people, particularly those working in places where "OMG speed is critical," but Python's execution speed just doesn't matter compared to its readability and time/LOCs required to get up off the ground and running.

RTFM. Go to the linked homepage for Tornado in TFA and read the docs. It shows a comparison with Tornado running on nginx against other web frameworks such as Django. It also says in there tests it was approx. 4X faster. However, they admit their tests were not very scientific.