Hi guys,
IMO what you're currently measuring is SSL handshake performance vs.
no-handshake in plain connection.
I quickly googled for SMTP protocol and looks like there is possibility
to keep connection alive, IMO it's essential, especially for secured use
case.
To be more fair, try to run Echo benchmark, but not with 10 messages,
but for example 100K or more, it should remove impact of SSL handshake.
Thanks.
WBR,
Alexey.
On 30.06.15 16:05, Ben-Yosef Efrat wrote:
>
> Sorry, couldn’t attach the file. Please see it in
> ftp://transfer.comverse.com/outgoing/SSLVsPlain/SSLVsPlain.zip
>
> *From:*Ben-Yosef Efrat [mailto:Efrat.Ben-Yosef_at_comverse.com]
> *Sent:* Tuesday, June 30, 2015 4:41 PM
> *To:* users_at_grizzly.java.net
> *Subject:* RE: High CPU Usage on SSL utils
>
> Hi Alexey,
>
> We spent that last week on profiling this issue. We did the following:
> 1. Run our application on plain vs. Ssl when the application basically
> does nothing (respond with hard coded OK)
>
> 2. Run Grizzly SSL/Plain echo example under load
>
> 3. run Jprofiler, VisualVm and netbeans profiler
>
> All showed the same:
>
> * CPU increases dramatically – over 60% on some cases
>
> * memory increase by 40% and more on some cases
>
> * org.glassfish.grizzly.ssl.SSlUtils.executeDelegatedTask() is the
> most problematic methods CPU wise
>
> We cannot run our application this way at all. On ssl everything
> crashes after 20 min.
>
> Attached are some screenshots and the code for the ssl/Plain echo load
> test we run.
>
> Please advise
>
> Efrat
>
> *From:*Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
> *Sent:* Friday, June 19, 2015 8:18 PM
> *To:* users_at_grizzly.java.net <mailto:users_at_grizzly.java.net>
> *Subject:* Re: High CPU Usage on SSL utils
>
> Hi Tiran,
>
> I see your concern, but IMO it's similar to what you found w.r.t.
> "selector", if you enable "core classes" profiling - you'll see that
> it's core SSL implementation consumes CPU, not Grizzly itself. Once
> you have the profiling results with core classes, we can check what
> exactly consumes that much time.
>
> Thanks.
>
> WBR,
> Alexey.
>
> On 18.06.15 20:07, Meltser Tiran wrote:
>
> Hi Alexey (working with Efrat and Uri) J,
>
> First we don’t keep the connections open as this is an IMAP server
> (or proxy).
>
> Second, I agree that SSL channel should have some performance
> price but what we experience is far beyond a reasonable price,
> after making another check we see we have response times slower
> *600* times than plain communication…
>
> Third, we are running on a 16 cores machine in which SSL should
> hardly be noticed.
>
> Forth, we have just compared the SSL experience to our previous
> server written in C++ some more than 10 years ago and operated on
> machines with about ¼ CPU power (or even less), and load results
> show response time was doubled at max (*not 600 times worse*).
>
> Can you have a look on the hot method the profiler is showing and
> see if something can be done there (or maybe give us some guideline)?
>
> *Tiran Meltser***
> System Architect
> Global Products & Operations
> *Comverse* – /Making Your Network Smarter/
>
> T +972-3-7678381
> M +972-54-5639381
> Tiran.Meltser_at_comverse.com <mailto:Tiran.Meltser_at_comverse.com>
> *www.comverse.com <http://www.comverse.com/> *
>
> *P****Please think of the environment before printing this email***
>
> *From:*Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
> *Sent:* Thursday, June 18, 2015 8:16 PM
> *To:* users_at_grizzly.java.net <mailto:users_at_grizzly.java.net>
> *Subject:* Re: High CPU Usage on SSL utils
>
> Hi Efrat,
>
> do you keep connections alive?
> In general SSL is not for free and it's expected to be slower than
> plain communication.
>
> WBR,
> Alexey.
>
> On 18.06.15 18:14, Ben-Yosef Efrat wrote:
>
> Also, we see higher response times then before (around 50
> times longer)
>
> *From:*Ben-Yosef Efrat [mailto:Efrat.Ben-Yosef_at_comverse.com]
> *Sent:* Thursday, June 18, 2015 6:54 PM
> *To:* users_at_grizzly.java.net <mailto:users_at_grizzly.java.net>
> *Cc:* Broide Uri; Meltser Tiran
> *Subject:* High CPU Usage on SSL utils
>
> Hi Alexey,
>
> Continuing Uri’s query about the CPU, we moved to java8
> profiler and as you said, indeed not the select() was the issue.
>
> Now, we added the SSL to the picture (utilizing Grizzly’s
> SSLfilter) and as you can see in the attached screenshot, the
> executeDelegatedTask() method consumes a lot of CPU (we sort
> by self-tile CPU).
>
> Please advise,
>
> Thanks,
>
> Efrat
>
> cid:image001.png_at_01D0A9F5.776D0720
>
> ------------------------------------------------------------------------
>
> “This e-mail message may contain confidential, commercial or
> privileged information that constitutes proprietary
> information of Comverse Inc. or its subsidiaries. If you are
> not the intended recipient of this message, you are hereby
> notified that any review, use or distribution of this
> information is absolutely prohibited and we request that you
> delete all copies and contact us by e-mailing to:
> security_at_comverse.com <mailto:security_at_comverse.com>. Thank You.”
>
> ------------------------------------------------------------------------
>
> “This e-mail message may contain confidential, commercial or
> privileged information that constitutes proprietary
> information of Comverse Inc. or its subsidiaries. If you are
> not the intended recipient of this message, you are hereby
> notified that any review, use or distribution of this
> information is absolutely prohibited and we request that you
> delete all copies and contact us by e-mailing to:
> security_at_comverse.com <mailto:security_at_comverse.com>. Thank You.”
>
> ------------------------------------------------------------------------
>
> “This e-mail message may contain confidential, commercial or
> privileged information that constitutes proprietary information of
> Comverse Inc. or its subsidiaries. If you are not the intended
> recipient of this message, you are hereby notified that any
> review, use or distribution of this information is absolutely
> prohibited and we request that you delete all copies and contact
> us by e-mailing to: security_at_comverse.com
> <mailto:security_at_comverse.com>. Thank You.”
>
> ------------------------------------------------------------------------
>
> “This e-mail message may contain confidential, commercial or
> privileged information that constitutes proprietary information of
> Comverse Inc. or its subsidiaries. If you are not the intended
> recipient of this message, you are hereby notified that any review,
> use or distribution of this information is absolutely prohibited and
> we request that you delete all copies and contact us by e-mailing to:
> security_at_comverse.com <mailto:security_at_comverse.com>. Thank You.”
>
> ------------------------------------------------------------------------
> “This e-mail message may contain confidential, commercial or
> privileged information that constitutes proprietary information of
> Comverse Inc. or its subsidiaries. If you are not the intended
> recipient of this message, you are hereby notified that any review,
> use or distribution of this information is absolutely prohibited and
> we request that you delete all copies and contact us by e-mailing to:
> security_at_comverse.com. Thank You.”