At the 2012 Esri Developer Summit, we gave two talks on building real-time apps – the first used Node.js and Socket.io, and persisted the data to a feature service. The second used ASP.NET MVC and SignalR, and stored the data points in a simple SQL table with x,y values.
During the talks we invited the ~100 people in the room to beat up the apps, and here’s what we found.
First – both services withstood the inbound load without issue.
Node.js and Socket.io
Demo site: http://node.dtsagile.com
This was running on an AWS Micro-Instance, and there were no issues handling the load. Over the 4 hours from when we opened it up, 999 points were added to the system.
In the first 10 minutes, 780 points were added, and looking at the timestamps we had several points where there were 10, 12 15 points added per-second. Not bad for a wee little instance! Here’s a screen cap from Brian Noyle’s phone after the session was over. Down to 3 users, but you can see all the points stacked up.
What we did find is that once there were a lot of points, the system hit a snag querying them back out and sending them to the clients. Although we could have had the clients query the ArcGIS Server FeatureService directly, part of the experiment was to do that work in Node, and then push the features to the client. This all worked smoothly except the FeatureService got slower as the number of points went up (we are still looking at why this is), and the timeout in the Node xhr request was set to be 1 second. Thus, the request timed out, and newly connecting clients did not get the “current” crop of points. Newly added points worked just fine.
At this point things are working smoothly again – and that’s because the query only pulls points added in the last 24 hours, and there are very few points added on any given day. I have not had any time to replicate the issue, but I expect that extending the timeout would fix things. A better idea would be to cache the data in something like Redis, and then lazy-write it into a geodatabase or feature service – maybe there would be a second or so lag between the two, but I think the user experience would be better.
code: https://github.com/dtsagile/dmg-express
ASP.NET MVC and SignalR
Demo site: http://signalr.dtsagile.com
This was running on a server in our Fort Collins office, and although overloaded, it’s a pretty powerful box, so there were no issues with the load. Over the first 4 hours, 536 points were added to the system. In the first 10 minutes, 426 were entered, with a peak of 5 per second. We can’t compare this directly to the numbers for node as there is now way to tell if more or less people were entering data. However, we can safely say that the server easily handled this load.
This version of the app simply stored the points in a SQL table with x,y values, and interestingly there was no issue with scaling this up – mainly because there was no xhr in the mix to time out, and because direct sql access is much faster than going through a feature service, which then hits the database.
code: https://github.com/dtsagile/dmg-signalr
Videos of the Talks
We recorded screencasts of the talks as we gave them, and they are now up at Vimeo.
**Node & Socket.IO: http://vimeo.com/dtsgis/realtime-node
SignalR & ASP.NET MVC: http://vimeo.com/dtsgis/realtime-signalr