Hacker News Reader

Comment by matthewmacleod | Hacker News Reader

I wonder if I'm missing the point here, but why are Redis or Memcached—implementations of exactly this service which are battle-tested and well-used—not suitable due to "additional time needed on the network", but this service is suitable? Is it just down to the requirement for a HTTP API?

One thing I've noticed is an extreme demand for making internal services available over HTTP. It has it's benefits, but the obvious downsides are the overhead and complexity of HTTP being totally overkill for things like a key-value store of this nature.

View on HN

I had to read the relevant sections three times to sort this out. I believe what they are saying is that this service they made had to speak HTTP in some specific way, and since Redis doesn't speak that way directly they would have needed to proxy requests in their service to Redis which would mean one network hop to reach their HTTP service plus one hop to reach Redis.

Of course, Redis and Memcached support Unix domain sockets which do not use the network and do not suffer from the overhead of TCP. The authors do not address this at all, suggesting they weren't aware of UDS, nor the fact that TCP within one Linux host does not touch the network at all.

Adding to the confusion is that even given an in-memory cache library which overcame their objections to the "network" based ones, they still elected to write their own low-level cache.

So the comment about time needed on the network was either spurious or misinformed. And one thing it was not: measured.

Quoting redis docs (http://redis.io/topics/benchmarks):

> When the server and client benchmark programs run on the same box, both the TCP/IP loopback and unix domain sockets can be used. Depending on the platform, unix domain sockets can achieve around 50% more throughput than the TCP/IP loopback (on Linux for instance). The default behavior of redis-benchmark is to use the TCP/IP loopback.

Haven't measured myself though.

I was wondering the same. I.e., how this might compare to an NGINX module talking to a caching process on a unix socket.

https://github.com/openresty/memc-nginx-module

https://github.com/openresty/redis2-nginx-module

This has the added benefit of being able to take advantage of other nginx features. For example, you could set different permissions on `set` and `get` routes.

Agreed. Redis is much faster out of the box with minimal tuning than this solution.

I was wondering about the same

Reply on news.ycombinator.com