3 ms·

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

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 https://news.ycombinator.com/item?id=10149961

geodel 10y ago
Zing needs heavily over provisioned machines like 64+ GB RAM to make those GC guarantees.
- faizshah 10y ago
  Can you provide a source? I haven't used Zing (only read about it) but my understanding is that it should work for low memory and high memory JVMs.
  - geodel 10y ago
    I got a pdf link in a google search sometime back. That document mentions that. You should try searching.
    - faizshah 10y ago
      I ask because the pdf you're probably referring to seems to imply the opposite. I only skimmed though but heres what I found that seems to imply the opposite: "An entire Java heap (large or small) can be marked consistently without falling behind and resorting to long garbage collection pauses because the C4 employs: • Single pass completion to avoid the possibility of applications changing references faster than the mark phase can revisit them • “Self-healing” traps that ensure a finite workload and avoid unnecessary overhead • Parallel marking threads to provide scalability that can support large applications and large dataset sizes" Maybe I'm looking at the wrong pdf can you provide a source for your claim? It's something useful to know if it's true.
      - geodel 10y ago
        I am hesitant to post direct link as document says 'Confidential and Proprietary'. But here is something in that doc about memory requirement `The Zing components require the following amount of RAM on the ZVM machine. l 64+ GB RAM recommended 16-32 GB RAM minimum, depending on the application memory requirements, for demonstration purposes only. Minimum is not sufficient for performance or scalability production testing of large or memory consuming enterprise applications. Increase the memory as needed to accommodate the number and size of your Java application/Zing Virtual Machine (ZVM) instances. The Pool license server requires the following amount of RAM on the license server machine. l 8 GB RAM recommended (4 GB minimum)` This document is like 300+ pages with all the details about tuning and optimizations which make me think that it is not simple plug and play once you have paid for license.
        faizshah 10y ago
        Ah I see the document now, thanks. Based on this it seems like Zing is only a good solution for vertically scaling software. Now it makes sense why it's priced at 3500 per machine.
duaneb 10y 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-product 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.
- faizshah 10y ago
  Good points, I agree. It seems they're probably going for finance with that pricing model.
sgmansfield 10y 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.
- faizshah 10y ago
  Cool, thanks for the insight! I love reading the thinking process behind design decisions. On the subject of Azul's price: I think they would give you a high volume discount, but even half the price (1750) per server would be pretty outrageous for your use case. For my use case I'm going with Apache Ignite right now for tiered off heap caching, but I'm not sure it would work for you guys. Might be worth a look though. I admire Netflix OSS ecosystem. Thanks for the great work you guys do!
  - desdiv 10y ago
    Just curious, is that 3500 per server per year? Or 3500 for the lifetime of the server?

geodel 10y ago

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

faizshah 10y ago
Can you provide a source? I haven't used Zing (only read about it) but my understanding is that it should work for low memory and high memory JVMs.
- geodel 10y ago
  I got a pdf link in a google search sometime back. That document mentions that. You should try searching.
  - faizshah 10y ago
    I ask because the pdf you're probably referring to seems to imply the opposite. I only skimmed though but heres what I found that seems to imply the opposite: "An entire Java heap (large or small) can be marked consistently without falling behind and resorting to long garbage collection pauses because the C4 employs: • Single pass completion to avoid the possibility of applications changing references faster than the mark phase can revisit them • “Self-healing” traps that ensure a finite workload and avoid unnecessary overhead • Parallel marking threads to provide scalability that can support large applications and large dataset sizes" Maybe I'm looking at the wrong pdf can you provide a source for your claim? It's something useful to know if it's true.
    - geodel 10y ago
      I am hesitant to post direct link as document says 'Confidential and Proprietary'. But here is something in that doc about memory requirement `The Zing components require the following amount of RAM on the ZVM machine. l 64+ GB RAM recommended 16-32 GB RAM minimum, depending on the application memory requirements, for demonstration purposes only. Minimum is not sufficient for performance or scalability production testing of large or memory consuming enterprise applications. Increase the memory as needed to accommodate the number and size of your Java application/Zing Virtual Machine (ZVM) instances. The Pool license server requires the following amount of RAM on the license server machine. l 8 GB RAM recommended (4 GB minimum)` This document is like 300+ pages with all the details about tuning and optimizations which make me think that it is not simple plug and play once you have paid for license.
      - faizshah 10y ago
        Ah I see the document now, thanks. Based on this it seems like Zing is only a good solution for vertically scaling software. Now it makes sense why it's priced at 3500 per machine.

duaneb 10y 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-product 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.

faizshah 10y ago
Good points, I agree. It seems they're probably going for finance with that pricing model.

sgmansfield 10y 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.

faizshah 10y ago
Cool, thanks for the insight! I love reading the thinking process behind design decisions. On the subject of Azul's price: I think they would give you a high volume discount, but even half the price (1750) per server would be pretty outrageous for your use case. For my use case I'm going with Apache Ignite right now for tiered off heap caching, but I'm not sure it would work for you guys. Might be worth a look though. I admire Netflix OSS ecosystem. Thanks for the great work you guys do!
- desdiv 10y ago
  Just curious, is that 3500 per server per year? Or 3500 for the lifetime of the server?