I will try to open a bug. An obvious fix is to only make 1 call to getCannonicalPath for the same file. That would halve the time.
After that I guess is tomcat team decission.... maybe emitting a warning that allowLinking=false in windows is very slow for jsf development ... or they may have more ideas El mar, 31 oct 2023, 14:20, Jens Zurawski <j...@diegurus.de> escribió: > Ok, after 4 hours of bisecting, checking out, building and testing (I've > needed three bisect sessions, because the first one wasn't successful > due to build failures of some revisions and I had to manually find some > other revisions to bisect) I can definitely identify the commit which > introduces the DevMode performance issue. It is: > > 0325d91 TOMEE-3773 - Update Tomcat to 9.0.50 > > I've cross checked with the immediate commit before (277fc71) and it's > clear: > 277fc71 good > 0325d91 bad > > So, indeed, tomcat is the root cause of the problem. But, I don't think > it will be successful to create an issue in tomcat. A far as I can see > in the diffs of tomcat 9.0.48 to 9.0.50, I assume, it already was a bug > fix in /java/org/apache/catalina/webresources/DirResourceSet.java. In > that class new code was inserted to skip symbolic links in > ServletContext.getResourcePaths(), which, I think, is important as a > security measure. Therefore, most likely they will not be willing to > revert that (I wouldn't recommend that, either) > > Long story short: It's not a bug it's a feature ;-) > > I guess, JSF in DevMode is doing a lot more calls to getResourcePaths() > hence suffering from this fix. Because ProdMode is not affected by this > I can live with it. Development environments are special in any case, > and to allow the dev tomcat following symlinks in that environment is > ok, from my pov. Just enable the allowLinking="true" and it works. > > At least my "academic problem" is solved and my "inner monk" is > satisfied and I don't think I will walk down this route any further. > > Many thanks to all of you who have helped me on this issue. > > cu > Jens > > Am 28.10.2023 um 15:17 schrieb Jens Zurawski: > > Yes, this may be one of the next steps here. But, I'm afraid, I have > > not enough info for them right now. > > Neither do I have a small test case to reproduce the problem, nor can > > I point them exact enough to what the problem might be. Also, maybe > > it's only coincidence, and the real problem is somewhere inside > > myfaces. The fact that ProdMode is not affected at all (at least not > > enough to measure any difference) and it only arises in JSF DevMode > > could point in that direction. > > > > So, before I go and open an issue on Tomcat, I want to try to narrow > > down it more. At least to the point where I can say: look, this commit > > in TomEE introduced it. And even better: here is a small test case to > > reproduce it. > > > > cu > > Jens > > > > > > Am 28.10.2023 um 12:55 schrieb Richard Zowalla: > >> 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 > >> <j...@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 > >>>>> > >>>>> > > > >
