I eliminated the OGNL problem (simple caching, there are only a few
unique expressions in the app). The call to file.exists() is also in
tomcat's original classloader, so there's no difference. Then I profiled
again.
- Page load takes ~50 seconds with profiler running. Before it took 65
seconds because of my own ogml caching issue.
- File.exists() takes ~20 seconds: 90% from tomcat's Webapp Classloader
called from AssetSourceImpl.getAsset. Probable reason: often-used
components that injects assets?
- PlasticProxyFactoryImpl.createProxy takes ~9 seconds: most often
called from PropBindingFactory.newBinding
I'm going to do some more research next week.
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 <[email protected]>:
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
<[email protected]> wrote:
On Mon, 07 Jan 2013 12:29:37 -0200, Michael Wyraz
<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
------------------------------**------------------------------**
---------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
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: [email protected]
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
Thomas Grünert
Michael Wyraz
------------------------------**------------------------------**---------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
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: [email protected]
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
Thomas Grünert
Michael Wyraz
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
