Application data caching using SSDs

http://techblog.netflix.com/2016/05/application-data-caching-using-ssds.html

by sgmansfield • 10 years ago

107 28 10 years ago

techblog.netflix.com

pmontra2• 10 years ago

The link redirects to a https URL that doesn't work (Firefox and Opera). I'm not using a https anywhere addon so I was very surprised that wget http://techblog.netflix.com/2016/05/application-data-caching... doesn't get redirected. Loading the downloaded file in the browser let me read the article.

sgmansfield3• 10 years ago

Sorry, not sure what's wrong. I tested in the latest firefox, safari, opera, and chrome and it works for me.

Edit: blogger doesn't do SSL on custom domains. Sorry =/

notnarb• 10 years ago

the http:// link you posted works fine, but if you attempt to access the link via https ( https://techblog.netflix.com/2016/05/application-data-cachin... ), I get a "Secure Connection Failed" in Firefox.

Screenshot:

http://storage8.static.itmages.com/i/16/0525/h_1464199626_32...

That said, I'm not being redirected and I don't know why gp is.

ademarre• 10 years ago

Works for me, but is it possible there was an incorrect HSTS configuration at some point? Possibly even the parent domain with includeSubdomains.

takeda• 10 years ago

Are you sure you don't have an extension installed that changes http requests to https?

The https is broken on that site.

geodel5• 10 years ago

The decision to use Go was deliberate, because we needed something that had lower latency than Java (where garbage collection pauses are an issue) and is more productive for developers than C, while also handling tens of thousands of client connections. Go fits this space well.

This is interesting. There haven't been many instances yet where Go's memory/GC performance is compared directly and favorably to Java's performance.

gshulegaard2• 10 years ago

I think the bigger thing is the deliberate design of go for parallel processing. I feel like the Go GC is still an issue, although getting better every day, but the benefits in regards to "handling tens of thousands of client connections" potentially make the GC easier to swallow than Java.

But that's is just my outside looking in take on it.

geodel5• 10 years ago

If you check this link: http://benchmarksgame.alioth.debian.org/u64q/go.html

Java uses about 2-10 times more memory most of time compare to Go. So I'd think Java's GC has to be at least 10 times better/sophisticated than Go's. Though I doubt if it is really 10 times better.

gohrt• 10 years ago

https://blog.golang.org/concurrency-is-not-parallelism

faizshah7• 10 years ago

In this case I don't think it's the raw performance they are looking for but rather freedom from the unpredictable GC pauses. Although I think they should have explained why they didn't use Azul Zing for this, I realize it's expensive but this seems like the exact use case for it.

Found some interesting discussion here about this: https://news.ycombinator.com/item?id=10149961

geodel5• 10 years ago

Zing needs heavily over provisioned machines like 64+ GB RAM to make those GC guarantees.

duaneb• 10 years ago

Although I think they should have explained why they didn't use Azul Zing for this, I realize it's expensive but this seems like the exact use case for it.

Azul Zing is extremely expensive for commodity hardware; that's a massive price-tag for just the lower latency constraint. Their pricing model is a much better fit for vertically-scaled services, though they even argue that it can lead to reduced costs on horizontally scaled services, presumably on the assumption that you can use fewer hardware instances at peak to handle latency guarantees:

With Zing, Azul has created the most scalable Java Virtual Machine (JVM) for enterprise workloads and made it available on cost-efficient commodity hardware. With Zing, enterprises can now dramatically simplify Java deployments by using fewer instances while achieving greater response time consistency under load and dramatically lowering operating costs.

- https://www.azul.com/products/zing/zinqfaq/#importance-produ...

Somehow, I don't see a cache solution working well with this pricing model. The underlying operations are presumably simple enough you can get the performance you want with thin, simple software deployed on many commodity machines.

sgmansfield3• 10 years ago

Author here (of both Rend and the post).

We really are looking for raw performance, but not at any cost. I spent a bunch of time, and continue to do so, to eliminate extra work, indirection, and garbage.

Efficiency of runtime and development is a careful balance that Go fits well. Rust is immature. C is difficult for people who haven't been writing it professionally. Java (less Zing or other special cases) is too latent, even if it's very fast when it's running because of HotSpot optimizations. The list goes on, but I didn't see a reason to choose the others over Go, nor have I found something yet that beats it for our use case.

Really, Java just wasn't the language for the job. Go has a lower level and simpler interface, simpler runtime (with less indirection), and better model for concurrency. Yes, it's a new language for us, but it was the right tool for the job. Our garbage collection pauses are mostly under a millisecond, so they aren't really an issue.

Zing never really was on my radar. Looking at it now I shudder to think of the licensing costs, especially since we run tens of thousands of cache instances. We already pay enough just to run these servers. It's also a new Java runtime which very few people know about, and probably nobody at Netflix has used. I would have had to learn it all independently and continue to be on my own from then on. The Go slack team and community in general are very helpful and supportive, and I would speculate that the same level of support isn't available for Zing without paying.

Application data caching using SSDs

Related Stories