I'm not sure, but I doubt the mailing list supports attachments.
Maybe you could provide a link to some image hosting site?

My first thought, reflection is darn cheap, especially since Java 5
and even more since Java 6. I'm no IBM JVM specialist, but I don't
think there are major differences with HotSpot... Compared with SQL
queries, backend transactions, web service calls, etc. reflective
method invocations really don't make a difference.

Having said that, what kind of application are you testing? Does this
application have any I/O, locking or other expensive things that may
be the cause of the CPU-time imbalance?

Also, what kind of load are you simulating on your application? Long
sessions with not much users? Lots of short sessions? Hyperactive
users without any pauses?

/JK

Ps. How did you configure your profiler? Sampling or
tracing/instrumentation? Although I don't think it makes a difference
in this case, sampling is less accurate...


2010/1/8 Ravi Kapoor <[email protected]>:
>
> The actual call to getter method is only using 2% CPU. Rest 38% is being
> used within trinidad classes.
> I am attaching two screenshots to give you more details.
>
> In first screenshot, you can see at the top left corner, total CPU units
> taken by getProperty are 32391
> getProperty calls javax.faces.el.ValueBinding.getValue which calls
> org.apache.myfaces.el.PropertyResolverImpl.getValue which calls
> org.apache.myfaces.el.PropertyResolverImpl.getProperty which calls
> java.lang.reflect.Method.invoke.
>
> In second screenshot you can see that Method.invoke is using only 1781 units
> of CPU. Rest of the time is being spent within trinidad classes.
>
> Does this help? Also the rest of trinidad using 45% CPU usage is also highly
> concerning.
>
> Thanks
> Ravi
>
>
> On Fri, Jan 8, 2010 at 1:47 PM, Jan-Kees van Andel
> <[email protected]> wrote:
>>
>> Hey,
>>
>> Is it possible that the getProperty indirectly invokes some expensive
>> computation? For example, do you have lots of logic inside your
>> getters?
>>
>> Regards,
>> Jan-Kees
>>
>>
>> 2010/1/8 Ravi Kapoor <[email protected]>:
>> > Hi Matthias,
>> >
>> > Here are the details:
>> >
>> > Server: Websphere 6.1
>> >
>> > Trinidad version: 1.0.7  (We cant upgrade to 2.0 until we upgrade
>> > websphere
>> > which will happen in due course. Even then if this issue has not been
>> > addressed, the problem may exist in 2.0 as well.)
>> >
>> > OS: Windows (Even though I am measuring numbers on windows but I do not
>> > think this is OS specific)
>> >
>> >
>> > Let me know if you need to know anything else.
>> >
>> > Regards
>> > Ravi
>> >
>> >
>> >
>> > On Fri, Jan 8, 2010 at 1:09 AM, Matthias Wessendorf
>> > <[email protected]>wrote:
>> >
>> >> Hello Ravi,
>> >>
>> >> some more background would be good, e.g. what version of Trinidad etc.
>> >>
>> >> -Matthias
>> >>
>> >> On Thu, Jan 7, 2010 at 11:25 PM, Ravi Kapoor <[email protected]>
>> >> wrote:
>> >> > Has anybody done performance tests on trinidad application. I have an
>> >> > application and it appears that it is taking 80-90% of CPU in my
>> >> > application, thus killing performance.
>> >> >
>> >> > We ran load tests and our CPU went to 100% usage. At this point we
>> >> measured
>> >> > how much time was being taken by each class/method. Here are some
>> >> > interesting figures:
>> >> >
>> >> > CPU usage by all Trinidad + myfaces classes = 80-90%
>> >> > Myfaces CPU usage (without trinidad) = 8% (which implies trinidad is
>> >> taking
>> >> > 70-80% of CPU)
>> >> > Total time taken by one method
>> >> > (org.apache.myfaces.trinidad.bean.FacesBeanImpl.getProperty) = 40%
>> >> >
>> >> > Can anybody confirm that they have seen this behavior?
>> >> > Or if somebody can confirm that this does not happen in their
>> >> > performance
>> >> > tests, that should help too.
>> >> >
>> >> > Thanks
>> >> > Ravi
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Matthias Wessendorf
>> >>
>> >> blog: http://matthiaswessendorf.wordpress.com/
>> >> sessions: http://www.slideshare.net/mwessendorf
>> >> twitter: http://twitter.com/mwessendorf
>> >>
>> >
>
>

Reply via email to