valyala/ybc

Is YBC production ready?

alexkoch01 opened this issue · 3 comments

Basically I am curious if anyone is using YBC in production?

@alexkoch01 I seriously intend to, but I still find the YBC application a bit vague on practical documentation, and without spending my time proofing and adapting something like this to a real production site, it is scary and hard to evaluate the plunge.

For me, it is the factor of unknown effort and compatibility with nginx, along with other known cache methods that already work well.

I do think YBC needs a write-up on methods.

I have been waiting for YBC to shift gears into a pragmatical eval and case thesis.

@peterbowey I find the documentation to be good enough. It claims to handle 2^64 items, I don't doubt it but I am curious about the performance implications of using this versus Varnish for example.

Is YBC production ready?

YBC library for Golang is used in an ad serving production system without any problems. The system consists of 20 servers. Each server has a couple of in-process caches based on YBC (each cache serves distinct purpose). Currently the busiest cache handles up to 5K 'Set' qps for values with 1-4Kb sizes and up to 50 'Get' qps on a single server.
Though these qps numbers are tiny for YBC - according to artificial performance tests, it is able to handle more than 3M qps in Golang and more than 20M qps in C.

For me, it is the factor of unknown effort and compatibility with nginx, along with other known cache methods that already work well.

Do you mean go-cdn-booster under 'compatibility with nginx'? Go-cdn-booster is a PoC on how to write simple, fast and efficient http caching proxy in Golang. Its' performance is behind (but close to) nginx's performance, but, contrary to nginx, you can easily implement custom logic in Go instead of writing low-level error-prone code in C for nginx :)

I do think YBC needs a write-up on methods.

I have such a feeling when reading docs on http://godoc.org/github.com/valyala/ybc/bindings/go/ybc too. These docs should be definitely improved in the future.