[core] ClassLoaderResourceLoader.getLibraryVersion(String) performace
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
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 martin.k...@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
Hi Created MYFACES-2538 Remove resourceVersion and libraryVersion from resource identifiers. regards, Leonardo Uribe 2010/2/5 Leonardo Uribe lu4...@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 martin.k...@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
-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 lu4...@gmail.com wrote: Hi Created MYFACES-2538 Remove resourceVersion and libraryVersion from resource identifiers. regards, Leonardo Uribe 2010/2/5 Leonardo Uribe lu4...@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 martin.k...@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
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 mat...@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 lu4...@gmail.com wrote: Hi Created MYFACES-2538 Remove resourceVersion and libraryVersion from resource identifiers. regards, Leonardo Uribe 2010/2/5 Leonardo Uribe lu4...@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 martin.k...@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
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 lu4...@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 mat...@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 lu4...@gmail.com wrote: Hi Created MYFACES-2538 Remove resourceVersion and libraryVersion from resource identifiers. regards, Leonardo Uribe 2010/2/5 Leonardo Uribe lu4...@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 martin.k...@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
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 lu4...@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 mat...@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 lu4...@gmail.com wrote: Hi Created MYFACES-2538 Remove resourceVersion and libraryVersion from resource identifiers. regards, Leonardo Uribe 2010/2/5 Leonardo Uribe lu4...@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 martin.k...@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
