https://bz.apache.org/bugzilla/show_bug.cgi?id=68054
Let's see how it works On Tue, Oct 31, 2023 at 3:04 PM Vicente Rossello <cocorosse...@gmail.com> wrote: > 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 >> >>>>> >> >>>>> >> > >> >>
