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]
