users@glassfish.java.net

Re: Slow HTTPS - Java 6 + Glassfish

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Mon, 15 Sep 2008 12:38:28 -0400

Salut,

glassfish_at_javadesktop.org wrote:
> hi,
>
> thank you for your feedback JeanFrancois...
>
> what does "blocking socket" mean? there is a tremendous difference in performance - blocking socket makes the https fast enough.

With blocking socket, every client that connect to GF will consume a
Thread for the time of the connection. With non blocking, you consume a
Thread only when there is data available on the connection. With
blocking, data or not, you waste a Thread. So throughput is always
faster when blocking socket are used, but the scalability is far much
lower as supporting 15000 clients could means having 15000 Threads.

That's why when comparing GF with Tomcat with a low number of connection
(let's say 100) you always have the "vision :-)" that Tomcat is much
faster. This is only true when the number of connected clients is lower
than the number of threads. As soon as you increase the load, you can
see that non-blocking socket (e.g Grizzly) perform better.

Grizzly supports blocking socket, so what you just enabled improve
throughput at the price of scalability. We will take a look at the
performance issue, but my experience tell me that it's the JDK under the
hood that is a little slower when SSL + non blocking socket are used.



is there a reason why http works fast (without needing blocking socket)
but https does not?

Yes the non blocking hanshake operation hurt the performance when
SSL/non blocking is used.


> Could it have anything to do with the fact that this is running on a T2000 with the Niagara processor?

I doubt.

The same config runs -way- faster in https on old V210 Ultrasparc IIIis.

Same JDK? Hum then you might be right. If you can privately send me the
details of your hardware, I can ping the JDK SSL team to see what they
things. There should not be such difference.


>
> That aside, is it safe to run in "blocking socket" mode until (presumably) the bug is fixed?

Yes, but allocated much more threads than the default, which is 5. At
least 150 and more.

A+

-- Jeanfrancois


>
> merci
> [Message sent by forum member 'coreyjohnston' (coreyjohnston)]
>
> http://forums.java.net/jive/thread.jspa?messageID=299191
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>