2. How we got here
The web started with the idea of sharing complex
documents.
Web 1.0 sites are limited by how quickly the user
can read
Performance was solved by caching and distributing
the load
4. Social Breakdown
Most people realized that the traditional model was breaking
down with social sites, although anyone needing frequent
updates was affected
The workload breaks many assumptions: frequent updates
visible to arbitrary subsets of users, with latency being a big
deal
Traditional coping strategies fail:
Content can't be cached
Heavy interdependencies complicate scaling wide
Visibility logic can be complex
5. Changing the model
Comet: long-lived request "pushing" data as it's generated
<script>chat.addMessage("foo");</script>
… time passes …
<script>chat.addMessage(";)");</script>
… or long polling:
GET /ajax/chat
… time passes …
{messages: ["lol"], highwater: 12345}
GET /ajax/chat?i=12345
6. Asynchronous I/O
Handling scale just become mandatory and that requires
switching to an event-driven back-end to match the event-
driven clients
Completely different model - but very familiar to JavaScript
devs or people with desktop experience:
(from http://www.tornadoweb.org/documentation#non-blocking-asynchronous-requests)
7. Tornado
Tornado is the opensourced technology behind friendfeed.
com (now Facebook)
Targetted at the problem of building high-performance,
scalable web applications:
Templating, reusable widgets, localization
Signed Cookies
Authenticates against common services (Google,
Twitter, Facebook, etc.)
Fast:
8. Caveats & Future Directions
Bad News:
Targeted is another way of saying limited
Blocking APIs are hard to avoid - you'll probably need
architectural changes to deal with databases, files, other
web services, etc.
Good News:
Asynchronous I/O is becoming very common
Twisted is finally getting some usability attention
HTML 5's WebSocket will clean up long-lived connections
