Slashdot Mirror
Facebook Releases Open Source Web Server
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."
Facebook was built with PHP?.
I posted this news first, but it seems somebody else got it on the front page :/
http://slashdot.org/firehose.pl?op=view&id=5864125
Here, have a cookie...
"Thats not IRONY chumps & chumpettes, its just coincidental".
Tornado includes both a Web server and a Web framework. The framework can take advantage of the (non-blocking) server architecture to achieve high performance. Apparently you can also run it under mod_wsgi, but I can't really see an advantage of using it in that scenario when compared to other Python frameworks.
I wonder if the Tornado authors set forth to re-implemented Twisted Python just for kicks or out of not knowning about its existence.
Twisted supports epoll kqueue, win32 iocp, select, etc.
Lone Gunmen crew.
Twisted is hard to learn. It's the sort of thing that programmers will re-implement just to avoid reading the documentation.
Or maybe they wanted to have control. Whatever the case, they would have know. Everybody (who uses python for web work) would know a bit about Twisted ... it's on the front page of python.org
It's just coincidental!
If this webserver is supposed to be fast, than just how fast is it? Is it faster than lighttpd? YAWS? I'd like to know.
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.
I don't know, Java, C++ and python all run at fine speeds if you write proper code for the language. C++ is probably the fastest in most cases, but Java is going to be a real close second written properly and on the right VM. While I don't like python myself, theres a reason it gets used in games, it can perform well enough to be used extensively if you can deal with compile time, which wouldn't really matter for long running process like a web server.
Perl isn't HORRIBLE, again, startup time is its biggest problem. PHP has issues, but when zend, precompiling and caching again, it works better than most expect.
I know nothing at all of Erlang so I won't speak to it.
MySQL is known for being fast as hell under the right workload, just gotta use it the right way.
Mix in some memcached and you can server a lot of hits.
Considering the number of extremely high traffic websites that use a mix of software about like this one, I think you'd have to be pretty stupid to put the blame on the software thats used.
Do you run a server farm that gets more traffic than Wikipedia, Yahoo or MySpace? I'll talk some shit about languages and say that everything should be written in C at the highest, by proper programmers so we don't end up with OSes that need gigs of ram to boot ... but ...
While possible, even I'm not arrogant enough to call them stupid.
I don't find anything about Wikipedia's setup 'impressive', but its certainly done properly. Their mix of php, python and mysql is all used exactly as is should be and serves a massive amount of people on a relatively low amount of processing power.
But again ... stupid? No, they are hardly stupid.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
~ C.
~ C.
They explicitly states that they looked at Twisted and chose to write something more user-friendly. Having looked at Twisted (3-4 years ago though) and at Tornado's samples and benchmarks I think they succeeded. Twisted seems to be going the way of Zope: an interesting platform that did everything its own way and shut itself out from the rest of the Python universe, eventually losing relevancy.
I think a Tornado/Django mashup (Tornado infrastructure, Django front-end/application bootstrapping) would be realllly interesting....
Bret Taylor says:
When we started, we did use Twisted. In practice, I found Twisted tedious. The deferred abstraction works, but I didn't love it in practice. Likewise, the HTTP/web support in Twisted is very chaotic (see http://twistedmatrix.com/trac/wiki/WebDevelopment ... - even they acknowledge this). In general, it seems like Twisted is full of demo-quality stuff, but most of the protocols have tons of bugs.
Given all those factors, it didn't seem to provide a lot of value. Our core I/O loop is actually pretty small and simple, and I think resulted in fewer bugs than would have come up if we had used Twisted.
True, you can. But Facebook is at the forefront, the bleeding edge. They're doing stuff that nobody else is doing yet. So it'd be more like complaining about a surgeon killing a patient during a procedure that no one has ever tried before, like a heart transplant in 1973. And they do successfully serve most of their customers. I'm no facebook fanboy, I'm just saying they are pushing the limits, and also doing what they can to advance the technology.