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
