For the case of redis, just some custom scripts built to test it for our use case. In this case, two things were tested: doing large batches of random writes of pixels onto the board and doing reads of the full canvas. That was what led to us realizing reads actually would be a huge hit to our performance since we were network-bound on the instances and 1 read of the board per second would cost us thousands of writes per second, since updating a pixel is <~20 bytes and reading the full board is 500KB.

I think it theoretically would be fine, since we were way overoptimizing for the write rate we ended up getting (I wanted to support one pixel per user per 10 seconds, even though I knew we'd probably never go down that low), but I was also concerned that there would be some event that would cause all users to refresh and request the board at the same time -- a thundering herd that would saturate redis's network throughput. This is what led us down the road of caching. I suspect people were refreshing a lot during the websockets issues, so this was probably a life-saver.

Edit: For cassandra, we already have a good sense of how much read and write capacity we can handle. The only load testing that was done there was in completely filling a board and trying to load a canvas. I think the article mentions it, but that's when we saw it took way too long to load and fully made the decision to go with redis for the board. We also did some napkin math of how much storage space storing pixel info would use and found it was relatively small compared to the rest of reddit.com, so we still used it for that.