You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Aurélien DEHAY <au...@zorel.org> on 2016/09/23 16:25:16 UTC
ListenHTTP SSL/TLS performance
Hello.
I encounter performance issue with ListenHTTP and StandardSSLContextService on Nifi 0.6.1.
My workflow is quite simple : ListenHTTP => Merge => PutFile.
I can top 3000 req/s with http, only few hundreds (about 200 without error) with https.
The thread dump shows a lock at getDefaultCipherSuiteList:
ListenHTTP (57965e61-52c0-4ed2-a8d8-ed9bcf1500c4) Web Server-1050-selector-ServerConnectorManager@e624229/3 - priority:5 - threadId:0x00007f12c0001000 - nativeId:0x3e47 - state:BLOCKED
stackTrace:
java.lang.Thread.State: BLOCKED (on object monitor)
at sun.security.ssl.SSLContextImpl.getDefaultCipherSuiteList(SSLContextImpl.java:291)
- waiting to lock <0x0000000631ce2450> (a sun.security.ssl.SSLContextImpl$TLSContext)
at sun.security.ssl.SSLEngineImpl.init(SSLEngineImpl.java:402)
at sun.security.ssl.SSLEngineImpl.<init>(SSLEngineImpl.java:357)
at sun.security.ssl.SSLContextImpl.engineCreateSSLEngine(SSLContextImpl.java:210)
at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:361)
at org.eclipse.jetty.util.ssl.SslContextFactory.newSSLEngine(SslContextFactory.java:1344)
. I'm using java 1.8.0_101-b13, I found some issues with a synchronized() on cipher cache.
I wonder if I can do anything in Nifi configuration, if ever someone else have this issue.
Thanks.
RE: ListenHTTP SSL/TLS performance
Posted by Aurélien DEHAY <au...@zorel.org>.
Hello, and thanks for the answer.
Will try OpenJDK 9, but It won’t be great for the production environment. We will try with Open JDK 7 either.
Maybe HandleHTTPRequest does not have the same behaviour regarding SSL context ? Will have to try that one too I suppose.
I will post here the results if I have something worth it.
Aurélien.
De : Andy LoPresto [mailto:alopresto@apache.org]
Envoyé : vendredi 23 septembre 2016 21:41
À : users@nifi.apache.org
Cc : Aurélien DEHAY <au...@zorel.org>
Objet : Re: ListenHTTP SSL/TLS performance
Hi Aurélien,
It sounds like you are already familiar with this bug regarding the cipher cache lookup being synchronized [1]. There isn’t much you can do from a “NiFi config” perspective to change that. It does appear that the patch for this issue was merged into OpenJDK 9 earlier this year [2]. Are you able to try running on OpenJDK 9 instead of (I’m assuming) Oracle 8 JRE? I checked the Oracle code for 1.8.0_101-b13, and it does not appear to include this change.
[cid:image001.png@01D21671.5612BDB0]
I can also look into ListenHTTP more closely (I believe it’s an older processor) and see if there is a reason it needs to initialize a new SSLEngine as frequently as it appears to be (possibly every connection). I’m not sure the level of encapsulation there — if the key parameters are not contained within the engine, we might be able to cache a pool of engines locally in the processor (or controller service) and serve them for the incoming connections.
[1] https://bugs.openjdk.java.net/browse/JDK-8133070
[2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6338191e2e44
Andy LoPresto
alopresto@apache.org<ma...@apache.org>
alopresto.apache@gmail.com<ma...@gmail.com>
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
On Sep 23, 2016, at 9:25 AM, Aurélien DEHAY <au...@zorel.org>> wrote:
Hello.
I encounter performance issue with ListenHTTP and StandardSSLContextService on Nifi 0.6.1.
My workflow is quite simple : ListenHTTP => Merge => PutFile.
I can top 3000 req/s with http, only few hundreds (about 200 without error) with https.
The thread dump shows a lock at getDefaultCipherSuiteList:
ListenHTTP (57965e61-52c0-4ed2-a8d8-ed9bcf1500c4) Web Server-1050-selector-ServerConnectorManager@e624229/3 - priority:5 - threadId:0x00007f12c0001000 - nativeId:0x3e47 - state:BLOCKED
stackTrace:
java.lang.Thread.State: BLOCKED (on object monitor)
at sun.security.ssl.SSLContextImpl.getDefaultCipherSuiteList(SSLContextImpl.java:291)
- waiting to lock <0x0000000631ce2450> (a sun.security.ssl.SSLContextImpl$TLSContext)
at sun.security.ssl.SSLEngineImpl.init(SSLEngineImpl.java:402)
at sun.security.ssl.SSLEngineImpl.<init>(SSLEngineImpl.java:357)
at sun.security.ssl.SSLContextImpl.engineCreateSSLEngine(SSLContextImpl.java:210)
at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:361)
at org.eclipse.jetty.util.ssl.SslContextFactory.newSSLEngine(SslContextFactory.java:1344)
. I’m using java 1.8.0_101-b13, I found some issues with a synchronized() on cipher cache.
I wonder if I can do anything in Nifi configuration, if ever someone else have this issue.
Thanks.
Re: ListenHTTP SSL/TLS performance
Posted by Andy LoPresto <al...@apache.org>.
Hi Aurélien,
It sounds like you are already familiar with this bug regarding the cipher cache lookup being synchronized [1]. There isn’t much you can do from a “NiFi config” perspective to change that. It does appear that the patch for this issue was merged into OpenJDK 9 earlier this year [2]. Are you able to try running on OpenJDK 9 instead of (I’m assuming) Oracle 8 JRE? I checked the Oracle code for 1.8.0_101-b13, and it does not appear to include this change.
I can also look into ListenHTTP more closely (I believe it’s an older processor) and see if there is a reason it needs to initialize a new SSLEngine as frequently as it appears to be (possibly every connection). I’m not sure the level of encapsulation there — if the key parameters are not contained within the engine, we might be able to cache a pool of engines locally in the processor (or controller service) and serve them for the incoming connections.
[1] https://bugs.openjdk.java.net/browse/JDK-8133070 <https://bugs.openjdk.java.net/browse/JDK-8133070>
[2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6338191e2e44 <http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6338191e2e44>
Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Sep 23, 2016, at 9:25 AM, Aurélien DEHAY <au...@zorel.org> wrote:
>
> Hello.
>
> I encounter performance issue with ListenHTTP and StandardSSLContextService on Nifi 0.6.1.
>
> My workflow is quite simple : ListenHTTP => Merge => PutFile.
>
> I can top 3000 req/s with http, only few hundreds (about 200 without error) with https.
>
> The thread dump shows a lock at getDefaultCipherSuiteList:
> ListenHTTP (57965e61-52c0-4ed2-a8d8-ed9bcf1500c4) Web Server-1050-selector-ServerConnectorManager@e624229/3 - priority:5 - threadId:0x00007f12c0001000 - nativeId:0x3e47 - state:BLOCKED
> stackTrace:
> java.lang.Thread.State: BLOCKED (on object monitor)
> at sun.security.ssl.SSLContextImpl.getDefaultCipherSuiteList(SSLContextImpl.java:291)
> - waiting to lock <0x0000000631ce2450> (a sun.security.ssl.SSLContextImpl$TLSContext)
> at sun.security.ssl.SSLEngineImpl.init(SSLEngineImpl.java:402)
> at sun.security.ssl.SSLEngineImpl.<init>(SSLEngineImpl.java:357)
> at sun.security.ssl.SSLContextImpl.engineCreateSSLEngine(SSLContextImpl.java:210)
> at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:361)
> at org.eclipse.jetty.util.ssl.SslContextFactory.newSSLEngine(SslContextFactory.java:1344)
>
>
>
>
> . I’m using java 1.8.0_101-b13, I found some issues with a synchronized() on cipher cache.
>
> I wonder if I can do anything in Nifi configuration, if ever someone else have this issue.
>
> Thanks.