Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 364847

Summary: First page load takes a long time
Product: [RT] Virgo Reporter: Preethi <preethidasa>
Component: runtimeAssignee: Violeta Georgieva <milesg78>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: glyn.normington, milesg78
Version: 3.0.1.RELEASE   
Target Milestone: 3.6.0.M05   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
screenshot
none
jar files in WEB-INF/lib none

Description Preethi CLA 2011-11-25 10:23:03 EST
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
Comment 1 Preethi CLA 2011-11-25 10:24:41 EST
Here is the link to the Yourkit CPU telemetry snapshot: mediafire.com/?m48qqaat9rh8wea
Comment 2 Glyn Normington CLA 2011-12-13 10:39:48 EST
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.
Comment 3 Glyn Normington CLA 2011-12-13 11:49:47 EST
Created attachment 208322 [details]
screenshot
Comment 4 Glyn Normington CLA 2011-12-13 11:59:14 EST
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.
Comment 5 Glyn Normington CLA 2011-12-13 12:00:08 EST
I should have written:

"Although the hotspots observed in the bug description don't obviously match the
host spots view in the telemetry snapshot, ..."
Comment 6 Glyn Normington CLA 2011-12-16 07:01:10 EST
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
Comment 7 Preethi CLA 2011-12-16 07:20:08 EST
Created attachment 208488 [details]
jar files in WEB-INF/lib
Comment 8 Preethi CLA 2011-12-16 07:21:53 EST
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
Comment 9 Glyn Normington CLA 2011-12-16 07:27:37 EST
(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
Comment 10 Violeta Georgieva CLA 2011-12-19 09:16:09 EST
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
Comment 11 Violeta Georgieva CLA 2011-12-19 09:34:19 EST
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
Comment 12 Preethi CLA 2012-01-04 04:58:35 EST
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
Comment 13 Violeta Georgieva CLA 2012-01-04 05:33:07 EST
That's great.
I will document this property for future references.

Regards
Violeta
Comment 14 Violeta Georgieva CLA 2012-11-28 15:03:25 EST
Documented in User Guide
Commit id ecbf914b4e5a8a3ca8df871c7ca221747fc43c17