5 ms·

Did you try to tune GC (as most Kafka production systems would have GC configured)? Which JVM version?

by StreamBright 6y ago

koffiezet 6y ago
Just the fact that you have to ask all these things proves the point?
- pjmlp 6y ago
  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 it is written and what tools one makes use of. If Go is so much better than Java, Google would have replaced it already on Android with Go (battery life and such), instead they went with a mix of AOT/JIT with PGO, introducing Kotlin, while gomobile efforts were never given any serious consideration not even for the NDK.
  - gen220 6y ago
    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. Because Kotlin runs on the JVM and can run on top of Java codebases, it doesn’t have to leap over these hurdles. There are other reasons you can come up with I’m sure, but those are the biggest that stick out to me. Notably it has nothing to do with “which language is better”. They optimize for different use cases, and that’s OK. That being said, if you were writing Android from scratch and were only targeting ARM (an equally silly comparison meant to highlight the differences in the languages), you’d be hard pressed to justify Java over Go.
    - apta 6y ago
      > (1) compile faster This isn't really true for non-trivial code bases. And even if it is, it's not a big difference in practice, especially with incremental compilation where I find it actually much quicker to change a couple of files and re-run unit tests compared to golang which has to spit out a multi-dozen MB binary each time, taking 5-6+ seconds. > (2) compile into single binaries with no dynamic links Java is getting AOT compilation which will do the same. > (3) natively support concurrency and parallelism with M:N routines:threads. Java is getting those as well: http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h...
    - pjmlp 6y ago
      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.
      - Groxx 6y ago
        I honestly have yet to see any evidence that Fuchsia is anything but an experiment in this respect, like Dart was (which was also going to "replace android"). I entirely admit the possibility, but I see no plan. Hopes and aspirations are not plans.
        pjmlp 6y ago
        > That being said, if you were writing Android from scratch and were only targeting ARM (an equally silly comparison meant to highlight the differences in the languages), you’d be hard pressed to justify Java over Go. Instead they went with Rust, C++ and Dart. Now what have all those languages in common that Go lacks?
        Groxx 6y ago
        I think you meant to reply to the parent comment with this?
- StreamBright 6y ago
  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.99999 is a whole different subject though. I don't understand what is the point of comparing a default GC setting that is for hello world applications to a software that is optimized every way possible. Apples to oranges. It is a grat marketing gimmick though. Look ma no performance! Look here, so much faster. We live in a single dimension word, yay!
  - manigandham 6y ago
    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 Cassandra but still lags behind drastically with performance.
    - StreamBright 6y ago
      >> 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-benchmark/ 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.
      - agallego 6y ago
        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 https://www.youtube.com/watch?v=lJ8ydIuPFeU What matters is what most of your customers will get - p99, p999, p9999, p100.
- Groxx 6y ago
  I'm going to go with "absolutely not". The fact that a tool works out of the box and offers you an extensive array of ways to get more out of it is not in any way worse than a tool that just works out of the box. You can use it in exactly the same way with no more mental effort - stick to the defaults.

Did you try to tune GC (as most Kafka production systems would have GC configured)? Which JVM version?

koffiezet 6y ago

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

pjmlp 6y ago
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 it is written and what tools one makes use of. If Go is so much better than Java, Google would have replaced it already on Android with Go (battery life and such), instead they went with a mix of AOT/JIT with PGO, introducing Kotlin, while gomobile efforts were never given any serious consideration not even for the NDK.
- gen220 6y ago
  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. Because Kotlin runs on the JVM and can run on top of Java codebases, it doesn’t have to leap over these hurdles. There are other reasons you can come up with I’m sure, but those are the biggest that stick out to me. Notably it has nothing to do with “which language is better”. They optimize for different use cases, and that’s OK. That being said, if you were writing Android from scratch and were only targeting ARM (an equally silly comparison meant to highlight the differences in the languages), you’d be hard pressed to justify Java over Go.
  - apta 6y ago
    > (1) compile faster This isn't really true for non-trivial code bases. And even if it is, it's not a big difference in practice, especially with incremental compilation where I find it actually much quicker to change a couple of files and re-run unit tests compared to golang which has to spit out a multi-dozen MB binary each time, taking 5-6+ seconds. > (2) compile into single binaries with no dynamic links Java is getting AOT compilation which will do the same. > (3) natively support concurrency and parallelism with M:N routines:threads. Java is getting those as well: http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h...
  - pjmlp 6y ago
    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.
    - Groxx 6y ago
      I honestly have yet to see any evidence that Fuchsia is anything but an experiment in this respect, like Dart was (which was also going to "replace android"). I entirely admit the possibility, but I see no plan. Hopes and aspirations are not plans.
      - pjmlp 6y ago
        > That being said, if you were writing Android from scratch and were only targeting ARM (an equally silly comparison meant to highlight the differences in the languages), you’d be hard pressed to justify Java over Go. Instead they went with Rust, C++ and Dart. Now what have all those languages in common that Go lacks?
        Groxx 6y ago
        I think you meant to reply to the parent comment with this?
StreamBright 6y ago
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.99999 is a whole different subject though. I don't understand what is the point of comparing a default GC setting that is for hello world applications to a software that is optimized every way possible. Apples to oranges. It is a grat marketing gimmick though. Look ma no performance! Look here, so much faster. We live in a single dimension word, yay!
- manigandham 6y ago
  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 Cassandra but still lags behind drastically with performance.
  - StreamBright 6y ago
    >> 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-benchmark/ 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.
    - agallego 6y ago
      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 https://www.youtube.com/watch?v=lJ8ydIuPFeU What matters is what most of your customers will get - p99, p999, p9999, p100.
Groxx 6y ago
I'm going to go with "absolutely not". The fact that a tool works out of the box and offers you an extensive array of ways to get more out of it is not in any way worse than a tool that just works out of the box. You can use it in exactly the same way with no more mental effort - stick to the defaults.