These are my notes from More Realtime, a talk by Daniel Shaw given on July 2, 2012 at NodeConf. You can follow Daniel on twitter @dshaw or on github: http://github.com/dshaw
There's more and more talk about deploying socket.io in production and 1.0 will make that more reliable and more resilient. I'm at Voxer right now, but not really going to talk too much about that today; I'm going to talk more about historical stuff on socket.io in realtime.
Socket.io RedisStore is awesome. You know what's cooler than one process or a cluster of processes? A cluster of servers where I can bring to bear 20,000 users. I was working at a startup that was using socket.io to do real-time video, and we needed to be able to support media stars who would come and interact with the service, and we needed to be able to deploy thousands and thousands of users at the same time to a single event, managed by socket.io.
Store is kind of an artifact of Express, and there's a simple key/value store. Use that; don't attach it to the socket object. You'll benefit from using the abstraction even if you're hacking on things in memory when you deploy to production and you're able to use an external store.
The real sexy part of RedisStore is the pub/sub inter-process dispatch that is facilitated with Redis PubSub in the background. When you emit an event to your connected users, anybody who is subscribed to a particular room or event will receive it, whatever server they are attached to.
The problem with RedisStore up until now, is that you're basically on your own. Once in a while people come to the socket.io list and ask "How the hell do I do this?" Today, we're releasing documentation with some production tips. Go hit that up and find info on how to use it.
Traditional socket.io is tied to a web server. That applies to the old school: Express + Socket.io as it does to the newest such as Tako. But your apps are so much more! With Socket.io-Announce you can tie your app to something way back in your DMZ or a stream of stock quotes coming off a wire somewhere deep in your architecture.
This is a cool new thing I'm releasing today. Redis is awesome. It's a great architectural fit for node. It just makes node work. A couple weeks ago there was a project that made the rounds on HN called RedisLive. It provides a level of visibility into what your Redis server is actually doing. But, it's bad. We could never deploy this. If you go to the Redis website and look up monitor, there's details that say that if you're running Monitor you could be cutting your I/O by up to 50%. We're already maxing out our Redis processes; we just can't do that. Monitor can't come into a real production equation.
But, a lot of the information that's exposed that's actually interesting is available through a command called info. Redis Monitor allows you to send very small deltas of information over the wire. I think you'll find it really useful without abusing your Redis server, because Redis is essential to our mix and doing less of it sucks.