Thank you for the hint - but it returns false.
Today I did some profiling with interesting results. Seems that the
current issues are self-made :-(
I installed a trial of YourKit Java Profile which seest so be really
usefull. Then I profiled a small page - once after it was changed, once
on second reload. The profiler allows to compare both snapshots. CPU
tracing slows down the application a lot, so don't wonder about the long
times. Here are my results:
The biggest time difference of this test was in
ComponentClassTransformWorker.transform
where the page is build. This happens several times, e.g. when creating
a link through link source to a different page that is not already build.
Here most time is consumed by InjectWorker. I tracked it down until
spring's BeanFactory.getBeansOfType() - it took several seconds. After
some more tests it turned out, that this was because of the profiler.
Without it, this BeanFactory.getBeansOfType() was not a speed issue anymore:
Because the profiler slowed down everything, I repeated the same with a
big page and without CPU tracing. In this mode, only method time, not
invocation count is profiled - it then runs with reasonable speed. On
the small page, everything happend within a few milliseconds which is
below the threashold of the profiler. The results on the big page are
much different:
Time consumption splits into many different calls during renderPage. I
used Hotspot profiling to trace it down to method calls. Here are the
biggest time-consumers:
- Most time goes to initializing OGNL-Bound expressions! This is a
home-made issue. We used them in some cases where tapestrys expressions
are not sufficient. Seems that there are uses in components that are
used very often - I'll to a rework of the code and repeat the tests.
Maybe I can cache it.
- Initializing the assets. I tracked it down to a call to file.exists()
in the webapp classloader - we use a special launcher that brings it's
own classloader - I'll check if it ist also an issue for the default
webapp classloader of tomcat.
I'l going to eliminate these issues and the post my new results.
Regards,
Michael.
We have a similiar application architecture, pages with a lot of ajax
components, biggest page reloading takes ~ 5s.
Michael, make sure you don't have a debug enabled on the root logger, it could
slow things down.
System.out.println(org.slf4j.LoggerFactory.getLogger("xyz123abcRandomLogger").isDebugEnabled());
- should return false.
Denis
Jan 10, 2013 v 9:57 AM, Michael Wyraz <michael.wy...@evermind.de>:
I did some further tests on a machine with SSD+HDD, 12 Core CPU, 32GB RAM.
I testet with the biggest page I found, log-level "warn".
The page always needs ~55 seconds to load after webapp start and after page
modification. There's no difference if it's loaded from SSD or from HDD.
During assembly, one core has a load of 80-90%, a second about 20-40%. The
other cores are idle.
The page itself requires ~30 seconds to assemble. But it links to a similar big
page (using linkSource.createPageRenderLinkWithContext) - so this page is
assebled too. If I change something in the first page, both pages are
re-assembled on next reload. This doubles the reload time. An alternative would
be to create the link without accessing the other page - but then I would have
to re-implememt stuff from linksource.
I have read (and thoght about) the suggestions from Thiago (splitting up things
to sub pages, look them up via link source). Probably this would solve the
issue but would be a deep impact in application design:
The "big" page does not contain the whole application. It contains everything
to edit a (big) business entity and it's sub-entities. The screens are separated in tabs,
each contains a component which contains other components like detail/wizard popups,
slide-ins and so on. The logic for creating each tab is within the responsible component
(e.g. returning the name of the tab or asking the backend to see if the user is allowed
to see a certain tab). If I separate the components to different pages and lookup/call
the pages dynamically, tapestry would still have to re-assemble them all on changes. To
avoid this, I'd move parts of the logic to the master page - which would split UI logic
across several pages.
Interesting results, I hope to carve out some time to optimize that code in
some way. Perhaps some kind of development only cache that could remove
some of the overhead of analyzing parameter types and usage.
On Wednesday, January 9, 2013, Michael Wyraz wrote:
Hi,
I had a closer look to the problem (reported by some of our developers):
There are a few really big pages. Formerly these where separate pages but
since we changed everything to ajax navigation, these pages are
consolidated to one page. I tested everything on a machine that runs the
workspace on a hardware raid on SSDs where IO performance should not be the
problem at all. After starting the webapp, the first load of this page
takes ~30 seconds. I changed tapestrys log level to "ALL" and restarted -
the page load took >4 minutes and printed several 100.000 log lines. Most
log lines (and probably most time) is in ParameterWorker. It takes about
90% of the component assembling time. Subsequent reloads take just a few
milliseconds. After modifying the page, reload takes again >4 minutes with
full debug.
Most time is spend in ParameterWorker (logs from line 319, 329 and 340).
Another place which takes lot time is Registry (logs from line 67 and 81).
Since the code in ParameterWorker is called some 100.000 or millions
times, speedup there would bring a big performance plus.
But maybe there are other ways to improve performance?
There are also a couple of performance tips at the very bottom of
http://tapestry.apache.org/**class-reloading.html<http://tapestry.apache.org/class-reloading.html>
On Mon, Jan 7, 2013 at 10:33 AM, Thiago H de Paula Figueiredo
<thiag...@gmail.com> wrote:
On Mon, 07 Jan 2013 12:29:37 -0200, Michael Wyraz
<michael.wy...@evermind.de> wrote:
Hi,
Hi!
we have a big project with Tapestry 5.3. There are many pages, lots of
components and many links between the pages (@Injects of other pages).
The problem is that after a change, the first page reload takes >5
seconds
on good hardware because there is much work for the tapestry page
compiler
which wastes much time of our developers.
There isn't a Tapestry page compiler, just a template parser and some
internal code that creates the page instances. There's no language
transformation, so, for me, it isn't compiling at all.
The first thing I think you should do is to do some profiling and check
whether these 5+ seconds are really all spent in Tapestry internals or if
there's some application-specific processing going on (method calls,
database queries, etc).
--
Thiago H. de Paula Figueiredo
------------------------------**------------------------------**
---------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
------------------------------**------------------------------**
---------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
--
Mit freundlichen Grüßen / Regards
Michael Wyraz
evermind GmbH
Schorlemmerstraße 1
04155 Leipzig
Tel.: +49 (0)341-25 39 66 - 0
Fax: +49 (0)341-25 39 66 - 1
Funk: +49 (0)177-73 00 00 3
E-Mail: michael.wy...@evermind.de
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
Thomas Grünert
Michael Wyraz
------------------------------**------------------------------**---------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
--
Mit freundlichen Grüßen / Regards
Michael Wyraz
evermind GmbH
Schorlemmerstraße 1
04155 Leipzig
Tel.: +49 (0)341-25 39 66 - 0
Fax: +49 (0)341-25 39 66 - 1
Funk: +49 (0)177-73 00 00 3
E-Mail: michael.wy...@evermind.de
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
Thomas Grünert
Michael Wyraz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
