Cool. Thanks for going down the rabbit hole ;-) Given that there is a lot of information/benchmarks etc. collected in this thread, what do you think about opening an issue in Tomcat with a reference to this thread?
They might take a look. Gruß Richard Am 28. Oktober 2023 12:22:12 MESZ schrieb Jens Zurawski <[email protected]>: >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 >>> >>>
