Multi-user real-time heatmaps – a possible approach
What is this article about?
Please keep in mind that my experiment is still no product, I cut off some essential things such as storing or managing the heatmap data on the serverside to reduce the effort. The demo is in alpha mode; if anything doesn’t work please drop me a comment, I’ll fix it as soon as possible.
Due to some performance issues and low resources on my server there are some limitations to the demo:
– A heatmap represents a channel. The maximum amount of users in a channel is 5.
– There are about 100 channels available (auto cleanup)
– I haven’t tested the demo with a huge amount of connected users yet, I’m sorry if my server isn’t able to handle it.
Have a look at it right here: Multi-user real-time heatmap
I’m sorry if there is no slot available for you, you may want to try the demo in a few minutes or days again ;-)
My thoughts and concept
Well, I wanted to push my heatmap example some steps further and thought about some of the latest technologies and how I could combine them for a more useful approach on a real-time heatmap. (the heatmap data is still not saved on the serverside, so if you expect a full working heatmap product this is probably the wrong place for you).
Ajax Push Engine as message oriented middleware
Web workers for cooling the heatmap down
As mentioned before, the cooldown process is resource-intensive, therefore I thought about doing it with web workers. The worker script contains the coloring function but the color information is recalculated for the whole heatmap with the addition that every alpha value gets decreased by a defined value. The coolDown function just works in Firefox, when I try to execute the Web Worker in Safari or Chrome I get a “Error: SECURITY_ERR: DOM Exception 18”, couldn’t figure out what the problem is.
Further required architectural redesign
The most important architectural improvement on the heatmap script was the function-queue. Instead of drawing the alpha gradients when the mousemove events fire, the new logic alpha drawing functions get pushed with its coordinates to the queue. The script permanently iterates through the queue and removes the functions after their execution.
Why is this the most important improvement?
It’s important because when the script communicates with APE and is constantly receiveing messages for drawing new coordinates it should not affect the drawing process of other messages. The drawing process manipulates a rectangle of pixels, if the script wasn’t executing the functions simultaneously, the rectangles could overlap and use wrong data for the calculation. (e.g. a function should increment a counter, start value is 0. The first function call increments the counter, but the second function call has the data from before the first function execution was done -> counter is 1 instead of 2)
The next step?
I wrote about storing and managing heatmap data in a data-matrix on the serverside in the description of my concept. I don’t know if this was a good concept for high performance in a multi-user real-time heatmap application and I didn’t try it because I haven’t had enough time, but if anybody wants to give it a shot I’d be open for support or hacking together. Just let me know