Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kafka Removing Zookeeper Dependency

confluent.io

Post reply on HN
Print view View original

141–150 of 183 posts

Re: Kafka Removing Zookeeper Dependency

#141

Post by ashtonkem »

apta wrote: post #132
gilbetron wrote: post #119

Earlier quoted context omitted.

Ok, you have a java app I want on my system, what are the steps I need to do? (I'm on Ubuntu 18.04)

You can ship the JVM with your app such that it's self-contained and system independent. Apps like IntelliJ already do this. And now with jlink, you can strip it down to make deployment sizes even smaller by only shipping the parts of the JVM that your app uses.

That’s the reasonable choice for consumer facing applications, yeah. For server applications it makes more sense to use something like Docker or a pre-built AMI.

For what I do “how do I get Java on the server” is much less difficult than making deployments quicker and more efficient, which is more a problem for our CI/CD harness and integration tests. Neither of which are Java specific per se.

Re: Kafka Removing Zookeeper Dependency

#142

Post by throwdbaaway »

bsaul wrote: post #98
elric wrote: post #91

Earlier quoted context omitted.

yum install java-latest-openjdk-headless There, you're done. Need fonts? Install fonts. Pain in the butt? Where?

And now you have a separate intermediate runtime layer between your code and the OS, with its own set of versions, patches, regression, bugs, backward compatibilities, etc. that may or may not have an impact on the code that you intend to deploy (or redeploy). Statically compiled binaries are undoubtedly a plus regarding deployment.

You do realize that golang statically compiled binaries contain the go runtime right? So, all the concerns that you mentioned are applicable to go as well, e.g. a golang app may be buggy when built with version X, while another golang app may have GC issue when built with version Y, and yet another golang app would be vulnerable unless rebuilt with version Z. [1][2][3]

Don't drink the Kool-Aid, golang is just a more opinionated and much less capable cousin of Java/JVM. And for many companies, that could be the right trade-off.

[1] https://groups.google.com/forum/m/#!topic/golang-announce/mV...

[2] https://groups.google.com/forum/m/#!topic/kubernetes-securit...

[3] https://groups.google.com/forum/m/#!topic/golang-announce/65...

Re: Kafka Removing Zookeeper Dependency

#143

Post by pjmlp »

gen220 wrote: post #102
pjmlp wrote: post #96

Earlier quoted context omitted.

Not really, after all most native code compilers have endless amount of configuration options as well, while Go still falls behind many use cases. Also I started to see a trend in books and blog posts regarding how to write Go code towards better performance, so it isn't a given that it excels at performance out of the box. All of which comes back to the original point that many times isn't the language, rather how i…

Go’s mission statement isn’t to be faster than Java or to replace java. Its to (1) compile faster (2) compile into single binaries with no dynamic links (3) natively support concurrency and parallelism with M:N routines:threads. Go will never replace Java for Android because (1) it doesn’t use a VM, so it would need to compile for every arch that android runs on (2) it would require a bug-compatible port of Android.…

Java on Android compiles to native code just like Go.

Google is writing Android from scratch, is it called Fuchsia and Go also doesn't get to play there.

The few parts that were written in Go are scheduled to be rewritten in C++ or Rust, with Dart being the main userspace language.

Re: Kafka Removing Zookeeper Dependency

#144

Post by apta »

agallego wrote: post #136
apta wrote: post #128

Earlier quoted context omitted.

It's known that golang optimizes for latency at the expense of throughput, and it doesn't give you the option to change this if your requirements change. This is the power of the JVM. In any case, the JVM now ships with ZGC, a low latency GC, and it may be worth running the benchmark with it. There's also another low latency GC in the works called Shenandoah.

We wrote it in c++ on top of seastar.io

Thanks for the info. It makes sense in that case. Though the JVM can be very performant when written properly, and especially now with ZGC, Valhalla, Panama, etc.

Re: Kafka Removing Zookeeper Dependency

#145

Post by StreamBright »

manigandham wrote: post #138
StreamBright wrote: post #137

Earlier quoted context omitted.

Which one is easier? Adding a few lines of GC configuration or rewriting a service in C++ using Seastar and binding processes to cores? What sort of performance measurement uses default configurations? What is even the point of not tuning the GC to your application workload? I have spent the last 15 years on running Java apps in production and to optimize for the p99 latency is really not that hard. Optimize p99.9999…

Easier for who? At some point, the architecture needs to change to overcome a fundamental limit. Developers take on that work to make the performance and operations easier for their users. Seastar is the foundation of Scylla, which shows that rewriting in C++ can deliver magnitudes more performance which is not possible by just tuning Cassandra on the JVM. In fact, Datastax has now copied the Scylla approach in Cassa…

>> Easier for who?

For any decent SRE out there.

>> magnitudes more performance which is not possible by just tuning Cassandra

Magnitudes?? Are you talking about the order of magnitude? You should read the ScyllaDB performance report first.

https://www.scylladb.com/product/benchmarks/aws-i3-metal-ben...

Avg. 99.9% Latency (ms): 9.9

vs.

Avg. 99.9% Latency (ms): 474.4

While there is no significant latency difference in lover percentile tiers. Where Scylla really shines is TCO. Some companies trade SRE time for license cost, some other companies tune GC.

Re: Kafka Removing Zookeeper Dependency

#146

Post by agallego »

StreamBright wrote: post #137
koffiezet wrote: post #92

Earlier quoted context omitted.

Just the fact that you have to ask all these things proves the point?

Which one is easier? Adding a few lines of GC configuration or rewriting a service in C++ using Seastar and binding processes to cores? What sort of performance measurement uses default configurations? What is even the point of not tuning the GC to your application workload? I have spent the last 15 years on running Java apps in production and to optimize for the p99 latency is really not that hard. Optimize p99.9999…

I understand tail latencies - https://www.youtube.com/watch?v=WdFYY3vEcxo - my prev open source project smf (https://github.com/smfrpc/smf) uses gill tene's HDR histogram. I think you have a very superficial understanding of seastar. It is not simply marketing, it is a suite of tools and techniques to build low latency software - Specifically for IO intensive apps. Glauber wrote a good into here https://www.scylladb.com/2018/06/12/scylla-leverages-control....

Seastar is a fundamentally different way of programming from what you mentioned above. Let me give you an example. Seastar takes all the memory up front - never gives it back to the operating system (you can control how much via -m2G, etc). This gives you deterministic allocation latency, is just incrementing a couple of pointers. Memory is split evenly across the number of cores and the way you communicate between cores is message passing - which means you explicitly tell which thread is allowed to read which inbox (similar to actors) - i wrote about it here in 2017 https://www.alexgallego.org/concurrency/smf/2017/12/16/futur...

The point of seastar is to not tune the GC for each application workload So to bring that up means that you missed the whole point of seastar. Instead the programmer explicitly reserves memory units for each subsystem - say 30% for the RPC, 20% for the app specific page-cache (since it's all DMA no kernel page cache), 20% for write-behinds, etc. (obviously in practice most of this is dynamic). It is not one dimension as suggested and not apples to oranges. it is apples to apples. You have a service, you connect your clients - unchanged - and one has better latency. that simple.

It may be your experience that when you download a bin kafka say 2.4.1 you change the GC settings but in a multi-tenant environment that's a moving target. Most enterprises I have talked to, just use the default script to startup kafka w.r.t gc memory settings. (they may change some writers settings, caching, etc)

At the end of the day there is no substitute for testing in your own app with your own firewall settings w/ your own hardware. The result should still give you 10x lower latency.

Re: Kafka Removing Zookeeper Dependency

#147

Post by agallego »

StreamBright wrote: post #145
manigandham wrote: post #138

Earlier quoted context omitted.

Easier for who? At some point, the architecture needs to change to overcome a fundamental limit. Developers take on that work to make the performance and operations easier for their users. Seastar is the foundation of Scylla, which shows that rewriting in C++ can deliver magnitudes more performance which is not possible by just tuning Cassandra on the JVM. In fact, Datastax has now copied the Scylla approach in Cassa…

>> Easier for who? For any decent SRE out there. >> magnitudes more performance which is not possible by just tuning Cassandra Magnitudes?? Are you talking about the order of magnitude? You should read the ScyllaDB performance report first. https://www.scylladb.com/product/benchmarks/aws-i3-metal-ben... Avg. 99.9% Latency (ms): 9.9 vs. Avg. 99.9% Latency (ms): 474.4 While there is no significant latency difference in…

who cares about lower percentage tiers in the world of big data? what does the p30 or 50 even matter at large scale?

See Gil Tene's talk on how not to measure latency.

https://www.youtube.com/watch?v=lJ8ydIuPFeU

What matters is what most of your customers will get - p99, p999, p9999, p100.

Re: Kafka Removing Zookeeper Dependency

#148

Post by agallego »

apta wrote: post #144
agallego wrote: post #136

Earlier quoted context omitted.

We wrote it in c++ on top of seastar.io

Thanks for the info. It makes sense in that case. Though the JVM can be very performant when written properly, and especially now with ZGC, Valhalla, Panama, etc.

ah yeah no doubt. I've read the recent gc code in the jvm tree. it's beautiful. We just had a ton years of experience with c++ and it was a good fit for seastar.io - this all came from me messing around with https://github.com/smfrpc/smf and seeing what one could do w/ DMA (no kernel page cache)

Re: Kafka Removing Zookeeper Dependency

#149

Post by femiagbabiaka »

Tsarbomb wrote: post #114
femiagbabiaka wrote: post #82

Earlier quoted context omitted.

It is a good faith argument — it’s literally the whole point. Native binaries bypass all of that.

Good luck when you need to deploy to a system with a different version of libc.

goalposts are moving at a rapid pace

Re: Kafka Removing Zookeeper Dependency

#150

Post by StreamBright »

agallego wrote: post #147
StreamBright wrote: post #145

Earlier quoted context omitted.

>> Easier for who? For any decent SRE out there. >> magnitudes more performance which is not possible by just tuning Cassandra Magnitudes?? Are you talking about the order of magnitude? You should read the ScyllaDB performance report first. https://www.scylladb.com/product/benchmarks/aws-i3-metal-ben... Avg. 99.9% Latency (ms): 9.9 vs. Avg. 99.9% Latency (ms): 474.4 While there is no significant latency difference in…

who cares about lower percentage tiers in the world of big data? what does the p30 or 50 even matter at large scale? See Gil Tene's talk on how not to measure latency. https://www.youtube.com/watch?v=lJ8ydIuPFeU What matters is what most of your customers will get - p99, p999, p9999, p100.

You are assuming that all workloads are customer facing.
Post reply on HN