Created attachment 12856 [details] startUp.png quality analyzer
Let's not waste anyone's time with this "quality" metric. If you want to suggest changes, please provide patches.
my tomcat server has 4 servlets loaded multiple times by 3 connectors (in 3 different wars). In order not to have to clean after these instances I put unpackwar=false. As a minor security consideration, each time less the files are on the disk, the smaller is the exposure (albeit an informed attacker would anyway be most interested in the ./work/*/_* directories). Anyway, being aware that this would reduce startup, time, I was surprised about the accelerated deterioration of startup time as my application and the number of jsp's grew. It's roughly 300 struts-related classes and 300 jsps. On an intel machine one generation behind, it easily took 5 minutes or more to start, especially, the super.init() method of the four servlets took ages. As per the attached screenshot, I guess the reason for this is the unpackwar that throws over 10'000 (probably planned?) exceptions (WARDir*...) and might unpack the war many times. RFE: ==== If these assumptions are right, I suggest to enhance the documentation at the above URL to inform the tomcat administrator about these implications.
Even if it is the problem (which I'm not sure of), it will be very difficult to "fix". I'd like to point out that the regular file based stuff creates as many of these exceptions, and, generally, Struts webapps startup is extremely slow.
further observations that may help others: 1) when setting CATALINA_OPTS="-verbose:gc" I see about 300 garbage collections: [GC 18619K->3026K(260160K), 0.0217930 secs] [GC 19218K->3011K(260160K), 0.0047730 secs] [GC 19191K->3011K(260160K), 0.0033220 secs] [GC 19203K->3013K(260160K), 0.0039100 secs] [GC 19205K->3100K(260160K), 0.0047540 secs] [GC 19292K->3125K(260160K), 0.0045940 secs] [GC 19316K->3143K(260160K), 0.0042910 secs] [GC 19328K->3167K(260160K), 0.0043550 secs] ... [GC 19654K->3458K(260160K), 0.0009390 secs] [Full GC 12290K->3530K(260160K), 0.0917670 secs] [GC 19784K->3811K(260224K), 0.0043500 secs] ... [GC 20465K->4217K(260224K), 0.0011250 secs] [GC 20471K->4215K(260224K), 0.0010260 secs] [GC 20466K->4222K(260224K), 0.0010590 secs] [GC 20478K->4242K(260224K), 0.0013500 secs] 2) when running jprobe memorydebugger, it ends up with excessive memory use and swapping such that a warm reboot of the machine is more promising than waiting for the console to respond on simple key entries ... (gijs.bruyn@quest.com from JProbe support suspects unpack=false to be the main culprit)