Re: Very slow JSF Development Mode on tomee 8.x newer than 8.0.6

Jens Zurawski <[email protected]> Sat, 28 Oct 2023 12:22:12 +0200
Newsgroups gmane.comp.java.openejb.user
Message-ID <7cf71fe1-9527-40da-ae12-40054bc71e07__1606.2979049579$1698488673$gmane$org@diegurus.de>
For all who are interested I've made some quick benchmarks, to see the 
impact.
I've taken one of my biggest views which is making a small AJAX poll on 
the same view every 30s to be able to get some balanced average values 
for the response times. The payload of the poll is small (around 500 to 
1000 bytes) but because it's the same view, the component tree is big.

Windows (same machine localhost, it is an 8 core Ryzen-7 with 64GB of 
RAM and SSD, so the machine is not the limiting factor)
====================================================
~ 12000 ms DevMode plain
~ 600 ms DevMode with <Resources archiveIndexStrategy="bloom" 
allowLinking="true"/>
~ 100 ms ProdMode plain
~ 100 ms ProdMode with <Resources archiveIndexStrategy="bloom" 
allowLinking="true"/>

Linux (customer site over Internet VPN, it is a 6 core Intel i5 with 
16GB of RAM and SSD)
====================================================
~ 700 ms DevMode plain
~ 350 ms DevMode with <Resources archiveIndexStrategy="bloom" 
allowLinking="true"/>
~ 130 ms ProdMode plain
~ 130 ms ProdMode with <Resources archiveIndexStrategy="bloom" 
allowLinking="true"/>

No, the 12000 ms is _not_ a typo ;-)

My conclusions from these figures are:
- ProdMode is not affected by this issue
- On Windows the problem is very significant and renders the DevMode 
unusable
- On Linux the problem is not that dramatic, so one can say "well, it's 
dev mode, deal with it", but it is also affected in doubling the 
response times. Maybe worth enough to also look into this issue even if 
one is Linux only.

cu
Jens



Am 28.10.2023 um 11:43 schrieb Jens Zurawski:
> I can confirm, that this setting also solves the problem of the slow 
> dev mode. Thank you for the tip.
>
> So, either this or the canonCache solves this issue for me on my 
> development environment. But, of course, both of them should be 
> avoided on production systems. The chances that they slip from dev to 
> prod by accident may be small (if one is using well known "good" 
> development strategies and methods, like staging, testing Q&A, 
> reviews, and the like) but still possible.
> And the fact, that it seems to only really matter in JSF dev mode is 
> curious at the least.
>
> Am 28.10.2023 um 08:24 schrieb Vicente Rossello:
>> Sorry, that was not correct.
>>
>> The allowLinking is at the resources level. So, in the 
>> META-INF/context.xml
>> file:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <Context allowCasualMultipartParsing="true" reloadable="false"
>> containerSciFilter="org.apache.tomcat.websocket.server.WsSci|org.apache.jasper.servlet.JasperInitializer" 
>>
>>           parallelAnnotationScanning="true"
>>           clearReferencesThreadLocals="false"
>> skipMemoryLeakChecksOnJvmShutdown="true">
>>      <Manager pathname=""/>
>>
>>      <Resources archiveIndexStrategy="bloom" allowLinking="true"/>
>> </Context>
>>
>>
>> BTW, the slowness is something between checking the canonicalPath too
>> many times and jdk12 that removed those canonCache by default. See
>> https://bugs.openjdk.org/browse/JDK-8258036
>>
>>