Reducing resource loading

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Reducing resource loading

Adrian Baker
Running a sampling profiler against Orbeon running under OSGi showed a lot of time (~30%) spent in java.util.zip.ZipEntry, it seemed a lot of time is spent re-retrieving resources from inside jars (perhaps this is more expensive when they are inside OSGi bundles, I'm not sure).

This tracked back to a couple of places in Orbeon:

1. Although the org.orbeon.oxf.resources.ResourceManagerBase class has some optimisation for caching lastModified values, there is no such handling for exists(). Every exists() call retrieves the resource input stream. My local workaround was to implement a custom resource handler which cached the results of the exists() call.

2. Creating Castor mapping objects seems to instantiate a new parser which also seems to load some resource. This was showing up for us in a call from the ScopeGenerator#fillOutState, because our input config didn't have any mappings, and the mapping is constructed anew every time:

        if (getConnectedInputs().get(INPUT_MAPPING) == null) {
                mapping = new Mapping();
                mapping.loadMapping(new InputSource(new StringReader("<mapping/>")));

Simply adding this input to the scope generator call:
 
  <p:input name="mapping"><mapping/></p:input>

avoided the problem because in this the parsed mapping is wrapped in a CacheableInputReader.

These two simple changes reduced the elapsed time in Orbeon significantly (about 350ms to 250ms), though I could be running in an environment where java.util.zip.ZipEntry is particularly expensive.
Reply | Threaded
Open this post in threaded view
|

Re: Reducing resource loading

Adrian Baker
The Castor issue also shows up in org.orbeon.oxf.xforms.function.xxforms.XXFormsGetScopeAttribute: unless you are putting instances of org.orbeon.saxon.value.AtomicValue into your request attributes/sessions, every call to xxforms:get-request-attribute or xxforms:get-session-attribute results in

        final Mapping mapping = new Mapping();
        mapping.loadMapping(new InputSource(new StringReader("<mapping/>")));

Which again seems to be expensive.

Our workaround was to wrap our request attributes (which were just strings) in AtomicValues.
Reply | Threaded
Open this post in threaded view
|

Re: Reducing resource loading

Erik Bruchez
Administrator
In reply to this post by Adrian Baker
Adrian,

Thanks for this feedback.

We have recently also observed with a profiler a case where exists()
was taking more time than needed.

I have entered an RFE for this one:

http://forge.ow2.org/tracker/index.php?func=detail&aid=316230&group_id=168&atid=350207

-Erik

On Tue, Oct 18, 2011 at 12:39 PM, Adrian Baker
<[hidden email]> wrote:

> Running a sampling profiler against Orbeon running under OSGi showed a lot of
> time (~30%) spent in java.util.zip.ZipEntry, it seemed a lot of time is
> spent re-retrieving resources from inside jars (perhaps this is more
> expensive when they are inside OSGi bundles, I'm not sure).
>
> This tracked back to a couple of places in Orbeon:
>
> 1. Although the org.orbeon.oxf.resources.ResourceManagerBase class has some
> optimisation for caching lastModified values, there is no such handling for
> exists(). Every exists() call retrieves the resource input stream. My local
> workaround was to implement a custom resource handler which cached the
> results of the exists() call.
>
> 2. Creating Castor mapping objects seems to instantiate a new parser which
> also seems to load some resource. This was showing up for us in a call from
> the ScopeGenerator#fillOutState, because our input config didn't have any
> mappings, and the mapping is constructed anew every time:
>
>        if (getConnectedInputs().get(INPUT_MAPPING) == null) {
>                mapping = new Mapping();
>                mapping.loadMapping(new InputSource(new StringReader("<mapping/>")));
>
> Simply adding this input to the scope generator call:
>
>  <p:input name="mapping"><mapping/></p:input>
>
> avoided the problem because in this the parsed mapping is wrapped in a
> CacheableInputReader.
>
> These two simple changes reduced the elapsed time in Orbeon significantly
> (about 350ms to 250ms), though I could be running in an environment where
> java.util.zip.ZipEntry is particularly expensive.
>
> --
> View this message in context: http://orbeon-forms-ops-users.24843.n4.nabble.com/Reducing-resource-loading-tp3916572p3916572.html
> Sent from the Orbeon Forms (ops-users) mailing list archive at Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>
>


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws