Wouldn't Soylent eventually add some flavouring to make it less utilitarian/boring? It's still the first version of the product and it seems that the author doesn't even consider the possibility that there would be variations of the powder for variety and different taste preferences in the future. Does anyone know if they ever stated anywhere that the taste won't change?
I tried using faye and it died very quickly under load with the redis backend. For every message that you send it queues it up into a redis list for each faye server in the cluster to read which doesn't scale very well in their very chatty redis queue system.
I would do significant load testing for each use case before using it (or socket.io for that matter). I needed to push 30-50 messages per second to each connected client and faye started choking as soon as there were more than 20-30 clients. socket.io would choke at around 50-100 connected clients. Raw websockets were able to reach closer to 100 clients but performed more or less similar to socket.io.
That's an incredibly high rate of messages. What could you possibly need that many messages for? I'm in no way surprised that generic solutions don't work for your case.
We kept the design simple, otherwise a "batching" mechanism could be introduced that would replay a single batch of 50 messages but that would make everything a second delayed. However, part of the map allows you to login and see your messages live on the screen as you're sending them to your partner and for that the real time streaming is pretty critical.
It looks like you're sending the same data to every client, but it sounds like Socket.IO/Faye aren't handling this well. Do they not have a `broadcast` method of something of that nature that handles your use-case?
Sticky load balancing was a deal breaker for us when we built the https://map.couple.me visualization with socket.io. At the last minute I just pulled older browser support and left it with raw websockets instead of socket.io because the cluser module couldn't be used otherwise.
We had two issues with sticky load balancing:
1. AWS ELB had to run in TCP mode (for websockets) which meant no stickiness
2. Within each instance we have a node-cluster running to utilize multiple CPUs and putting haproxy with stickiness there increased complexity
We could avoid using the ELB but then you lose the ability to use an EC2 Auto Scaling group, introducing significant admin overhead.
Ultimately we didn't need the nodes communicating between each other (it's a one way stream from us to the client) so raw websockets ended up being the simplest solution.
Good catch! There is a small variation depending on the server that you hit but the variation should never be more than 1,000 messages. It's just a side effect of how we're scaling the system.
It's the geographic center of Canada, that's the coordinate that the geo-ip database gives us back when no specific city is available. Works well for smaller countries, but in Canada it's quite visibly "off" :)
I have this gripe with mapping in general - area of uncertainty doesn't seem to be plumbed well. The assumption that everything is a point seems to permeate everything.
I do know that Alice Springs exists, but it's an error in the Geo IP database they are using rather than true data. That's where the general hand-waving "australia" marker is placed when they don't know more than the country of allocation. There's a huge disparity between the number of people that live in NT and in other states, so the large number of results "coming from" there is telling in itself.
That's pretty much exactly what's happening with some locations. We do our best to get an accurate location based on a few sources, but ultimately Maxmind is the database we fall back to for pure IP based location if that's all we have.
We have the same difficulties with our Maxmind IP database. An inordinate number of our users supposedly live in Potwin, KS, AKA the geographical center of the United States.
We're planning to do a larger tech focused write-up on this infographic soon. On the backend it's powered by Node and Redis and runs within an EC2 auto scaling group.
Let me know if I can elaborate on any of the tech behind this visualization.
Those data points appear as circular flashes without a line, there are quite a few of them there. The app appeals to a lot of long distance Couples so the map is somewhat biased towards long distance communication.
Also if you look at big cities (LA, NYC, SF) you'll see a continuous stream of circles flashing without lines. So the data just overlaps a lot.
We're planning to do a larger tech focused write-up on this infographic soon. On the backend it's powered by Node and Redis and runs within an EC2 auto scaling group.
Keep in mind that you have to run this with OpenSSL v1.0.1 and above. Running it on a stock OS X Mavericks install will not detect the extension because v0.9.8 of OpenSSL is installed.
