You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zipkin.apache.org by Adrian Cole <ad...@gmail.com> on 2019/05/15 07:41:12 UTC
next release will be zipkin again :)
Hi, folks.
Before, we chatted about releasing the reporter project next, but as
Rag and I did some big perf work on the codec library, it is better to
release zipkin again (so that reporter and dependencies jobs can use
the faster codec).
So, sometime shortly we'll start another Zipkin release. This is not
just codec, this also adds the highly anticipated throttling and
Elasticsearch 7 features.
Stay tuned!
-A
* Why is faster codec important? Well, any library that uses zipkin's
codec will use less cpu and/or generate less garbage. While most of
our optimizations were read side (ex being able to decode from a
ByteBuffer), there were also some write side optimizations. So, this
means tracers like Brave, analysis jobs like Spark, and stream
processing like Kafka streaming will all benefit (especially if
protobuf format).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
For additional commands, e-mail: dev-help@zipkin.apache.org
Re: next release will be zipkin again :)
Posted by Adrian Cole <ad...@gmail.com>.
closing this thread.. here's the release vote
https://lists.apache.org/thread.html/03b215cc4a6e10a7092fe39b6ce87d3a964f35b6e181e12da4d45432@%3Cdev.zipkin.apache.org%3E
On Wed, May 15, 2019 at 3:41 PM Adrian Cole <ad...@gmail.com> wrote:
>
> Hi, folks.
>
> Before, we chatted about releasing the reporter project next, but as
> Rag and I did some big perf work on the codec library, it is better to
> release zipkin again (so that reporter and dependencies jobs can use
> the faster codec).
>
> So, sometime shortly we'll start another Zipkin release. This is not
> just codec, this also adds the highly anticipated throttling and
> Elasticsearch 7 features.
>
> Stay tuned!
> -A
>
> * Why is faster codec important? Well, any library that uses zipkin's
> codec will use less cpu and/or generate less garbage. While most of
> our optimizations were read side (ex being able to decode from a
> ByteBuffer), there were also some write side optimizations. So, this
> means tracers like Brave, analysis jobs like Spark, and stream
> processing like Kafka streaming will all benefit (especially if
> protobuf format).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
For additional commands, e-mail: dev-help@zipkin.apache.org