Realtime web2012

  • View

  • Download

Embed Size (px)

Text of Realtime web2012

  • 1.Building Real-Time Web http:// Timothy Fitz .com CTO Canvas

2. What is Realtime web 3. What does Realtime look like? 4. What does Realtime look like? 5. What does Realtime look like? 6. Push, not pull.REALTIME WEB 7. Talking to the browserHigh concurrencyScaling up3 HARD PROBLEMS 8. Talking to the browser Short Polling Long Polling WebSocket Flash Socket 9. Short Polling 10. Long Polling 11. Flash Socket 12. WebSocket 13. High Concurrency Blocking I/O Thread per process Tops out at 200 to 1k connections Non-blocking I/O One process, one thread 10k to 100k connections 14. Django 15. Django Apache 16. There is no apache for realtime 17. Non-blocking I/O Servers Python Twisted Tornado gevent Not python Node.js Erlang something 18. Twisted Pro Can talk every protocol ever Oldest and most widely used in production Con Overkill for web-only tasks Not simple 19. Tornado Pro Simple Does HTTP stuff simply Con Might not interface with what you need Confusing You can run Tornado (HTTP layer) on top ofTwisted (networking layer) 20. gevent Pro Coroutines are a better model than callbacks As such, very easy to write complicated logic Con Least well documented Least consensus on best practices New, uncertain about production readiness 21. Node.js Pro Best documentation by far Socket.IO abstracts away browser communication Con Cant share logic between Django app New, but has fairly large install base 22. Erlang Pro Hands down best for complex realtime tasks Forces you to think about concurrency/scale Abstracts away the network Old and reliable Con Forces you to think about concurrency/scale Cant share logic between Django app High spin-up cost (functional, concurrency driven) 23. Just oneFrontend nodes x Backend nodesMore architecture decisions!SCALING UP! 24. Just one Everything in memory Django nodes talk directly to box Spare for availability Failover = realtime data loss Make realtime 100% redundant 25. Probably good enough! WARNING: NAPKIN MATH 10k daily visits * 10.0min avg visit= 70 average concurrent users One box can easily be built out to handle 3-5k= Roughly 450k-700k daily visits 26. Frontend nodes x Backend nodes Frontend handle users / connections Backend handles channels 27. More architecture decisions! In memory backend Redis Pub/Sub ZeroMQ Roll your own Persisted to Disk: ActiveMQ RabbitMQ Amazon SQS 28. Redis Pub/Sub Simplest to setup Simplest model SUBSCRIBE channel_name PUBLISH channel_name Hello World! 29. ZeroMQ Publish/Subscribe semantics Request/Response Push/Pull (round robin) Extremely fast 30. Roll your own Same language as your frontend (Twisted/Node/Whatever) Only do this if you have per-channel businesslogic You probably dont. Erlang maps really really well to this domain. 31. Full Stack Services REST APIs to push to the browser 32. CanvasAmazon ELB Nginx + Twisted Redis 33. Final Recommendations Need python? Twisted Dont? Node.js/SocketIO Need scale/reliability? Redis backend. Complex? Going big? Erlang all the way. 34. Questions? 35. Further Reading IMVU IMQ talk Twilio talk on gevent + zeromq (given by Jeff Lindsay, highly recomended): scaling Eralng/Mochiweb to 1 million concurrent connections onone machine: The original Comet blog post: Django + Socket.IO + gevent: