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 >> >> >>> >> >> >> >> >> > >> >
