You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Leonardo Uribe <lu...@gmail.com> on 2010/02/05 17:13:50 UTC

Re: [core] ClassLoaderResourceLoader.getLibraryVersion(String) performace

Hi

Yes, that one is a big problem. There is no way to "traverse" a jar file
without iterating over all entries to get the library version and resource
version. That means the current algorithm do that all times a resource is
rendered. This is really bad.

I remember someone commented that on jsr-314-open at jcp.org mailing list,
and checking the latest ri code (2.0.2-b10), library and resource version
feature was removed. It seems a decision was taken there.

Checking more, the topic describing this is:

[jsr-314-open] Need guidance: invalid assumptions in design of resource
versioning feature

We should change our algorithm too to prevent this performance problem.

regards,

Leonardo Uribe

2010/2/5 Martin Koci <ma...@aura.cz>

> Hi,
>
> during  profiling YourKitProfiler always marks
> org.apache.myfaces.resource.ClassLoaderResourceLoader.getLibraryVersion(String)
> as hotspot - that method always takes 30--50% CPU time per one
> request/response. Is it a known problem? I will provide more information
> later.
>
> Regards,
>
> Martin Kočí
>
>
>
>
>

Re: [core] ClassLoaderResourceLoader.getLibraryVersion(String) performace

Posted by Martin Koci <ma...@aura.cz>.
I can confirm that problem was really in getLibraryVersion() - after few
hours of profiling (with simulation of 10 concurrent users) profiler
shows that JarEntry.nextElement() in was called over 300 000 000 times
(!) and getLibraryVersion() was total winner in cumulative time category
within org.apache packages.

Now with current trunk problem is gone and database queries are again my
prime time hogs ;-) 

Thanks,

Martin Kočí

Matthias Wessendorf píše v Pá 05. 02. 2010 v 18:20 +0100:
> Ah, ok :)
> 
> I am interested in what Martin comes up, regarding details.
> Hopefully it is only "getLibraryVersion(...)" ;-)
> 
> -Matthias
> 
> On Fri, Feb 5, 2010 at 6:09 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> > Hi
> >
> > The code that serve resources on myfaces core comes from trinidad. There was
> > also other parts that comes from there too.
> >
> > Leonardo Uribe
> >
> > 2010/2/5 Matthias Wessendorf <ma...@apache.org>
> >>
> >> -hi,
> >>
> >> has one checked what Trinidad is offering for that ?
> >> I mean the code is pretty old (and therefore stable).
> >> Also at Oracle there is quite some PREF testing done...
> >>
> >> -Matthias
> >>
> >> On Fri, Feb 5, 2010 at 5:38 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> >> > Hi
> >> >
> >> > Created MYFACES-2538 Remove resourceVersion and libraryVersion from
> >> > resource
> >> > identifiers.
> >> >
> >> > regards,
> >> >
> >> > Leonardo Uribe
> >> >
> >> > 2010/2/5 Leonardo Uribe <lu...@gmail.com>
> >> >>
> >> >> Hi
> >> >>
> >> >> Yes, that one is a big problem. There is no way to "traverse" a jar
> >> >> file
> >> >> without iterating over all entries to get the library version and
> >> >> resource
> >> >> version. That means the current algorithm do that all times a resource
> >> >> is
> >> >> rendered. This is really bad.
> >> >>
> >> >> I remember someone commented that on jsr-314-open at jcp.org mailing
> >> >> list,
> >> >> and checking the latest ri code (2.0.2-b10), library and resource
> >> >> version
> >> >> feature was removed. It seems a decision was taken there.
> >> >>
> >> >> Checking more, the topic describing this is:
> >> >>
> >> >> [jsr-314-open] Need guidance: invalid assumptions in design of resource
> >> >> versioning feature
> >> >>
> >> >> We should change our algorithm too to prevent this performance problem.
> >> >>
> >> >> regards,
> >> >>
> >> >> Leonardo Uribe
> >> >>
> >> >> 2010/2/5 Martin Koci <ma...@aura.cz>
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> during  profiling YourKitProfiler always marks
> >> >>>
> >> >>>
> >> >>> org.apache.myfaces.resource.ClassLoaderResourceLoader.getLibraryVersion(String)
> >> >>> as hotspot - that method always takes 30--50% CPU time per one
> >> >>> request/response. Is it a known problem? I will provide more
> >> >>> information
> >> >>> later.
> >> >>>
> >> >>> Regards,
> >> >>>
> >> >>> Martin Kočí
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> twitter: http://twitter.com/mwessendorf
> >
> >
> 
> 
> 



Re: [core] ClassLoaderResourceLoader.getLibraryVersion(String) performace

Posted by Matthias Wessendorf <ma...@apache.org>.
Ah, ok :)

I am interested in what Martin comes up, regarding details.
Hopefully it is only "getLibraryVersion(...)" ;-)

-Matthias

On Fri, Feb 5, 2010 at 6:09 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi
>
> The code that serve resources on myfaces core comes from trinidad. There was
> also other parts that comes from there too.
>
> Leonardo Uribe
>
> 2010/2/5 Matthias Wessendorf <ma...@apache.org>
>>
>> -hi,
>>
>> has one checked what Trinidad is offering for that ?
>> I mean the code is pretty old (and therefore stable).
>> Also at Oracle there is quite some PREF testing done...
>>
>> -Matthias
>>
>> On Fri, Feb 5, 2010 at 5:38 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>> > Hi
>> >
>> > Created MYFACES-2538 Remove resourceVersion and libraryVersion from
>> > resource
>> > identifiers.
>> >
>> > regards,
>> >
>> > Leonardo Uribe
>> >
>> > 2010/2/5 Leonardo Uribe <lu...@gmail.com>
>> >>
>> >> Hi
>> >>
>> >> Yes, that one is a big problem. There is no way to "traverse" a jar
>> >> file
>> >> without iterating over all entries to get the library version and
>> >> resource
>> >> version. That means the current algorithm do that all times a resource
>> >> is
>> >> rendered. This is really bad.
>> >>
>> >> I remember someone commented that on jsr-314-open at jcp.org mailing
>> >> list,
>> >> and checking the latest ri code (2.0.2-b10), library and resource
>> >> version
>> >> feature was removed. It seems a decision was taken there.
>> >>
>> >> Checking more, the topic describing this is:
>> >>
>> >> [jsr-314-open] Need guidance: invalid assumptions in design of resource
>> >> versioning feature
>> >>
>> >> We should change our algorithm too to prevent this performance problem.
>> >>
>> >> regards,
>> >>
>> >> Leonardo Uribe
>> >>
>> >> 2010/2/5 Martin Koci <ma...@aura.cz>
>> >>>
>> >>> Hi,
>> >>>
>> >>> during  profiling YourKitProfiler always marks
>> >>>
>> >>>
>> >>> org.apache.myfaces.resource.ClassLoaderResourceLoader.getLibraryVersion(String)
>> >>> as hotspot - that method always takes 30--50% CPU time per one
>> >>> request/response. Is it a known problem? I will provide more
>> >>> information
>> >>> later.
>> >>>
>> >>> Regards,
>> >>>
>> >>> Martin Kočí
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [core] ClassLoaderResourceLoader.getLibraryVersion(String) performace

Posted by Leonardo Uribe <lu...@gmail.com>.
Hi

The code that serve resources on myfaces core comes from trinidad. There was
also other parts that comes from there too.

Leonardo Uribe

2010/2/5 Matthias Wessendorf <ma...@apache.org>

> -hi,
>
> has one checked what Trinidad is offering for that ?
> I mean the code is pretty old (and therefore stable).
> Also at Oracle there is quite some PREF testing done...
>
> -Matthias
>
> On Fri, Feb 5, 2010 at 5:38 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> > Hi
> >
> > Created MYFACES-2538 Remove resourceVersion and libraryVersion from
> resource
> > identifiers.
> >
> > regards,
> >
> > Leonardo Uribe
> >
> > 2010/2/5 Leonardo Uribe <lu...@gmail.com>
> >>
> >> Hi
> >>
> >> Yes, that one is a big problem. There is no way to "traverse" a jar file
> >> without iterating over all entries to get the library version and
> resource
> >> version. That means the current algorithm do that all times a resource
> is
> >> rendered. This is really bad.
> >>
> >> I remember someone commented that on jsr-314-open at jcp.org mailing
> list,
> >> and checking the latest ri code (2.0.2-b10), library and resource
> version
> >> feature was removed. It seems a decision was taken there.
> >>
> >> Checking more, the topic describing this is:
> >>
> >> [jsr-314-open] Need guidance: invalid assumptions in design of resource
> >> versioning feature
> >>
> >> We should change our algorithm too to prevent this performance problem.
> >>
> >> regards,
> >>
> >> Leonardo Uribe
> >>
> >> 2010/2/5 Martin Koci <ma...@aura.cz>
> >>>
> >>> Hi,
> >>>
> >>> during  profiling YourKitProfiler always marks
> >>>
> >>>
> org.apache.myfaces.resource.ClassLoaderResourceLoader.getLibraryVersion(String)
> >>> as hotspot - that method always takes 30--50% CPU time per one
> >>> request/response. Is it a known problem? I will provide more
> information
> >>> later.
> >>>
> >>> Regards,
> >>>
> >>> Martin Kočí
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Re: [core] ClassLoaderResourceLoader.getLibraryVersion(String) performace

Posted by Matthias Wessendorf <ma...@apache.org>.
-hi,

has one checked what Trinidad is offering for that ?
I mean the code is pretty old (and therefore stable).
Also at Oracle there is quite some PREF testing done...

-Matthias

On Fri, Feb 5, 2010 at 5:38 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi
>
> Created MYFACES-2538 Remove resourceVersion and libraryVersion from resource
> identifiers.
>
> regards,
>
> Leonardo Uribe
>
> 2010/2/5 Leonardo Uribe <lu...@gmail.com>
>>
>> Hi
>>
>> Yes, that one is a big problem. There is no way to "traverse" a jar file
>> without iterating over all entries to get the library version and resource
>> version. That means the current algorithm do that all times a resource is
>> rendered. This is really bad.
>>
>> I remember someone commented that on jsr-314-open at jcp.org mailing list,
>> and checking the latest ri code (2.0.2-b10), library and resource version
>> feature was removed. It seems a decision was taken there.
>>
>> Checking more, the topic describing this is:
>>
>> [jsr-314-open] Need guidance: invalid assumptions in design of resource
>> versioning feature
>>
>> We should change our algorithm too to prevent this performance problem.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2010/2/5 Martin Koci <ma...@aura.cz>
>>>
>>> Hi,
>>>
>>> during  profiling YourKitProfiler always marks
>>>
>>> org.apache.myfaces.resource.ClassLoaderResourceLoader.getLibraryVersion(String)
>>> as hotspot - that method always takes 30--50% CPU time per one
>>> request/response. Is it a known problem? I will provide more information
>>> later.
>>>
>>> Regards,
>>>
>>> Martin Kočí
>>>
>>>
>>>
>>>
>>
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [core] ClassLoaderResourceLoader.getLibraryVersion(String) performace

Posted by Leonardo Uribe <lu...@gmail.com>.
Hi

Created MYFACES-2538 Remove resourceVersion and libraryVersion from resource
identifiers.

regards,

Leonardo Uribe

2010/2/5 Leonardo Uribe <lu...@gmail.com>

> Hi
>
> Yes, that one is a big problem. There is no way to "traverse" a jar file
> without iterating over all entries to get the library version and resource
> version. That means the current algorithm do that all times a resource is
> rendered. This is really bad.
>
> I remember someone commented that on jsr-314-open at jcp.org mailing list,
> and checking the latest ri code (2.0.2-b10), library and resource version
> feature was removed. It seems a decision was taken there.
>
> Checking more, the topic describing this is:
>
> [jsr-314-open] Need guidance: invalid assumptions in design of resource
> versioning feature
>
> We should change our algorithm too to prevent this performance problem.
>
> regards,
>
> Leonardo Uribe
>
> 2010/2/5 Martin Koci <ma...@aura.cz>
>
> Hi,
>>
>> during  profiling YourKitProfiler always marks
>> org.apache.myfaces.resource.ClassLoaderResourceLoader.getLibraryVersion(String)
>> as hotspot - that method always takes 30--50% CPU time per one
>> request/response. Is it a known problem? I will provide more information
>> later.
>>
>> Regards,
>>
>> Martin Kočí
>>
>>
>>
>>
>>
>