Hi Tom,
On Monday 05 September 2016 06:32 PM, Tom Crayford wrote:
We've been using SSL quite successfully on a few thousand production
clusters, and have done heavy performance testing, and as far as we can
see, it doesn't impact the cluster's capacity. The only case I could see
that happening is if you have a *lot* of connection churn, but that isn't
very typical for most Kafka usage.
We have a single broker and the clients to this broker are the Java
producers and consumers across different Java VMs. The producers are one
per app (as recommended by Kafka) and consumers are around 3 per app
(all pointing to the same broker, obviously). I don't think this adds to
any kind of connection churn. Furthermore, the slowness we are seeing is
in the client JVMs and no real noticeable issues on the broker itself.
That's for both produce and consume traffic. We do see increase amounts of
garbage collection under high consumer load with SSL enabled, but nothing
too horrible (brokers are well below the SLA of GC to keep their zookeeper
sessions alive).
This GC you notice, is it on the broker(s) or on the clients which hosts
the producer/consumers? Either way, this is a good hint and something I
hadn't considered in my setup. I'll see if I can get some GC
logs/metrics on our setup for this. Thanks for the input.
-Jaikiran
Thanks
Tom Crayford
Heroku Kafka
On Sun, Sep 4, 2016 at 6:28 PM, Todd Palino <tpal...@gmail.com> wrote:
We've been using SSL for produce traffic (mirror makers only right now, but
that's a very large percentage of traffic for us), and we're in the process
of turning it on for inter broker traffic as well. Our experience is that
this does not present a significant amount of overhead to the brokers.
Specifically with switching over the IBP, we were expecting a lot more of a
hit, and it really only ended up being something like a 5% increase in
system load, and no reduction in the cluster capacity, in our test cluster.
Note that this relies on the fix in KAFKA-4050 and switching the PRNG to
SHA1PRNG.
Right now, we're specifically avoiding moving consume traffic to SSL, due
to the zero copy send issue. Now I've been told (but I have not
investigated) that OpenSSL can solve this. It would probably be a good use
of time to look into that further.
That said, switching the message format to the newer option (KIP-31 I
believe?) will result in the brokers not needing to recompress message
batches that are produced. This should result in a significant reduction in
CPU usage, which may offset the cost of SSL. We haven't had a chance to
fully investigate this, however, as changing that config depends on the
clients being updated to support the new format.
-Todd
On Sunday, September 4, 2016, Jaikiran Pai <jai.forums2...@gmail.com>
wrote:
We are using 0.10.0.1 of Kafka and (Java) client libraries. We recently
decided to start using SSL for Kafka communication between broker and
clients. Right now, we have a pretty basic setup with just 1 broker with
SSL keystore setup and the Java client(s) communicate using the
Producer/Consumer APIs against this single broker. There's no client auth
(intentionally) right now. We also have plain text enabled for the
initial
testing.
What we have noticed is that the consumer/producer performance when SSL
is
enabled is noticeably poor when compared to plain text. I understand that
there are expected to be performance impacts when SSL is enabled but the
order of magnitude is too high and in fact it shows up in a very
noticeable
fashion in our product. I do have the numbers, but I haven't been able to
narrow it down yet (because there's nothing that stands out, except that
it's slow). Our application code is exactly the same between non-SSL and
SSL usage.
Furthermore, I'm aware of this specific JIRA in Kafka
https://issues.apache.org/jira/browse/KAFKA-2561 which acknowledges a
similar issue. So what I would like to know is, in context of Kafka
0.10.x
releases and Java 8 support, are there any timelines that the dev team is
looking for in terms of improving this performance issue (which I believe
requires usage of OpenSSL or other non-JDK implementations of SSLEngine)?
We would like to go for GA of our product in the next couple of months
and
in order to do that, we do plan to have Kafka over SSL working with
reasonably good performance, but the current performance isn't promising.
Expecting this to be fixed in the next couple of months and have it
available in 0.10.x is probably too much to expect, but if we know the
plans around this, we should be able to come up with a plan of our own
for
our product.
-Jaikiran
--
*Todd Palino*
Staff Site Reliability Engineer
Data Infrastructure Streaming
linkedin.com/in/toddpalino