Hacker News Reader

Comment by jpeterson | Hacker News Reader

Not this stuff again. Yes, basically any service you can think of can be implemented trivially, if you don't have to worry about things like concurrency, performance, scalability, etc.

This might have been a nice learning experience for the author, but it's definitely not hacker news.

View on HN

As the author, I agree. As I explicitly wrote in the README, I didn't find this project interesting and didn't think it'd be very useful for anyone in particular. Kiln ships with both a licensed on-site version, and a SaaS version. The SaaS version uses Redis as the backing for a small, easy-to-use queuing system. It was less work to write a tiny little clone of the parts of Redis the queuing system used than to write an entirely different pile of logic for Windows.

I think MiniRedis does what it needs to do well, but I was surprised to see it reasonably high on the HN page. I think there are probably more deserving projects out there.

The code handles concurrency the same way that redis handles concurrency. It's single threaded.

Redis 2 is multithreaded. The weird thing for me is that MiniRedis is 1/4th the speed of Redis 2 (using redis-bench, included with Redis 2, to measure), which means that being both single-threaded and written in a relatively slow scripting language didn't hurt performance that much. I haven't taken the time to figure out why; I thought Redis would be much faster.

Because Redis is in part I/O bound, this is why Redis 2.0, and even more Redis 2.2 (currently git master) are using the spare CPU in order to use less memory, with specially encoding for small lists, sets, hashes.

Btw 25% the speed means a lot slower :) My guess was that the difference for small keys that the redis-benchmark is stressing would be smaller.

I think that with big lists or using the SORT command the difference will be bigger.

Cheers, Salvatore

Reply on news.ycombinator.com