Community
Participate
Working Groups
Hi, I have a standard war (spring application with spring jars embedded in the war) deployed on virgo (3.0.1). It doesn't have dependencies on any other bundles. The first time a page loads it takes about 20 to 30 secs while subsequent requests are very responsive. Profiling using Yourkit gave us the following hotspots: org.eclipse.virgo.osgi.extensions.equinox.hooks.ExtendedBundleFileWrapperFactoryHook$FileResourceEnforcingBundleFile.getEntry(String) org.eclipse.osgi.baseadaptor.bundlefile.ZipBundleFile.getEntry(String) java.util.zip.ZipFile.<init>(File) org.eclipse.osgi.framework.internal.core.BundleHost.getResource(String) org.springframework.osgi.util.BundleDelegatingClassLoader.findResource(String) On probing file io, we see that the actual file read for each class/jsp takes about 1 or 2 milliseconds. Any ideas on why the page takes a long time to load the first time it is requested? Thank you, Preethi
Here is the link to the Yourkit CPU telemetry snapshot: mediafire.com/?m48qqaat9rh8wea
I thought I'd take a peek at the telemetry snapshot, but YourKit 9.5.1 refused to load it, although the error disappeared so fast I couldn't read it. I notice that the snapshot appears to have been captured using YourKit 10.0.2, so I'll have to upgrade. Noting this for anyone else who wants to read the snapshot.
Created attachment 208322 [details] screenshot
After upgrading YourKit, I noticed from the telemetry snapshot that thread http-bio-8080-exec-9 presumably processed the page load as it clocked up about 34.5 seconds in the "Call tree (by thread) view". Sorting the methods on "Own Time (ms)" shows org.eclipse.osgi.framework.internal.core.BundleHost.getResource(String) consumes over 24 seconds of the 34.5 seconds. (see the attached screenshot). Although the hotspots observed in the bug description these obviously match the host spots view in the telemetry snapshot, they seem to indicate resource lookup as the costly process. So I'm wondering if the scanning for JSPs is having to crack open all the JARs on the bundle classpath. Please could you provide a list of the JARs in WEB-INF/lib to give some indication of the overhead of the likely search.
I should have written: "Although the hotspots observed in the bug description don't obviously match the host spots view in the telemetry snapshot, ..."
Hi Preethi Any update on this bug? We are not going to be able to do much about it unless we can either find out more about your problem web app or, ideally, get hold of a suitable test to reproduce the problem. Regards, Glyn
Created attachment 208488 [details] jar files in WEB-INF/lib
Hi Glyn, Thanks for taking the effort to look at the snapshot. There were 115 jars in the WEB-INF/lib. I have attached the list. On another note, would precompiling the jsps help? I tried this with maven-jspc plugin the tomcat 6 jasper jar but that didn't work. Which is the right jar to use? Thanks, Preethi
(In reply to comment #8) > Hi Glyn, > > Thanks for taking the effort to look at the snapshot. > > There were 115 jars in the WEB-INF/lib. I have attached the list. So it seems plausible that it is the large number and combined size of those JARs which is slowing things down so badly. Would it be possible for you to make available a version of the WAR file that demonstrates the problem so we can debug with it to see if any performance improvements are feasible? Converting to a WAB and moving those JARs out as dependent bundles should improve things. > > On another note, would precompiling the jsps help? I tried this with maven-jspc > plugin the tomcat 6 jasper jar but that didn't work. Which is the right jar to > use? Unfortunately, I have no experience in that area, but I'll ask around. Would precompiling the JSPs prevent the scanning happening I wonder? > > Thanks, > Preethi
Hello, About JSP pre-compilation: - you can use "ant" - http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html#Web_Application_Compilation - you can use "maven" - http://mojo.codehaus.org/jspc-maven-plugin/usage.html Can you try that and tell us what's the result Regards Violeta
Also can we try to increase the value for "osgi.bundlefile.limit" [1] Go to "Virgo-Home/lib/org.eclipse.virgo.kernel.launch.properties" and add for example "osgi.bundlefile.limit=200" Then reproduce the issue and tell us whether there is some effect or no. [1] http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html
Hi Violeta, Sorry for replying so late. But setting the osgi.bundlefile.limit to 200 seems to work! This has reduced the page load time to 3 secs! Thanks a lot, Preethi
That's great. I will document this property for future references. Regards Violeta
Documented in User Guide Commit id ecbf914b4e5a8a3ca8df871c7ca221747fc43c17
