tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wyraz <michael.wy...@evermind.de>
Subject Re: Speed up page compiling (partial solved)
Date Fri, 11 Jan 2013 11:36:43 GMT
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 <michael.wyraz@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
>>>>>> <thiagohp@gmail.com> wrote:
>>>>>>
>>>>>>> On Mon, 07 Jan 2013 12:29:37 -0200, Michael Wyraz
>>>>>>> <michael.wyraz@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-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>>>>
>>>>>>> ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: dev-help@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.wyraz@evermind.de
>>>>>
>>>>> HRB: 21586
>>>>> Amtsgericht Leipzig
>>>>>
>>>>> Geschäftsführer:
>>>>> Christoph Klemm
>>>>> Thomas Grünert
>>>>> Michael Wyraz
>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**---------

>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: dev-help@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.wyraz@evermind.de
>>>
>>> HRB: 21586
>>> Amtsgericht Leipzig
>>>
>>> Geschäftsführer:
>>> Christoph Klemm
>>> Thomas Grünert
>>> Michael Wyraz
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message