Thanks Bernd for pointing to this.
I tried to profile the single request with yourKit.
I found some method calls that look strange to me. Note the millis are
much larger due to additional profiling costs): The whole request took
now around 100 seconds with tracing.
- org.apache.catalina.connector.Request.isSSLAttribute(String) is called
205.000 times but it took only 671 ms (own time 499ms)
- some methods like
com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates() or -
com.sun.net.ssl.internal.ssl.SSLSessionImpl.hashCode() are called 95.000
times (own time 2300ms)
- getPeerCertificates is also called from
RequestCacade.getAttributeNames as in the mentioned bug report.
- org.apache.catalina.util.Enumerator.<init>(Iterator, boolean) has 10
seconds own time!
- around 95000 javax.net.ssl.SSLPeerUnverifiedExceptions are thrown.
I tested this locally with a certificate created via java keytool.
Next I'll test with a real certificate
Michael
Am 12.04.2011 09:53, schrieb Bernd Bohmann:
Hello,
maybe it is a richfaces issue see:
https://issues.apache.org/jira/browse/MYFACES-2823
Regards
Bernd
On Mon, Apr 11, 2011 at 6:42 PM, Mike Kienenberger<mkien...@gmail.com> wrote:
Yes, I know that this method has drawbacks, but it's still a good
alternative in this case as he knows what methods are involved, and he
has access to the source code so he can change it at the
htmlTableRenderer.encodeInnerHtml. Data method.
Not everyone wants to try to set up and learn YourKit, nor "evaluate"
it or buy it or any of the other "serious" profilers.
If you've already got a profiler installed and are familiar with it,
go with that. :) This is a quick-and-dirty solution that's often
worked for me. I've got the eclipse profiler installed, and I've had
YourKit installed before, but this is often the simplest path for me.
You can have the results back from this in the time it takes to 1)
download the h2database jar and drop it into your project, 2) change
the code, 3) recompile the app, 4) run it.
On Mon, Apr 11, 2011 at 12:31 PM, Mark Struberg<strub...@yahoo.de> wrote:
yea, but most of the time you
a) don't exactly know what you r looking for
b) don't like to change your code
c) will get the the lifecycle wrappers back as 'most expensive' methods...
LieGrue,
strub
--- On Mon, 4/11/11, Mike Kienenberger<mkien...@gmail.com> wrote:
From: Mike Kienenberger<mkien...@gmail.com>
Subject: Re: JSF application very slow with HTTPS
To: "MyFaces Discussion"<users@myfaces.apache.org>
Cc: "Mark Struberg"<strub...@yahoo.de>
Date: Monday, April 11, 2011, 4:27 PM
Or you can go with something a lot
simpler and start with the free
profiler provided in the H2Database jar.
import org.h2.util;
...
Profiler profiler = new Profiler();
profiler.startCollecting();
// application code
System.out.println(profiler.getTop(3));
http://www.h2database.com/html/performance.html#application_profiling
For my own use, I've pulled out the three relevant classes
and removed
the unnecessary methods if you don't want to grab the
entire package,
although that's really trivial to do as well.
It's about 350 lines
of code total.
On Mon, Apr 11, 2011 at 12:12 PM, Mark Struberg<strub...@yahoo.de>
wrote:
Ah sorry, have overread that:
The time is spent in
htmlTableRenderer.encodeInnerHtml
I'd start the application with YourKit profiler and do
some profiling.
You can get a free yourkit test license (14 days I
think) for evaluation.
LieGrue,
strub
--- On Mon, 4/11/11, Michael Heinen<mhn4...@googlemail.com>
wrote:
From: Michael Heinen<mhn4...@googlemail.com>
Subject: Re: JSF application very slow with HTTPS
To: "MyFaces Discussion"<users@myfaces.apache.org>
Date: Monday, April 11, 2011, 3:45 PM
Fat? Well there is a lot of EL
in this table, nearly in all cells,
e.g. for column widths, values, styles etc.
The EL is always hitting backing beans, some with
additional map access.
But the real problem is the poor HTTPS performance
compared
to HTTP.
It should not be caused by the app and also not by
JSF or
Tomcat of course.
There should be a little overhead for additional
handshaking, but not
for the rendering!
Could this be caused by a buffering whereever?
Mark (or anybody else), did you compare your app
with http
and https?
Just wondering whether this is a problem only in
my app.
Regards,
Michael
Am 11.04.2011 17:27, schrieb Mark Struberg:
Btw another question: 1s local response time?
How fat
is this page?
We have a really big page in production with
1400
lines in a dataTable - and it renders in 450
ms...
How many back-and-forth requests do you see
if you
open firebug?
Do you have some EL involved which isn't
hitting the
backing bean but directly goes into the database?
Something
in this direction...
LieGrue,
strub
--- On Mon, 4/11/11, Mike Kienenberger<mkien...@gmail.com>
wrote:
From: Mike Kienenberger<mkien...@gmail.com>
Subject: Re: JSF application very slow
with HTTPS
To: "MyFaces Discussion"<users@myfaces.apache.org>
Cc: "Michael Heinen"<mhn4...@googlemail.com>
Date: Monday, April 11, 2011, 2:20 PM
I also use
jetty-6.1.22. My environment is
almost
identical to
yours, give or take a minor version
number.
On Mon, Apr 11, 2011 at 7:49 AM, Michael
Heinen<mhn4...@googlemail.com>
wrote:
Hi,
My JSF application is very slow via
HTTPS.
Some parts are 15 times slower
compared to
HTTP
I measured the response times of the
xhtml
requests
with Fiddler (locally
and over network)
Result for a very large page (512 KB)
with a
big
datatable without ajax
usage:
-- local access with HTTP: 1 sec
-- local access with HTTPS: 15-16
sec
Other pages are factor 2-4 slower,
with or
without
ajax.
The time is spent in
htmlTableRenderer.encodeInnerHtml. Data
is of
course
available, there is no additional
backend
access.
The simple download of xhtml files or
other
files is
NOT (noticeable)
slower.
Other non JSF applications running on
the same
servers
are also not slower
with HTTPS.
Before I start profiling:
- Does anybody have an idea where I
should
look at?
- Are there any known JSF or webApp
settings
that
influence https
performance?
Environment:
Facelets
myFaces 1.2.9
tomahawk12_1.1.10
richfaces 3.3.3
tomcat 6.0.29
jdk 1.6.0_23
Regards,
Michael
