RE: Spring FilterSecurityInterceptor not been called for myfaces forwards
To add if you see the spring security application config, I have the following set: The URL for the outcome to be forwarded to matches the second interceptor pattern which is "/jsp/operations/user/operationsLanding.iface" However what the filter receives is "/jsp/secure/hprelanding.jspx" which is the old URL from where the control is being forwarded. This is not how it happens when using jsp:forward. Regards, Madhav -Original Message- >From: Madhav Bhargava > >Hi Michael, > >Following are the servlet mappings: > > > Faces Servlet > *.faces > > > > Faces Servlet > *.jspx > > > > > Persistent Faces Servlet > *.iface > > >The navigation case in faces-config.xml is: > > > > OPERATION_LANDING > > /jsp/operations/user/operationsLanding.iface > > > >This has been configured as per the icefaces documentation. If we disregard >spring security filter issue the >forward happens properly. Spring security >filter gets invoked once after the return "OPERATION_LANDING" from >within the >action method has been executed. The strange part is that the URL is still the >previous one. > >It is strange because when using jsp:forward from index.jsp to login.jsp >spring security filter gets both the >URL's. > >What could be the issue? > >Regards, >Madhav > > >From: Michael Kurz [mailto:michi.k...@gmx.at] >Hi, > >which mapping do you use for your faces servlet: postfix (like *.jsf) or >prefix (like /faces/*)? Maybe the "real" JSF urls are not listed in your >intercepter config. > >regards >Michael > >Madhav Bhargava schrieb: > Hi All, > > I am using myfaces 1.1, icefaces 1.8.1, spring 2.5.6, spring security -2.0.5, > WAS 6.0 (app server) > > I have configured spring security for my JSF application along with > SiteMinder as an external authentication mechanism. It works fine till a > forward happens from within myfaces. > > Here is my spring servlet filter chain declaration: > > > Spring delegating filter which will initiate > the spring > security filter chain > > springSecurityFilterChain > springSecurityFilterChain > > > org.springframework.web.filter.DelegatingFilterProxy > > > > > springSecurityFilterChain > /* > FORWARD > REQUEST > > > And in my spring application context I have followed the advice from spring > forums and done necessary settings: > Excerpt is: > > entry-point-ref="preAuthenticatedProcessingFilterEntryPoint" > once-per-request="false"> > > > filters="none"/> > filters="none"/> > > > > access="ROLE_USER" /> > access="ROLE_OPERATIONS"/> > access="IS_AUTHENTICATED_ANONYMOUSLY" /> > > > Now when I forward a request from index.jsp to login.jsp then the spring > filters are called with the login.jsp URL even though the browser shows the > old URL. > > However when from within an action method a navigation case is handled then > it is not intercepted by the spring filters at all. However if I give a > then it is properly intercepted with the correct URL as expected. > > What can be the reason? > > Regards, > Madhav >
RE: Spring FilterSecurityInterceptor not been called for myfaces forwards
Hi Michael, Following are the servlet mappings: Faces Servlet *.faces Faces Servlet *.jspx Persistent Faces Servlet *.iface The navigation case in faces-config.xml is: OPERATION_LANDING /jsp/operations/user/operationsLanding.iface This has been configured as per the icefaces documentation. If we disregard spring security filter issue the forward happens properly. Spring security filter gets invoked once after the return "OPERATION_LANDING" from within the action method has been executed. The strange part is that the URL is still the previous one. It is strange because when using jsp:forward from index.jsp to login.jsp spring security filter gets both the URL's. What could be the issue? Regards, Madhav From: Michael Kurz [mailto:michi.k...@gmx.at] >Hi, > >which mapping do you use for your faces servlet: postfix (like *.jsf) or >prefix (like /faces/*)? Maybe the "real" JSF urls are not listed in your >intercepter config. > >regards >Michael > >Madhav Bhargava schrieb: > Hi All, > > I am using myfaces 1.1, icefaces 1.8.1, spring 2.5.6, spring security -2.0.5, > WAS 6.0 (app server) > > I have configured spring security for my JSF application along with > SiteMinder as an external authentication mechanism. It works fine till a > forward happens from within myfaces. > > Here is my spring servlet filter chain declaration: > > > Spring delegating filter which will initiate > the spring > security filter chain > > springSecurityFilterChain > springSecurityFilterChain > > > org.springframework.web.filter.DelegatingFilterProxy > > > > > springSecurityFilterChain > /* > FORWARD > REQUEST > > > And in my spring application context I have followed the advice from spring > forums and done necessary settings: > Excerpt is: > > entry-point-ref="preAuthenticatedProcessingFilterEntryPoint" > once-per-request="false"> > > > filters="none"/> > filters="none"/> > > > > access="ROLE_USER" /> > access="ROLE_OPERATIONS"/> > access="IS_AUTHENTICATED_ANONYMOUSLY" /> > > > Now when I forward a request from index.jsp to login.jsp then the spring > filters are called with the login.jsp URL even though the browser shows the > old URL. > > However when from within an action method a navigation case is handled then > it is not intercepted by the spring filters at all. However if I give a > then it is properly intercepted with the correct URL as expected. > > What can be the reason? > > Regards, > Madhav > CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS***
Re: Spring FilterSecurityInterceptor not been called for myfaces forwards
Hi, which mapping do you use for your faces servlet: postfix (like *.jsf) or prefix (like /faces/*)? Maybe the "real" JSF urls are not listed in your intercepter config. regards Michael Madhav Bhargava schrieb: Hi All, I am using myfaces 1.1, icefaces 1.8.1, spring 2.5.6, spring security -2.0.5, WAS 6.0 (app server) I have configured spring security for my JSF application along with SiteMinder as an external authentication mechanism. It works fine till a forward happens from within myfaces. Here is my spring servlet filter chain declaration: Spring delegating filter which will initiate the spring security filter chain springSecurityFilterChain springSecurityFilterChain org.springframework.web.filter.DelegatingFilterProxy springSecurityFilterChain /* FORWARD REQUEST And in my spring application context I have followed the advice from spring forums and done necessary settings: Excerpt is: Now when I forward a request from index.jsp to login.jsp then the spring filters are called with the login.jsp URL even though the browser shows the old URL. However when from within an action method a navigation case is handled then it is not intercepted by the spring filters at all. However if I give a then it is properly intercepted with the correct URL as expected. What can be the reason? Regards, Madhav
RE: Spring FilterSecurityInterceptor not been called for myfaces forwards
Thanks for your response Jakob. What you have mentioned is already known to me. That is the reason I have put a FORWARD For Spring security filter. I should have made it a little more clear. Apologies for that. The forward from index.jsp to login.jsp is via . These are not JSF pages. This forward is captured by Spring security filter. However when a forward happens from within JSF via NavigationHandler then this forward is not caught by spring security filter. I am not sure why a jsp:forward forward will be caught every time and not when done via myfaces. So essentially I not worried about browser showing me the previous URL because that is an expected behavior but the new URL is always caught by the filter which in my case is the exact problem. Regards, Madhav >-Original Message- >From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf >Of Jakob Korherr >Sent: Tuesday, January 12, 2010 4:21 AM >To: MyFaces Discussion >Subject: Re: Spring FilterSecurityInterceptor not been called for myfaces >forwards > >Hi Madhav, > >JSF always submits back to the original view, if you hit a h:commandButton >or h:commandLink. So if you are on index.jsp and hit for example a >h:commandLink, you will get a request for index.jsp. However, after the >action method on the server is finished, the server renders the new view, >depending on the outcome of the action method, in your case login.jsp. But >your browser still displays index.jsp in the address bar, because that was >the page you requested. > >When you add in the faces-config, JSF will instead of just >rendering the new view, redirect to it. Thus you have a second http round >trip and your browser's address bar will display the new view. > >I hope this explains things. > >Regards, >Jakob Korherr 2010/1/11 Madhav Bhargava > Hi All, > > I am using myfaces 1.1, icefaces 1.8.1, spring 2.5.6, spring security > -2.0.5, WAS 6.0 (app server) > > I have configured spring security for my JSF application along with > SiteMinder as an external authentication mechanism. It works fine till a > forward happens from within myfaces. > > Here is my spring servlet filter chain declaration: > > >Spring delegating filter which will initiate > the spring >security filter chain > >springSecurityFilterChain >springSecurityFilterChain > > > org.springframework.web.filter.DelegatingFilterProxy > > > > >springSecurityFilterChain >/* >FORWARD >REQUEST > > > And in my spring application context I have followed the advice from spring > forums and done necessary settings: > Excerpt is: > > entry-point-ref="preAuthenticatedProcessingFilterEntryPoint" > once-per-request="false"> > /> > /> > filters="none"/> > filters="none"/> > filters="none"/> > > filters="none"/> > access="ROLE_USER" /> > access="ROLE_OPERATIONS"/> > access="IS_AUTHENTICATED_ANONYMOUSLY" /> > > > Now when I forward a request from index.jsp to login.jsp then the spring > filters are called with the login.jsp URL even though the browser shows the > old URL. > > However when from within an action method a navigation case is handled then > it is not intercepted by the spring filters at all. However if I give a > then it is properly intercepted with the correct URL as > expected. > > What can be the reason? > > Regards, > Madhav >
Re: [Trinidad] Trinidad consuming 80-90% CPU
Richard, So basically your system can handle 18.5 pages/CPU/second. I can only wish we could get that kind of throughput. We can only get 2 page/CPU/second or so. If you can get that kind of performance, I wonder what is wrong with our environment. I think I need a good night sleep and recharge my batteries to think again in the morning. Good Night. - Ravi Richard Yee wrote: Our servers are made by Sun and have 4 AMD Opteron processessors with 16GB RAM. We are running in a cluster of 3 servers. -Richard On Mon, Jan 11, 2010 at 12:54 PM, Ravi Kapoor wrote: Thanks Richard for the numbers. Can you also mention no of servers used, CPU and memory details of each server? Regards Ravi On Mon, Jan 11, 2010 at 3:00 PM, Richard Yee wrote: Ravi, We have load tested our Trinidad application with up to 800,000 page loads/hr. and the application handled it fine. We have also simulated up to 190 concurrent users. We are using MyFaces 1.1.5 and Trinidad 1.0.5. We are using the Oracle Application Server 10GR3 and are running on Linux. -Richard On Fri, Jan 8, 2010 at 3:12 PM, Ravi Kapoor wrote: I have 2 GB on the machine and it only uses 1 GB. Can you give details on your environment. Especially trinidad version, CPU details and how many users per JVM can you handle, what %age of CPU is consumed by trinidad etc Regards Ravi On Fri, Jan 8, 2010 at 4:08 PM, Richard Yee wrote: How much physical memory is on your testing machine? I have a few Trinidad applications in production and don't see any of the performance issues you are having. -Richard On Fri, Jan 8, 2010 at 12:33 PM, Jan-Kees van Andel < jankeesvanan...@gmail.com> wrote: 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 : 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 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 : 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 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 < ravikapoor...@gmail.com> 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 th
Re: [Trinidad] Trinidad consuming 80-90% CPU
Oh I see what you are saying. We only create and populate the hashmap once,
we never clear or delete from it. So that endless loop is not the problem.
Also in that case the CPU wouldnt show up for org.apache.* classes.
I guess you are looking for how to specify packages in VisualVM. This would
give me another point of reference to validate my numbers.
- Ravi
On Mon, Jan 11, 2010 at 6:00 PM, Jakob Korherr wrote:
> Ravi,
>
> To your question: Can you explain little bit how lack of synchronization
> can
> add to CPU?
>
> I don't know exactly, but maybe it is possible that the internal structure
> of a Map (e.g. HashMap) can be destroyed when there are multiple change
> operations (put, remove, clear) at the same time, because of lack of
> synchronization. But that's really just a guess!
>
> Regards,
> Jakob
>
> 2010/1/11 Ravi Kapoor
>
> > Jakob,
> >
> > I did install VisualVM but it is not capturing org.apache.* classes or
> > com.mycompany.* classes. I did not find a setting on how to enable
> > capturing
> > data for all the classes I want. Can you tell me where to specity the
> > packages for which I want to capture CPU usage?
> >
> > Vinay
> >
> >
> > On Mon, Jan 11, 2010 at 4:05 PM, Ravi Kapoor > >wrote:
> >
> > > Jakob,
> > >
> > > The beans are not big. Also these tests have been performed under a
> > single
> > > user to measure the CPU timing. So I doubt locking/synchronization is
> an
> > > issue.
> > >
> > > I would think that if there is synchronization, then the threads could
> be
> > > waiting for long time, but lack of synchronization can only lead to
> > corrupt
> > > data not to higher CPU. Can you explain little bit how lack of
> > > synchronization can add to CPU?
> > >
> > > I have never used VisualVM, I can try it sometime this week. I am
> > assuming
> > > it will work with Websphere 6.1
> > >
> > > Regards
> > > Ravi
> > >
> > >
> > > On Mon, Jan 11, 2010 at 3:03 PM, Jan-Kees van Andel <
> > > jankeesvanan...@gmail.com> wrote:
> > >
> > >> Hi Ravi,
> > >>
> > >> Just a stupid question. Are your beans extremely big? Since FacesBean
> > >> doesn't do much locking/synchronizing (none if I'm correctly), the
> > >> only reason I can imagine it to eat CPU cycles is because of its
> > >> size...
> > >>
> > >> Also, is it possible for you to do a profiling run using VisualVM?
> > >> I've been profiling Trinidad with VisualVM myself and maybe we can
> > >> compare numbers... Using the same tool might make it easier to
> > >> compare...
> > >>
> > >> /JK
> > >>
> > >>
> > >> 2010/1/11 Ravi Kapoor :
> > >> > I am thinking if that was the case, I would see high CPU in
> > >> > java.util.HashMap instead of org.apache.faces.*
> > >> >
> > >> > If you disagree, please explain and I can try using HashTable to
> store
> > >> data
> > >> > and get fresh numbers.
> > >> >
> > >> >
> > >> > On Mon, Jan 11, 2010 at 10:00 AM, Jakob Korherr <
> > >> jakob.korh...@gmail.com>wrote:
> > >> >
> > >> >> Maybe it happens when accessing the value from the Map with
> > >> >> "#{bean.get['memid']}", because the Map is not properly
> synchronized,
> > >> thus
> > >> >> its internal structure is broken and thus it is running in infinite
> > >> loops.
> > >> >>
> > >> >> Are your resources properly synchronized?
> > >> >>
> > >> >> Just a guess in the blue...
> > >> >>
> > >> >> Regards,
> > >> >> Jakob Korherr
> > >> >>
> > >> >> 2010/1/11 Ravi Kapoor
> > >> >>
> > >> >> > Another thing, most of our EL expressions are one of the
> following
> > >> types
> > >> >> >
> > >> >> > "#{bean.active}"
> > >> >> > or
> > >> >> > "#{bean.get['memid']}"
> > >> >> >
> > >> >> > Parsing of these expressions probably happens within
> > >> org.apache.myfaces.*
> > >> >> > classes. These are fairly basic EL expressions and should not be
> > >> taking
> > >> >> > much
> > >> >> > time. We know, the final getter method is not taking much time.
> > >> >> >
> > >> >> > Do you know if the page (and EL expressions) are parsed each time
> a
> > >> page
> > >> >> is
> > >> >> > rendered? If pages are parsed only once, then the parsing time
> > should
> > >> >> also
> > >> >> > be almost negligible.
> > >> >> >
> > >> >> > - Ravi
> > >> >> >
> > >> >> > On Mon, Jan 11, 2010 at 8:28 AM, Ravi
> > >> wrote:
> > >> >> >
> > >> >> > >
> > >> >> > > Matthias,
> > >> >> > >
> > >> >> > > If the issue is in bean, it should show up in my analysis. Also
> > >> >> > getProperty
> > >> >> > > is only 40% CPU, there is additional 45% cpu consumed by rest
> of
> > >> the
> > >> >> > > trinidad classes totaling 85% total CPU, all within
> > >> >> org.apache.myfaces.*
> > >> >> > > classes
> > >> >> > >
> > >> >> > > Ravi
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > > Matthias Wessendorf wrote:
> > >> >> > >
> > >> >> > >> Ravi,
> > >> >> > >>
> > >> >> > >> spoke to a guy that does performance testing/improvement for
> > >> Oracle
> > >> >> > >> Applications. He said that there is some % CPU in Trindad but
> I
> > >> would
> > >> >> > >> not
Re: [Trinidad] Trinidad consuming 80-90% CPU
Ravi,
To your question: Can you explain little bit how lack of synchronization can
add to CPU?
I don't know exactly, but maybe it is possible that the internal structure
of a Map (e.g. HashMap) can be destroyed when there are multiple change
operations (put, remove, clear) at the same time, because of lack of
synchronization. But that's really just a guess!
Regards,
Jakob
2010/1/11 Ravi Kapoor
> Jakob,
>
> I did install VisualVM but it is not capturing org.apache.* classes or
> com.mycompany.* classes. I did not find a setting on how to enable
> capturing
> data for all the classes I want. Can you tell me where to specity the
> packages for which I want to capture CPU usage?
>
> Vinay
>
>
> On Mon, Jan 11, 2010 at 4:05 PM, Ravi Kapoor >wrote:
>
> > Jakob,
> >
> > The beans are not big. Also these tests have been performed under a
> single
> > user to measure the CPU timing. So I doubt locking/synchronization is an
> > issue.
> >
> > I would think that if there is synchronization, then the threads could be
> > waiting for long time, but lack of synchronization can only lead to
> corrupt
> > data not to higher CPU. Can you explain little bit how lack of
> > synchronization can add to CPU?
> >
> > I have never used VisualVM, I can try it sometime this week. I am
> assuming
> > it will work with Websphere 6.1
> >
> > Regards
> > Ravi
> >
> >
> > On Mon, Jan 11, 2010 at 3:03 PM, Jan-Kees van Andel <
> > jankeesvanan...@gmail.com> wrote:
> >
> >> Hi Ravi,
> >>
> >> Just a stupid question. Are your beans extremely big? Since FacesBean
> >> doesn't do much locking/synchronizing (none if I'm correctly), the
> >> only reason I can imagine it to eat CPU cycles is because of its
> >> size...
> >>
> >> Also, is it possible for you to do a profiling run using VisualVM?
> >> I've been profiling Trinidad with VisualVM myself and maybe we can
> >> compare numbers... Using the same tool might make it easier to
> >> compare...
> >>
> >> /JK
> >>
> >>
> >> 2010/1/11 Ravi Kapoor :
> >> > I am thinking if that was the case, I would see high CPU in
> >> > java.util.HashMap instead of org.apache.faces.*
> >> >
> >> > If you disagree, please explain and I can try using HashTable to store
> >> data
> >> > and get fresh numbers.
> >> >
> >> >
> >> > On Mon, Jan 11, 2010 at 10:00 AM, Jakob Korherr <
> >> jakob.korh...@gmail.com>wrote:
> >> >
> >> >> Maybe it happens when accessing the value from the Map with
> >> >> "#{bean.get['memid']}", because the Map is not properly synchronized,
> >> thus
> >> >> its internal structure is broken and thus it is running in infinite
> >> loops.
> >> >>
> >> >> Are your resources properly synchronized?
> >> >>
> >> >> Just a guess in the blue...
> >> >>
> >> >> Regards,
> >> >> Jakob Korherr
> >> >>
> >> >> 2010/1/11 Ravi Kapoor
> >> >>
> >> >> > Another thing, most of our EL expressions are one of the following
> >> types
> >> >> >
> >> >> > "#{bean.active}"
> >> >> > or
> >> >> > "#{bean.get['memid']}"
> >> >> >
> >> >> > Parsing of these expressions probably happens within
> >> org.apache.myfaces.*
> >> >> > classes. These are fairly basic EL expressions and should not be
> >> taking
> >> >> > much
> >> >> > time. We know, the final getter method is not taking much time.
> >> >> >
> >> >> > Do you know if the page (and EL expressions) are parsed each time a
> >> page
> >> >> is
> >> >> > rendered? If pages are parsed only once, then the parsing time
> should
> >> >> also
> >> >> > be almost negligible.
> >> >> >
> >> >> > - Ravi
> >> >> >
> >> >> > On Mon, Jan 11, 2010 at 8:28 AM, Ravi
> >> wrote:
> >> >> >
> >> >> > >
> >> >> > > Matthias,
> >> >> > >
> >> >> > > If the issue is in bean, it should show up in my analysis. Also
> >> >> > getProperty
> >> >> > > is only 40% CPU, there is additional 45% cpu consumed by rest of
> >> the
> >> >> > > trinidad classes totaling 85% total CPU, all within
> >> >> org.apache.myfaces.*
> >> >> > > classes
> >> >> > >
> >> >> > > Ravi
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > Matthias Wessendorf wrote:
> >> >> > >
> >> >> > >> Ravi,
> >> >> > >>
> >> >> > >> spoke to a guy that does performance testing/improvement for
> >> Oracle
> >> >> > >> Applications. He said that there is some % CPU in Trindad but I
> >> would
> >> >> > >> not give it more them 20%. The heavy hitters is getClientId
> (Blake
> >> -
> >> >> > >> see dev@ thread - is doing some optimization there).
> >> >> > >>
> >> >> > >> Now if getProperty is some el expression and expression is
> >> expensive
> >> >> > >> the problem is in expression not in Trinidad (perhaps that is
> the
> >> case
> >> >> > >> where you have el epression but beans behind it are not that
> >> good).
> >> >> > >>
> >> >> > >> -Matthias
> >> >> > >>
> >> >> > >> On Mon, Jan 11, 2010 at 6:45 AM, Ravi Kapoor <
> >> ravikapoor...@gmail.com
> >> >> >
> >> >> > >> wrote:
> >> >> > >>
> >> >> > >>> Hi Jan-Kees,
> >> >> > >>>
> >> >> > >>> You are right, the getProperty method is only taking 2K units.
> >> >> Ho
Re: Spring FilterSecurityInterceptor not been called for myfaces forwards
Hi Madhav, JSF always submits back to the original view, if you hit a h:commandButton or h:commandLink. So if you are on index.jsp and hit for example a h:commandLink, you will get a request for index.jsp. However, after the action method on the server is finished, the server renders the new view, depending on the outcome of the action method, in your case login.jsp. But your browser still displays index.jsp in the address bar, because that was the page you requested. When you add in the faces-config, JSF will instead of just rendering the new view, redirect to it. Thus you have a second http round trip and your browser's address bar will display the new view. I hope this explains things. Regards, Jakob Korherr 2010/1/11 Madhav Bhargava > Hi All, > > I am using myfaces 1.1, icefaces 1.8.1, spring 2.5.6, spring security > -2.0.5, WAS 6.0 (app server) > > I have configured spring security for my JSF application along with > SiteMinder as an external authentication mechanism. It works fine till a > forward happens from within myfaces. > > Here is my spring servlet filter chain declaration: > > >Spring delegating filter which will initiate > the spring >security filter chain > >springSecurityFilterChain >springSecurityFilterChain > > > org.springframework.web.filter.DelegatingFilterProxy > > > > >springSecurityFilterChain >/* >FORWARD >REQUEST > > > And in my spring application context I have followed the advice from spring > forums and done necessary settings: > Excerpt is: > > entry-point-ref="preAuthenticatedProcessingFilterEntryPoint" > once-per-request="false"> > /> > /> > filters="none"/> > filters="none"/> > filters="none"/> > > filters="none"/> > access="ROLE_USER" /> > access="ROLE_OPERATIONS"/> > access="IS_AUTHENTICATED_ANONYMOUSLY" /> > > > Now when I forward a request from index.jsp to login.jsp then the spring > filters are called with the login.jsp URL even though the browser shows the > old URL. > > However when from within an action method a navigation case is handled then > it is not intercepted by the spring filters at all. However if I give a > then it is properly intercepted with the correct URL as > expected. > > What can be the reason? > > Regards, > Madhav >
Re: [Trinidad] Trinidad consuming 80-90% CPU
Jakob,
I did install VisualVM but it is not capturing org.apache.* classes or
com.mycompany.* classes. I did not find a setting on how to enable capturing
data for all the classes I want. Can you tell me where to specity the
packages for which I want to capture CPU usage?
Vinay
On Mon, Jan 11, 2010 at 4:05 PM, Ravi Kapoor wrote:
> Jakob,
>
> The beans are not big. Also these tests have been performed under a single
> user to measure the CPU timing. So I doubt locking/synchronization is an
> issue.
>
> I would think that if there is synchronization, then the threads could be
> waiting for long time, but lack of synchronization can only lead to corrupt
> data not to higher CPU. Can you explain little bit how lack of
> synchronization can add to CPU?
>
> I have never used VisualVM, I can try it sometime this week. I am assuming
> it will work with Websphere 6.1
>
> Regards
> Ravi
>
>
> On Mon, Jan 11, 2010 at 3:03 PM, Jan-Kees van Andel <
> jankeesvanan...@gmail.com> wrote:
>
>> Hi Ravi,
>>
>> Just a stupid question. Are your beans extremely big? Since FacesBean
>> doesn't do much locking/synchronizing (none if I'm correctly), the
>> only reason I can imagine it to eat CPU cycles is because of its
>> size...
>>
>> Also, is it possible for you to do a profiling run using VisualVM?
>> I've been profiling Trinidad with VisualVM myself and maybe we can
>> compare numbers... Using the same tool might make it easier to
>> compare...
>>
>> /JK
>>
>>
>> 2010/1/11 Ravi Kapoor :
>> > I am thinking if that was the case, I would see high CPU in
>> > java.util.HashMap instead of org.apache.faces.*
>> >
>> > If you disagree, please explain and I can try using HashTable to store
>> data
>> > and get fresh numbers.
>> >
>> >
>> > On Mon, Jan 11, 2010 at 10:00 AM, Jakob Korherr <
>> jakob.korh...@gmail.com>wrote:
>> >
>> >> Maybe it happens when accessing the value from the Map with
>> >> "#{bean.get['memid']}", because the Map is not properly synchronized,
>> thus
>> >> its internal structure is broken and thus it is running in infinite
>> loops.
>> >>
>> >> Are your resources properly synchronized?
>> >>
>> >> Just a guess in the blue...
>> >>
>> >> Regards,
>> >> Jakob Korherr
>> >>
>> >> 2010/1/11 Ravi Kapoor
>> >>
>> >> > Another thing, most of our EL expressions are one of the following
>> types
>> >> >
>> >> > "#{bean.active}"
>> >> > or
>> >> > "#{bean.get['memid']}"
>> >> >
>> >> > Parsing of these expressions probably happens within
>> org.apache.myfaces.*
>> >> > classes. These are fairly basic EL expressions and should not be
>> taking
>> >> > much
>> >> > time. We know, the final getter method is not taking much time.
>> >> >
>> >> > Do you know if the page (and EL expressions) are parsed each time a
>> page
>> >> is
>> >> > rendered? If pages are parsed only once, then the parsing time should
>> >> also
>> >> > be almost negligible.
>> >> >
>> >> > - Ravi
>> >> >
>> >> > On Mon, Jan 11, 2010 at 8:28 AM, Ravi
>> wrote:
>> >> >
>> >> > >
>> >> > > Matthias,
>> >> > >
>> >> > > If the issue is in bean, it should show up in my analysis. Also
>> >> > getProperty
>> >> > > is only 40% CPU, there is additional 45% cpu consumed by rest of
>> the
>> >> > > trinidad classes totaling 85% total CPU, all within
>> >> org.apache.myfaces.*
>> >> > > classes
>> >> > >
>> >> > > Ravi
>> >> > >
>> >> > >
>> >> > >
>> >> > > Matthias Wessendorf wrote:
>> >> > >
>> >> > >> Ravi,
>> >> > >>
>> >> > >> spoke to a guy that does performance testing/improvement for
>> Oracle
>> >> > >> Applications. He said that there is some % CPU in Trindad but I
>> would
>> >> > >> not give it more them 20%. The heavy hitters is getClientId (Blake
>> -
>> >> > >> see dev@ thread - is doing some optimization there).
>> >> > >>
>> >> > >> Now if getProperty is some el expression and expression is
>> expensive
>> >> > >> the problem is in expression not in Trinidad (perhaps that is the
>> case
>> >> > >> where you have el epression but beans behind it are not that
>> good).
>> >> > >>
>> >> > >> -Matthias
>> >> > >>
>> >> > >> On Mon, Jan 11, 2010 at 6:45 AM, Ravi Kapoor <
>> ravikapoor...@gmail.com
>> >> >
>> >> > >> wrote:
>> >> > >>
>> >> > >>> Hi Jan-Kees,
>> >> > >>>
>> >> > >>> You are right, the getProperty method is only taking 2K units.
>> >> However
>> >> > if
>> >> > >>> I
>> >> > >>> dig deeper, I find that most of the cumulative time is being
>> spent
>> >> > within
>> >> > >>> Trinidad classes. The final call to java getters consumes
>> negligible
>> >> > >>> time.
>> >> > >>>
>> >> > >>> I was unable to create thread structure like you showed (JProbe
>> keeps
>> >> > >>> getting crashed). But I took another screenshot that shows almost
>> >> > similar
>> >> > >>> details you are looking for. It highlights the classes that are
>> >> taking
>> >> > >>> maximum time (cumulative time again) but as you can see, all the
>> >> > classes
>> >> > >>> are
>> >> > >>> just trinidad classes.
>> >> > >>>
>> >> > >>>
>> >> >
>> >>
>> http://docs
Re: [Trinidad] Trinidad consuming 80-90% CPU
Our servers are made by Sun and have 4 AMD Opteron processessors with 16GB RAM. We are running in a cluster of 3 servers. -Richard On Mon, Jan 11, 2010 at 12:54 PM, Ravi Kapoor wrote: > Thanks Richard for the numbers. Can you also mention no of servers used, > CPU > and memory details of each server? > > Regards > Ravi > > On Mon, Jan 11, 2010 at 3:00 PM, Richard Yee >wrote: > > > Ravi, > > We have load tested our Trinidad application with up to 800,000 page > > loads/hr. and the application handled it fine. We have also simulated up > to > > 190 concurrent users. We are using MyFaces 1.1.5 and Trinidad 1.0.5. We > are > > using the Oracle Application Server 10GR3 and are running on Linux. > > > > -Richard > > > > > > On Fri, Jan 8, 2010 at 3:12 PM, Ravi Kapoor > > wrote: > > > > > I have 2 GB on the machine and it only uses 1 GB. > > > > > > Can you give details on your environment. Especially trinidad version, > > CPU > > > details and how many users per JVM can you handle, what %age of CPU is > > > consumed by trinidad etc > > > > > > Regards > > > Ravi > > > > > > On Fri, Jan 8, 2010 at 4:08 PM, Richard Yee > > > wrote: > > > > > > > How much physical memory is on your testing machine? > > > > I have a few Trinidad applications in production and don't see any of > > the > > > > performance issues you are having. > > > > > > > > -Richard > > > > > > > > > > > > > > > > On Fri, Jan 8, 2010 at 12:33 PM, Jan-Kees van Andel < > > > > jankeesvanan...@gmail.com> wrote: > > > > > > > > > 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 : > > > > > > > > > > > > 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 > > > > > > 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 : > > > > > >> > 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 > > > > > >> > > > > > > >> > > > > >
Re: [Trinidad] Trinidad consuming 80-90% CPU
The memory 2GB is not much for a server but even that much is not being used
(due to CPU constraint).Max memory used is about 1.1GB or so when CPU has
hit 100%.
The numbers I posted are from my desktop (which has 4GB memory) as it is
easier to profile CPU on local desktop. The CPU usage is fairly high but I
do not have exact numbers.
On Mon, Jan 11, 2010 at 4:30 PM, Richard Yee wrote:
> Ravi,
> If you are running on Windows, what does the TaskManager show as the CPU
> utilization? How much memory is also being used? 2Gb is not much memory for
> a production application. I have that much on my desktop.
>
> -Richard
>
> On Mon, Jan 11, 2010 at 1:05 PM, Ravi Kapoor >wrote:
>
> > Jakob,
> >
> > The beans are not big. Also these tests have been performed under a
> single
> > user to measure the CPU timing. So I doubt locking/synchronization is an
> > issue.
> >
> > I would think that if there is synchronization, then the threads could be
> > waiting for long time, but lack of synchronization can only lead to
> corrupt
> > data not to higher CPU. Can you explain little bit how lack of
> > synchronization can add to CPU?
> >
> > I have never used VisualVM, I can try it sometime this week. I am
> assuming
> > it will work with Websphere 6.1
> >
> > Regards
> > Ravi
> >
> > On Mon, Jan 11, 2010 at 3:03 PM, Jan-Kees van Andel <
> > jankeesvanan...@gmail.com> wrote:
> >
> > > Hi Ravi,
> > >
> > > Just a stupid question. Are your beans extremely big? Since FacesBean
> > > doesn't do much locking/synchronizing (none if I'm correctly), the
> > > only reason I can imagine it to eat CPU cycles is because of its
> > > size...
> > >
> > > Also, is it possible for you to do a profiling run using VisualVM?
> > > I've been profiling Trinidad with VisualVM myself and maybe we can
> > > compare numbers... Using the same tool might make it easier to
> > > compare...
> > >
> > > /JK
> > >
> > >
> > > 2010/1/11 Ravi Kapoor :
> > > > I am thinking if that was the case, I would see high CPU in
> > > > java.util.HashMap instead of org.apache.faces.*
> > > >
> > > > If you disagree, please explain and I can try using HashTable to
> store
> > > data
> > > > and get fresh numbers.
> > > >
> > > >
> > > > On Mon, Jan 11, 2010 at 10:00 AM, Jakob Korherr <
> > jakob.korh...@gmail.com
> > > >wrote:
> > > >
> > > >> Maybe it happens when accessing the value from the Map with
> > > >> "#{bean.get['memid']}", because the Map is not properly
> synchronized,
> > > thus
> > > >> its internal structure is broken and thus it is running in infinite
> > > loops.
> > > >>
> > > >> Are your resources properly synchronized?
> > > >>
> > > >> Just a guess in the blue...
> > > >>
> > > >> Regards,
> > > >> Jakob Korherr
> > > >>
> > > >> 2010/1/11 Ravi Kapoor
> > > >>
> > > >> > Another thing, most of our EL expressions are one of the following
> > > types
> > > >> >
> > > >> > "#{bean.active}"
> > > >> > or
> > > >> > "#{bean.get['memid']}"
> > > >> >
> > > >> > Parsing of these expressions probably happens within
> > > org.apache.myfaces.*
> > > >> > classes. These are fairly basic EL expressions and should not be
> > > taking
> > > >> > much
> > > >> > time. We know, the final getter method is not taking much time.
> > > >> >
> > > >> > Do you know if the page (and EL expressions) are parsed each time
> a
> > > page
> > > >> is
> > > >> > rendered? If pages are parsed only once, then the parsing time
> > should
> > > >> also
> > > >> > be almost negligible.
> > > >> >
> > > >> > - Ravi
> > > >> >
> > > >> > On Mon, Jan 11, 2010 at 8:28 AM, Ravi
> > > wrote:
> > > >> >
> > > >> > >
> > > >> > > Matthias,
> > > >> > >
> > > >> > > If the issue is in bean, it should show up in my analysis. Also
> > > >> > getProperty
> > > >> > > is only 40% CPU, there is additional 45% cpu consumed by rest of
> > the
> > > >> > > trinidad classes totaling 85% total CPU, all within
> > > >> org.apache.myfaces.*
> > > >> > > classes
> > > >> > >
> > > >> > > Ravi
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Matthias Wessendorf wrote:
> > > >> > >
> > > >> > >> Ravi,
> > > >> > >>
> > > >> > >> spoke to a guy that does performance testing/improvement for
> > Oracle
> > > >> > >> Applications. He said that there is some % CPU in Trindad but I
> > > would
> > > >> > >> not give it more them 20%. The heavy hitters is getClientId
> > (Blake
> > > -
> > > >> > >> see dev@ thread - is doing some optimization there).
> > > >> > >>
> > > >> > >> Now if getProperty is some el expression and expression is
> > > expensive
> > > >> > >> the problem is in expression not in Trinidad (perhaps that is
> the
> > > case
> > > >> > >> where you have el epression but beans behind it are not that
> > good).
> > > >> > >>
> > > >> > >> -Matthias
> > > >> > >>
> > > >> > >> On Mon, Jan 11, 2010 at 6:45 AM, Ravi Kapoor <
> > > ravikapoor...@gmail.com
> > > >> >
> > > >> > >> wrote:
> > > >> > >>
> > > >> > >>> Hi Jan-Kees,
> > > >> > >>>
> > > >> > >>> You are right, the getProperty
Re: [Trinidad] Trinidad consuming 80-90% CPU
Ravi,
If you are running on Windows, what does the TaskManager show as the CPU
utilization? How much memory is also being used? 2Gb is not much memory for
a production application. I have that much on my desktop.
-Richard
On Mon, Jan 11, 2010 at 1:05 PM, Ravi Kapoor wrote:
> Jakob,
>
> The beans are not big. Also these tests have been performed under a single
> user to measure the CPU timing. So I doubt locking/synchronization is an
> issue.
>
> I would think that if there is synchronization, then the threads could be
> waiting for long time, but lack of synchronization can only lead to corrupt
> data not to higher CPU. Can you explain little bit how lack of
> synchronization can add to CPU?
>
> I have never used VisualVM, I can try it sometime this week. I am assuming
> it will work with Websphere 6.1
>
> Regards
> Ravi
>
> On Mon, Jan 11, 2010 at 3:03 PM, Jan-Kees van Andel <
> jankeesvanan...@gmail.com> wrote:
>
> > Hi Ravi,
> >
> > Just a stupid question. Are your beans extremely big? Since FacesBean
> > doesn't do much locking/synchronizing (none if I'm correctly), the
> > only reason I can imagine it to eat CPU cycles is because of its
> > size...
> >
> > Also, is it possible for you to do a profiling run using VisualVM?
> > I've been profiling Trinidad with VisualVM myself and maybe we can
> > compare numbers... Using the same tool might make it easier to
> > compare...
> >
> > /JK
> >
> >
> > 2010/1/11 Ravi Kapoor :
> > > I am thinking if that was the case, I would see high CPU in
> > > java.util.HashMap instead of org.apache.faces.*
> > >
> > > If you disagree, please explain and I can try using HashTable to store
> > data
> > > and get fresh numbers.
> > >
> > >
> > > On Mon, Jan 11, 2010 at 10:00 AM, Jakob Korherr <
> jakob.korh...@gmail.com
> > >wrote:
> > >
> > >> Maybe it happens when accessing the value from the Map with
> > >> "#{bean.get['memid']}", because the Map is not properly synchronized,
> > thus
> > >> its internal structure is broken and thus it is running in infinite
> > loops.
> > >>
> > >> Are your resources properly synchronized?
> > >>
> > >> Just a guess in the blue...
> > >>
> > >> Regards,
> > >> Jakob Korherr
> > >>
> > >> 2010/1/11 Ravi Kapoor
> > >>
> > >> > Another thing, most of our EL expressions are one of the following
> > types
> > >> >
> > >> > "#{bean.active}"
> > >> > or
> > >> > "#{bean.get['memid']}"
> > >> >
> > >> > Parsing of these expressions probably happens within
> > org.apache.myfaces.*
> > >> > classes. These are fairly basic EL expressions and should not be
> > taking
> > >> > much
> > >> > time. We know, the final getter method is not taking much time.
> > >> >
> > >> > Do you know if the page (and EL expressions) are parsed each time a
> > page
> > >> is
> > >> > rendered? If pages are parsed only once, then the parsing time
> should
> > >> also
> > >> > be almost negligible.
> > >> >
> > >> > - Ravi
> > >> >
> > >> > On Mon, Jan 11, 2010 at 8:28 AM, Ravi
> > wrote:
> > >> >
> > >> > >
> > >> > > Matthias,
> > >> > >
> > >> > > If the issue is in bean, it should show up in my analysis. Also
> > >> > getProperty
> > >> > > is only 40% CPU, there is additional 45% cpu consumed by rest of
> the
> > >> > > trinidad classes totaling 85% total CPU, all within
> > >> org.apache.myfaces.*
> > >> > > classes
> > >> > >
> > >> > > Ravi
> > >> > >
> > >> > >
> > >> > >
> > >> > > Matthias Wessendorf wrote:
> > >> > >
> > >> > >> Ravi,
> > >> > >>
> > >> > >> spoke to a guy that does performance testing/improvement for
> Oracle
> > >> > >> Applications. He said that there is some % CPU in Trindad but I
> > would
> > >> > >> not give it more them 20%. The heavy hitters is getClientId
> (Blake
> > -
> > >> > >> see dev@ thread - is doing some optimization there).
> > >> > >>
> > >> > >> Now if getProperty is some el expression and expression is
> > expensive
> > >> > >> the problem is in expression not in Trinidad (perhaps that is the
> > case
> > >> > >> where you have el epression but beans behind it are not that
> good).
> > >> > >>
> > >> > >> -Matthias
> > >> > >>
> > >> > >> On Mon, Jan 11, 2010 at 6:45 AM, Ravi Kapoor <
> > ravikapoor...@gmail.com
> > >> >
> > >> > >> wrote:
> > >> > >>
> > >> > >>> Hi Jan-Kees,
> > >> > >>>
> > >> > >>> You are right, the getProperty method is only taking 2K units.
> > >> However
> > >> > if
> > >> > >>> I
> > >> > >>> dig deeper, I find that most of the cumulative time is being
> spent
> > >> > within
> > >> > >>> Trinidad classes. The final call to java getters consumes
> > negligible
> > >> > >>> time.
> > >> > >>>
> > >> > >>> I was unable to create thread structure like you showed (JProbe
> > keeps
> > >> > >>> getting crashed). But I took another screenshot that shows
> almost
> > >> > similar
> > >> > >>> details you are looking for. It highlights the classes that are
> > >> taking
> > >> > >>> maximum time (cumulative time again) but as you can see, all the
> > >> > classes
> > >> > >>> are
> > >> > >>> ju
Re: [Trinidad] Trinidad consuming 80-90% CPU
Jakob,
The beans are not big. Also these tests have been performed under a single
user to measure the CPU timing. So I doubt locking/synchronization is an
issue.
I would think that if there is synchronization, then the threads could be
waiting for long time, but lack of synchronization can only lead to corrupt
data not to higher CPU. Can you explain little bit how lack of
synchronization can add to CPU?
I have never used VisualVM, I can try it sometime this week. I am assuming
it will work with Websphere 6.1
Regards
Ravi
On Mon, Jan 11, 2010 at 3:03 PM, Jan-Kees van Andel <
jankeesvanan...@gmail.com> wrote:
> Hi Ravi,
>
> Just a stupid question. Are your beans extremely big? Since FacesBean
> doesn't do much locking/synchronizing (none if I'm correctly), the
> only reason I can imagine it to eat CPU cycles is because of its
> size...
>
> Also, is it possible for you to do a profiling run using VisualVM?
> I've been profiling Trinidad with VisualVM myself and maybe we can
> compare numbers... Using the same tool might make it easier to
> compare...
>
> /JK
>
>
> 2010/1/11 Ravi Kapoor :
> > I am thinking if that was the case, I would see high CPU in
> > java.util.HashMap instead of org.apache.faces.*
> >
> > If you disagree, please explain and I can try using HashTable to store
> data
> > and get fresh numbers.
> >
> >
> > On Mon, Jan 11, 2010 at 10:00 AM, Jakob Korherr >wrote:
> >
> >> Maybe it happens when accessing the value from the Map with
> >> "#{bean.get['memid']}", because the Map is not properly synchronized,
> thus
> >> its internal structure is broken and thus it is running in infinite
> loops.
> >>
> >> Are your resources properly synchronized?
> >>
> >> Just a guess in the blue...
> >>
> >> Regards,
> >> Jakob Korherr
> >>
> >> 2010/1/11 Ravi Kapoor
> >>
> >> > Another thing, most of our EL expressions are one of the following
> types
> >> >
> >> > "#{bean.active}"
> >> > or
> >> > "#{bean.get['memid']}"
> >> >
> >> > Parsing of these expressions probably happens within
> org.apache.myfaces.*
> >> > classes. These are fairly basic EL expressions and should not be
> taking
> >> > much
> >> > time. We know, the final getter method is not taking much time.
> >> >
> >> > Do you know if the page (and EL expressions) are parsed each time a
> page
> >> is
> >> > rendered? If pages are parsed only once, then the parsing time should
> >> also
> >> > be almost negligible.
> >> >
> >> > - Ravi
> >> >
> >> > On Mon, Jan 11, 2010 at 8:28 AM, Ravi
> wrote:
> >> >
> >> > >
> >> > > Matthias,
> >> > >
> >> > > If the issue is in bean, it should show up in my analysis. Also
> >> > getProperty
> >> > > is only 40% CPU, there is additional 45% cpu consumed by rest of the
> >> > > trinidad classes totaling 85% total CPU, all within
> >> org.apache.myfaces.*
> >> > > classes
> >> > >
> >> > > Ravi
> >> > >
> >> > >
> >> > >
> >> > > Matthias Wessendorf wrote:
> >> > >
> >> > >> Ravi,
> >> > >>
> >> > >> spoke to a guy that does performance testing/improvement for Oracle
> >> > >> Applications. He said that there is some % CPU in Trindad but I
> would
> >> > >> not give it more them 20%. The heavy hitters is getClientId (Blake
> -
> >> > >> see dev@ thread - is doing some optimization there).
> >> > >>
> >> > >> Now if getProperty is some el expression and expression is
> expensive
> >> > >> the problem is in expression not in Trinidad (perhaps that is the
> case
> >> > >> where you have el epression but beans behind it are not that good).
> >> > >>
> >> > >> -Matthias
> >> > >>
> >> > >> On Mon, Jan 11, 2010 at 6:45 AM, Ravi Kapoor <
> ravikapoor...@gmail.com
> >> >
> >> > >> wrote:
> >> > >>
> >> > >>> Hi Jan-Kees,
> >> > >>>
> >> > >>> You are right, the getProperty method is only taking 2K units.
> >> However
> >> > if
> >> > >>> I
> >> > >>> dig deeper, I find that most of the cumulative time is being spent
> >> > within
> >> > >>> Trinidad classes. The final call to java getters consumes
> negligible
> >> > >>> time.
> >> > >>>
> >> > >>> I was unable to create thread structure like you showed (JProbe
> keeps
> >> > >>> getting crashed). But I took another screenshot that shows almost
> >> > similar
> >> > >>> details you are looking for. It highlights the classes that are
> >> taking
> >> > >>> maximum time (cumulative time again) but as you can see, all the
> >> > classes
> >> > >>> are
> >> > >>> just trinidad classes.
> >> > >>>
> >> > >>>
> >> >
> >>
> http://docs.google.com/Doc?docid=0AbuQsSDG0X9_ZGhraHFwejJfNGRjcGNiN2hk&hl=en
> >> > >>>
> >> > >>> Regards,
> >> > >>> Ravi
> >> > >>>
> >> > >>> On Sun, Jan 10, 2010 at 12:54 PM, Jan-Kees van Andel <
> >> > >>> jankeesvanan...@gmail.com> wrote:
> >> > >>>
> >> > >>> Hey Ravi,
> >> >
> >> > Looking at your JProbe screenshots for the second time, I think
> >> you're
> >> > misinterpreting the graphs (but I haven't used JProbe before, so
> I
> >> > might be mistaking ;-) ).
> >> >
> >> > In your first screenshot (upper
Re: [Trinidad] Trinidad consuming 80-90% CPU
Thanks Richard for the numbers. Can you also mention no of servers used, CPU and memory details of each server? Regards Ravi On Mon, Jan 11, 2010 at 3:00 PM, Richard Yee wrote: > Ravi, > We have load tested our Trinidad application with up to 800,000 page > loads/hr. and the application handled it fine. We have also simulated up to > 190 concurrent users. We are using MyFaces 1.1.5 and Trinidad 1.0.5. We are > using the Oracle Application Server 10GR3 and are running on Linux. > > -Richard > > > On Fri, Jan 8, 2010 at 3:12 PM, Ravi Kapoor > wrote: > > > I have 2 GB on the machine and it only uses 1 GB. > > > > Can you give details on your environment. Especially trinidad version, > CPU > > details and how many users per JVM can you handle, what %age of CPU is > > consumed by trinidad etc > > > > Regards > > Ravi > > > > On Fri, Jan 8, 2010 at 4:08 PM, Richard Yee > > wrote: > > > > > How much physical memory is on your testing machine? > > > I have a few Trinidad applications in production and don't see any of > the > > > performance issues you are having. > > > > > > -Richard > > > > > > > > > > > > On Fri, Jan 8, 2010 at 12:33 PM, Jan-Kees van Andel < > > > jankeesvanan...@gmail.com> wrote: > > > > > > > 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 : > > > > > > > > > > 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 > > > > > 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 : > > > > >> > 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 > > > > >> > 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 < > > > > ravikapoor...@gmail.com> > > > > >> >> wrote: > > > > >> >> > Has anybody done performance tests on trinidad application. I > > > h
Spring FilterSecurityInterceptor not been called for myfaces forwards
Hi All, I am using myfaces 1.1, icefaces 1.8.1, spring 2.5.6, spring security -2.0.5, WAS 6.0 (app server) I have configured spring security for my JSF application along with SiteMinder as an external authentication mechanism. It works fine till a forward happens from within myfaces. Here is my spring servlet filter chain declaration: Spring delegating filter which will initiate the spring security filter chain springSecurityFilterChain springSecurityFilterChain org.springframework.web.filter.DelegatingFilterProxy springSecurityFilterChain /* FORWARD REQUEST And in my spring application context I have followed the advice from spring forums and done necessary settings: Excerpt is: Now when I forward a request from index.jsp to login.jsp then the spring filters are called with the login.jsp URL even though the browser shows the old URL. However when from within an action method a navigation case is handled then it is not intercepted by the spring filters at all. However if I give a then it is properly intercepted with the correct URL as expected. What can be the reason? Regards, Madhav
Re: [Trinidad] Trinidad consuming 80-90% CPU
Hi Ravi,
Just a stupid question. Are your beans extremely big? Since FacesBean
doesn't do much locking/synchronizing (none if I'm correctly), the
only reason I can imagine it to eat CPU cycles is because of its
size...
Also, is it possible for you to do a profiling run using VisualVM?
I've been profiling Trinidad with VisualVM myself and maybe we can
compare numbers... Using the same tool might make it easier to
compare...
/JK
2010/1/11 Ravi Kapoor :
> I am thinking if that was the case, I would see high CPU in
> java.util.HashMap instead of org.apache.faces.*
>
> If you disagree, please explain and I can try using HashTable to store data
> and get fresh numbers.
>
>
> On Mon, Jan 11, 2010 at 10:00 AM, Jakob Korherr
> wrote:
>
>> Maybe it happens when accessing the value from the Map with
>> "#{bean.get['memid']}", because the Map is not properly synchronized, thus
>> its internal structure is broken and thus it is running in infinite loops.
>>
>> Are your resources properly synchronized?
>>
>> Just a guess in the blue...
>>
>> Regards,
>> Jakob Korherr
>>
>> 2010/1/11 Ravi Kapoor
>>
>> > Another thing, most of our EL expressions are one of the following types
>> >
>> > "#{bean.active}"
>> > or
>> > "#{bean.get['memid']}"
>> >
>> > Parsing of these expressions probably happens within org.apache.myfaces.*
>> > classes. These are fairly basic EL expressions and should not be taking
>> > much
>> > time. We know, the final getter method is not taking much time.
>> >
>> > Do you know if the page (and EL expressions) are parsed each time a page
>> is
>> > rendered? If pages are parsed only once, then the parsing time should
>> also
>> > be almost negligible.
>> >
>> > - Ravi
>> >
>> > On Mon, Jan 11, 2010 at 8:28 AM, Ravi wrote:
>> >
>> > >
>> > > Matthias,
>> > >
>> > > If the issue is in bean, it should show up in my analysis. Also
>> > getProperty
>> > > is only 40% CPU, there is additional 45% cpu consumed by rest of the
>> > > trinidad classes totaling 85% total CPU, all within
>> org.apache.myfaces.*
>> > > classes
>> > >
>> > > Ravi
>> > >
>> > >
>> > >
>> > > Matthias Wessendorf wrote:
>> > >
>> > >> Ravi,
>> > >>
>> > >> spoke to a guy that does performance testing/improvement for Oracle
>> > >> Applications. He said that there is some % CPU in Trindad but I would
>> > >> not give it more them 20%. The heavy hitters is getClientId (Blake -
>> > >> see dev@ thread - is doing some optimization there).
>> > >>
>> > >> Now if getProperty is some el expression and expression is expensive
>> > >> the problem is in expression not in Trinidad (perhaps that is the case
>> > >> where you have el epression but beans behind it are not that good).
>> > >>
>> > >> -Matthias
>> > >>
>> > >> On Mon, Jan 11, 2010 at 6:45 AM, Ravi Kapoor > >
>> > >> wrote:
>> > >>
>> > >>> Hi Jan-Kees,
>> > >>>
>> > >>> You are right, the getProperty method is only taking 2K units.
>> However
>> > if
>> > >>> I
>> > >>> dig deeper, I find that most of the cumulative time is being spent
>> > within
>> > >>> Trinidad classes. The final call to java getters consumes negligible
>> > >>> time.
>> > >>>
>> > >>> I was unable to create thread structure like you showed (JProbe keeps
>> > >>> getting crashed). But I took another screenshot that shows almost
>> > similar
>> > >>> details you are looking for. It highlights the classes that are
>> taking
>> > >>> maximum time (cumulative time again) but as you can see, all the
>> > classes
>> > >>> are
>> > >>> just trinidad classes.
>> > >>>
>> > >>>
>> >
>> http://docs.google.com/Doc?docid=0AbuQsSDG0X9_ZGhraHFwejJfNGRjcGNiN2hk&hl=en
>> > >>>
>> > >>> Regards,
>> > >>> Ravi
>> > >>>
>> > >>> On Sun, Jan 10, 2010 at 12:54 PM, Jan-Kees van Andel <
>> > >>> jankeesvanan...@gmail.com> wrote:
>> > >>>
>> > >>> Hey Ravi,
>> >
>> > Looking at your JProbe screenshots for the second time, I think
>> you're
>> > misinterpreting the graphs (but I haven't used JProbe before, so I
>> > might be mistaking ;-) ).
>> >
>> > In your first screenshot (upper left corner) you can see the total
>> > time the getProperty method takes.
>> > This includes its self time and the time taken by its children. Its
>> > self time is 2781 and the child time is 29609.
>> > A large portion (around 85%) comes from the getLocalProperty and
>> > ValueBinding.getValue methods.
>> >
>> > However, these two methods don't do much, since they delegate to
>> other
>> > methods to do the real work. Maybe even invoking application code,
>> > like managed beans.
>> >
>> > Can you provide a more detailed call tree with more info about the
>> > child methods that are invoked? I'm especially interested in the
>> > methods that are called by getLocalProperty and
>> ValueBinding.getValue
>> > and their children. I'm not that familiar with JProbe, but I'm sure
>> it
>> > supports something like a call tree
>> > (
>> >
>> >
Re: [Trinidad] Trinidad consuming 80-90% CPU
Ravi, We have load tested our Trinidad application with up to 800,000 page loads/hr. and the application handled it fine. We have also simulated up to 190 concurrent users. We are using MyFaces 1.1.5 and Trinidad 1.0.5. We are using the Oracle Application Server 10GR3 and are running on Linux. -Richard On Fri, Jan 8, 2010 at 3:12 PM, Ravi Kapoor wrote: > I have 2 GB on the machine and it only uses 1 GB. > > Can you give details on your environment. Especially trinidad version, CPU > details and how many users per JVM can you handle, what %age of CPU is > consumed by trinidad etc > > Regards > Ravi > > On Fri, Jan 8, 2010 at 4:08 PM, Richard Yee > wrote: > > > How much physical memory is on your testing machine? > > I have a few Trinidad applications in production and don't see any of the > > performance issues you are having. > > > > -Richard > > > > > > > > On Fri, Jan 8, 2010 at 12:33 PM, Jan-Kees van Andel < > > jankeesvanan...@gmail.com> wrote: > > > > > 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 : > > > > > > > > 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 > > > > 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 : > > > >> > 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 > > > >> > 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 < > > > ravikapoor...@gmail.com> > > > >> >> 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% > > >
Re: [Trinidad] Trinidad consuming 80-90% CPU
I am thinking if that was the case, I would see high CPU in
java.util.HashMap instead of org.apache.faces.*
If you disagree, please explain and I can try using HashTable to store data
and get fresh numbers.
On Mon, Jan 11, 2010 at 10:00 AM, Jakob Korherr wrote:
> Maybe it happens when accessing the value from the Map with
> "#{bean.get['memid']}", because the Map is not properly synchronized, thus
> its internal structure is broken and thus it is running in infinite loops.
>
> Are your resources properly synchronized?
>
> Just a guess in the blue...
>
> Regards,
> Jakob Korherr
>
> 2010/1/11 Ravi Kapoor
>
> > Another thing, most of our EL expressions are one of the following types
> >
> > "#{bean.active}"
> > or
> > "#{bean.get['memid']}"
> >
> > Parsing of these expressions probably happens within org.apache.myfaces.*
> > classes. These are fairly basic EL expressions and should not be taking
> > much
> > time. We know, the final getter method is not taking much time.
> >
> > Do you know if the page (and EL expressions) are parsed each time a page
> is
> > rendered? If pages are parsed only once, then the parsing time should
> also
> > be almost negligible.
> >
> > - Ravi
> >
> > On Mon, Jan 11, 2010 at 8:28 AM, Ravi wrote:
> >
> > >
> > > Matthias,
> > >
> > > If the issue is in bean, it should show up in my analysis. Also
> > getProperty
> > > is only 40% CPU, there is additional 45% cpu consumed by rest of the
> > > trinidad classes totaling 85% total CPU, all within
> org.apache.myfaces.*
> > > classes
> > >
> > > Ravi
> > >
> > >
> > >
> > > Matthias Wessendorf wrote:
> > >
> > >> Ravi,
> > >>
> > >> spoke to a guy that does performance testing/improvement for Oracle
> > >> Applications. He said that there is some % CPU in Trindad but I would
> > >> not give it more them 20%. The heavy hitters is getClientId (Blake -
> > >> see dev@ thread - is doing some optimization there).
> > >>
> > >> Now if getProperty is some el expression and expression is expensive
> > >> the problem is in expression not in Trinidad (perhaps that is the case
> > >> where you have el epression but beans behind it are not that good).
> > >>
> > >> -Matthias
> > >>
> > >> On Mon, Jan 11, 2010 at 6:45 AM, Ravi Kapoor >
> > >> wrote:
> > >>
> > >>> Hi Jan-Kees,
> > >>>
> > >>> You are right, the getProperty method is only taking 2K units.
> However
> > if
> > >>> I
> > >>> dig deeper, I find that most of the cumulative time is being spent
> > within
> > >>> Trinidad classes. The final call to java getters consumes negligible
> > >>> time.
> > >>>
> > >>> I was unable to create thread structure like you showed (JProbe keeps
> > >>> getting crashed). But I took another screenshot that shows almost
> > similar
> > >>> details you are looking for. It highlights the classes that are
> taking
> > >>> maximum time (cumulative time again) but as you can see, all the
> > classes
> > >>> are
> > >>> just trinidad classes.
> > >>>
> > >>>
> >
> http://docs.google.com/Doc?docid=0AbuQsSDG0X9_ZGhraHFwejJfNGRjcGNiN2hk&hl=en
> > >>>
> > >>> Regards,
> > >>> Ravi
> > >>>
> > >>> On Sun, Jan 10, 2010 at 12:54 PM, Jan-Kees van Andel <
> > >>> jankeesvanan...@gmail.com> wrote:
> > >>>
> > >>> Hey Ravi,
> >
> > Looking at your JProbe screenshots for the second time, I think
> you're
> > misinterpreting the graphs (but I haven't used JProbe before, so I
> > might be mistaking ;-) ).
> >
> > In your first screenshot (upper left corner) you can see the total
> > time the getProperty method takes.
> > This includes its self time and the time taken by its children. Its
> > self time is 2781 and the child time is 29609.
> > A large portion (around 85%) comes from the getLocalProperty and
> > ValueBinding.getValue methods.
> >
> > However, these two methods don't do much, since they delegate to
> other
> > methods to do the real work. Maybe even invoking application code,
> > like managed beans.
> >
> > Can you provide a more detailed call tree with more info about the
> > child methods that are invoked? I'm especially interested in the
> > methods that are called by getLocalProperty and
> ValueBinding.getValue
> > and their children. I'm not that familiar with JProbe, but I'm sure
> it
> > supports something like a call tree
> > (
> >
> >
> >
> http://www.ej-technologies.com/products/jprofiler/images/whatsnew/exceptional_methods_calltree.png
> > ),
> > so you can see the problematic method.
> >
> > Regards,
> > Jan-Kees
> >
> >
> > 2010/1/10 Ravi :
> >
> > > Matthias, I think websphere 6.1 does not support JSF 1.2. I will
> > > doublecheck, let me know if this is incorrect. This mans I cannot
> try
> > > trinidad version 1.2.12
> > >
> > > I will try out 1.0.11 release, but that is a minor release update
> and
> > I
> > > seriously doubt if it will fix such a per
Re: [Trinidad] Trinidad consuming 80-90% CPU
Maybe it happens when accessing the value from the Map with
"#{bean.get['memid']}", because the Map is not properly synchronized, thus
its internal structure is broken and thus it is running in infinite loops.
Are your resources properly synchronized?
Just a guess in the blue...
Regards,
Jakob Korherr
2010/1/11 Ravi Kapoor
> Another thing, most of our EL expressions are one of the following types
>
> "#{bean.active}"
> or
> "#{bean.get['memid']}"
>
> Parsing of these expressions probably happens within org.apache.myfaces.*
> classes. These are fairly basic EL expressions and should not be taking
> much
> time. We know, the final getter method is not taking much time.
>
> Do you know if the page (and EL expressions) are parsed each time a page is
> rendered? If pages are parsed only once, then the parsing time should also
> be almost negligible.
>
> - Ravi
>
> On Mon, Jan 11, 2010 at 8:28 AM, Ravi wrote:
>
> >
> > Matthias,
> >
> > If the issue is in bean, it should show up in my analysis. Also
> getProperty
> > is only 40% CPU, there is additional 45% cpu consumed by rest of the
> > trinidad classes totaling 85% total CPU, all within org.apache.myfaces.*
> > classes
> >
> > Ravi
> >
> >
> >
> > Matthias Wessendorf wrote:
> >
> >> Ravi,
> >>
> >> spoke to a guy that does performance testing/improvement for Oracle
> >> Applications. He said that there is some % CPU in Trindad but I would
> >> not give it more them 20%. The heavy hitters is getClientId (Blake -
> >> see dev@ thread - is doing some optimization there).
> >>
> >> Now if getProperty is some el expression and expression is expensive
> >> the problem is in expression not in Trinidad (perhaps that is the case
> >> where you have el epression but beans behind it are not that good).
> >>
> >> -Matthias
> >>
> >> On Mon, Jan 11, 2010 at 6:45 AM, Ravi Kapoor
> >> wrote:
> >>
> >>> Hi Jan-Kees,
> >>>
> >>> You are right, the getProperty method is only taking 2K units. However
> if
> >>> I
> >>> dig deeper, I find that most of the cumulative time is being spent
> within
> >>> Trinidad classes. The final call to java getters consumes negligible
> >>> time.
> >>>
> >>> I was unable to create thread structure like you showed (JProbe keeps
> >>> getting crashed). But I took another screenshot that shows almost
> similar
> >>> details you are looking for. It highlights the classes that are taking
> >>> maximum time (cumulative time again) but as you can see, all the
> classes
> >>> are
> >>> just trinidad classes.
> >>>
> >>>
> http://docs.google.com/Doc?docid=0AbuQsSDG0X9_ZGhraHFwejJfNGRjcGNiN2hk&hl=en
> >>>
> >>> Regards,
> >>> Ravi
> >>>
> >>> On Sun, Jan 10, 2010 at 12:54 PM, Jan-Kees van Andel <
> >>> jankeesvanan...@gmail.com> wrote:
> >>>
> >>> Hey Ravi,
>
> Looking at your JProbe screenshots for the second time, I think you're
> misinterpreting the graphs (but I haven't used JProbe before, so I
> might be mistaking ;-) ).
>
> In your first screenshot (upper left corner) you can see the total
> time the getProperty method takes.
> This includes its self time and the time taken by its children. Its
> self time is 2781 and the child time is 29609.
> A large portion (around 85%) comes from the getLocalProperty and
> ValueBinding.getValue methods.
>
> However, these two methods don't do much, since they delegate to other
> methods to do the real work. Maybe even invoking application code,
> like managed beans.
>
> Can you provide a more detailed call tree with more info about the
> child methods that are invoked? I'm especially interested in the
> methods that are called by getLocalProperty and ValueBinding.getValue
> and their children. I'm not that familiar with JProbe, but I'm sure it
> supports something like a call tree
> (
>
>
> http://www.ej-technologies.com/products/jprofiler/images/whatsnew/exceptional_methods_calltree.png
> ),
> so you can see the problematic method.
>
> Regards,
> Jan-Kees
>
>
> 2010/1/10 Ravi :
>
> > Matthias, I think websphere 6.1 does not support JSF 1.2. I will
> > doublecheck, let me know if this is incorrect. This mans I cannot try
> > trinidad version 1.2.12
> >
> > I will try out 1.0.11 release, but that is a minor release update and
> I
> > seriously doubt if it will fix such a performance issue.
> >
> > What other options do we have? Is there a way we can get somebody
> >
> familiar
>
> > with trinidad architecture/code to look at this issue? This can even
> be
> > a
> > paid assignment.
> >
> > Regards
> > Ravi
> >
> >
> > Matthias Wessendorf wrote:
> >
> >> Hello Ravi,
> >>
> >> I wonder what our last release for JSF 1.1 (1.0.11) does?
> >>
> >> Not sure, perhaps you may also try the JSF 1.2 version ? (1.2.12)
> >> The JSF 1.2 version is
Re: [Trinidad] Trinidad consuming 80-90% CPU
Another thing, most of our EL expressions are one of the following types
"#{bean.active}"
or
"#{bean.get['memid']}"
Parsing of these expressions probably happens within org.apache.myfaces.*
classes. These are fairly basic EL expressions and should not be taking much
time. We know, the final getter method is not taking much time.
Do you know if the page (and EL expressions) are parsed each time a page is
rendered? If pages are parsed only once, then the parsing time should also
be almost negligible.
- Ravi
On Mon, Jan 11, 2010 at 8:28 AM, Ravi wrote:
>
> Matthias,
>
> If the issue is in bean, it should show up in my analysis. Also getProperty
> is only 40% CPU, there is additional 45% cpu consumed by rest of the
> trinidad classes totaling 85% total CPU, all within org.apache.myfaces.*
> classes
>
> Ravi
>
>
>
> Matthias Wessendorf wrote:
>
>> Ravi,
>>
>> spoke to a guy that does performance testing/improvement for Oracle
>> Applications. He said that there is some % CPU in Trindad but I would
>> not give it more them 20%. The heavy hitters is getClientId (Blake -
>> see dev@ thread - is doing some optimization there).
>>
>> Now if getProperty is some el expression and expression is expensive
>> the problem is in expression not in Trinidad (perhaps that is the case
>> where you have el epression but beans behind it are not that good).
>>
>> -Matthias
>>
>> On Mon, Jan 11, 2010 at 6:45 AM, Ravi Kapoor
>> wrote:
>>
>>> Hi Jan-Kees,
>>>
>>> You are right, the getProperty method is only taking 2K units. However if
>>> I
>>> dig deeper, I find that most of the cumulative time is being spent within
>>> Trinidad classes. The final call to java getters consumes negligible
>>> time.
>>>
>>> I was unable to create thread structure like you showed (JProbe keeps
>>> getting crashed). But I took another screenshot that shows almost similar
>>> details you are looking for. It highlights the classes that are taking
>>> maximum time (cumulative time again) but as you can see, all the classes
>>> are
>>> just trinidad classes.
>>>
>>> http://docs.google.com/Doc?docid=0AbuQsSDG0X9_ZGhraHFwejJfNGRjcGNiN2hk&hl=en
>>>
>>> Regards,
>>> Ravi
>>>
>>> On Sun, Jan 10, 2010 at 12:54 PM, Jan-Kees van Andel <
>>> jankeesvanan...@gmail.com> wrote:
>>>
>>> Hey Ravi,
Looking at your JProbe screenshots for the second time, I think you're
misinterpreting the graphs (but I haven't used JProbe before, so I
might be mistaking ;-) ).
In your first screenshot (upper left corner) you can see the total
time the getProperty method takes.
This includes its self time and the time taken by its children. Its
self time is 2781 and the child time is 29609.
A large portion (around 85%) comes from the getLocalProperty and
ValueBinding.getValue methods.
However, these two methods don't do much, since they delegate to other
methods to do the real work. Maybe even invoking application code,
like managed beans.
Can you provide a more detailed call tree with more info about the
child methods that are invoked? I'm especially interested in the
methods that are called by getLocalProperty and ValueBinding.getValue
and their children. I'm not that familiar with JProbe, but I'm sure it
supports something like a call tree
(
http://www.ej-technologies.com/products/jprofiler/images/whatsnew/exceptional_methods_calltree.png
),
so you can see the problematic method.
Regards,
Jan-Kees
2010/1/10 Ravi :
> Matthias, I think websphere 6.1 does not support JSF 1.2. I will
> doublecheck, let me know if this is incorrect. This mans I cannot try
> trinidad version 1.2.12
>
> I will try out 1.0.11 release, but that is a minor release update and I
> seriously doubt if it will fix such a performance issue.
>
> What other options do we have? Is there a way we can get somebody
>
familiar
> with trinidad architecture/code to look at this issue? This can even be
> a
> paid assignment.
>
> Regards
> Ravi
>
>
> Matthias Wessendorf wrote:
>
>> Hello Ravi,
>>
>> I wonder what our last release for JSF 1.1 (1.0.11) does?
>>
>> Not sure, perhaps you may also try the JSF 1.2 version ? (1.2.12)
>> The JSF 1.2 version is the one that is best supported, these days.
>>
>> Trinidad 2.0 is now in alpha stage, and I can understand that you
>> don't want to update on that version, now
>>
>> -Matthias
>>
>> On Sun, Jan 10, 2010 at 4:56 AM, Ravi
>> wrote:
>>
>>> Scott, we do not have CPUs available. The time trinidad is consuming
>>> is
>>> supposed to be doing some other work. Hence this is costing us real
>>> dollars
>>> and hence our time and effort to resolve this.
>>>
>>> This is not initial hit of page. I always ignore the first hit on all
>>> pages,
>>
Re: [Trinidad] Trinidad consuming 80-90% CPU
Matthias, If the issue is in bean, it should show up in my analysis. Also getProperty is only 40% CPU, there is additional 45% cpu consumed by rest of the trinidad classes totaling 85% total CPU, all within org.apache.myfaces.* classes Ravi Matthias Wessendorf wrote: Ravi, spoke to a guy that does performance testing/improvement for Oracle Applications. He said that there is some % CPU in Trindad but I would not give it more them 20%. The heavy hitters is getClientId (Blake - see dev@ thread - is doing some optimization there). Now if getProperty is some el expression and expression is expensive the problem is in expression not in Trinidad (perhaps that is the case where you have el epression but beans behind it are not that good). -Matthias On Mon, Jan 11, 2010 at 6:45 AM, Ravi Kapoor wrote: Hi Jan-Kees, You are right, the getProperty method is only taking 2K units. However if I dig deeper, I find that most of the cumulative time is being spent within Trinidad classes. The final call to java getters consumes negligible time. I was unable to create thread structure like you showed (JProbe keeps getting crashed). But I took another screenshot that shows almost similar details you are looking for. It highlights the classes that are taking maximum time (cumulative time again) but as you can see, all the classes are just trinidad classes. http://docs.google.com/Doc?docid=0AbuQsSDG0X9_ZGhraHFwejJfNGRjcGNiN2hk&hl=en Regards, Ravi On Sun, Jan 10, 2010 at 12:54 PM, Jan-Kees van Andel < jankeesvanan...@gmail.com> wrote: Hey Ravi, Looking at your JProbe screenshots for the second time, I think you're misinterpreting the graphs (but I haven't used JProbe before, so I might be mistaking ;-) ). In your first screenshot (upper left corner) you can see the total time the getProperty method takes. This includes its self time and the time taken by its children. Its self time is 2781 and the child time is 29609. A large portion (around 85%) comes from the getLocalProperty and ValueBinding.getValue methods. However, these two methods don't do much, since they delegate to other methods to do the real work. Maybe even invoking application code, like managed beans. Can you provide a more detailed call tree with more info about the child methods that are invoked? I'm especially interested in the methods that are called by getLocalProperty and ValueBinding.getValue and their children. I'm not that familiar with JProbe, but I'm sure it supports something like a call tree ( http://www.ej-technologies.com/products/jprofiler/images/whatsnew/exceptional_methods_calltree.png ), so you can see the problematic method. Regards, Jan-Kees 2010/1/10 Ravi : Matthias, I think websphere 6.1 does not support JSF 1.2. I will doublecheck, let me know if this is incorrect. This mans I cannot try trinidad version 1.2.12 I will try out 1.0.11 release, but that is a minor release update and I seriously doubt if it will fix such a performance issue. What other options do we have? Is there a way we can get somebody familiar with trinidad architecture/code to look at this issue? This can even be a paid assignment. Regards Ravi Matthias Wessendorf wrote: Hello Ravi, I wonder what our last release for JSF 1.1 (1.0.11) does? Not sure, perhaps you may also try the JSF 1.2 version ? (1.2.12) The JSF 1.2 version is the one that is best supported, these days. Trinidad 2.0 is now in alpha stage, and I can understand that you don't want to update on that version, now -Matthias On Sun, Jan 10, 2010 at 4:56 AM, Ravi wrote: Scott, we do not have CPUs available. The time trinidad is consuming is supposed to be doing some other work. Hence this is costing us real dollars and hence our time and effort to resolve this. This is not initial hit of page. I always ignore the first hit on all pages, I am only measuring CPU from 2nd hit onwards. Ravi Scott O'Bryan wrote: I don't know. I'm of the camp that if the CPU time is available, use it. That said, is this load consistant or are you just testing an initial hit of each page. Sent from my iPhone On Jan 8, 2010, at 11:25 PM, Ravi wrote: Hi Jan-Kees, Now that I am reading your message again, I do want to answer your questions in detail. First I agree reflection is cheap, that is why reflection is not my concern. Time being spent in reflection is almost negligible compared to time being spent in trinidad classes. Secondly IO and locking etc contribute to clock time but not to CPU time. e.g. for IO, the thread may be in a wait state waiting for data to arrive. In this case, the clock keeps ticking but such a wait does not need CPU. My numbers are specifically CPU time. Which means trinidad is not waiting but executing CPU instructions. This is why the user load is also irrelevant (high load leads to adding clock time but not to CPU time). But since you asked, to get these numbers, I am not doing a load testing. I am simply loading 4 screens 4 times in order (total 16
Re: [Trinidad] Trinidad consuming 80-90% CPU
Ravi, spoke to a guy that does performance testing/improvement for Oracle Applications. He said that there is some % CPU in Trindad but I would not give it more them 20%. The heavy hitters is getClientId (Blake - see dev@ thread - is doing some optimization there). Now if getProperty is some el expression and expression is expensive the problem is in expression not in Trinidad (perhaps that is the case where you have el epression but beans behind it are not that good). -Matthias On Mon, Jan 11, 2010 at 6:45 AM, Ravi Kapoor wrote: > Hi Jan-Kees, > > You are right, the getProperty method is only taking 2K units. However if I > dig deeper, I find that most of the cumulative time is being spent within > Trinidad classes. The final call to java getters consumes negligible time. > > I was unable to create thread structure like you showed (JProbe keeps > getting crashed). But I took another screenshot that shows almost similar > details you are looking for. It highlights the classes that are taking > maximum time (cumulative time again) but as you can see, all the classes are > just trinidad classes. > http://docs.google.com/Doc?docid=0AbuQsSDG0X9_ZGhraHFwejJfNGRjcGNiN2hk&hl=en > > Regards, > Ravi > > On Sun, Jan 10, 2010 at 12:54 PM, Jan-Kees van Andel < > jankeesvanan...@gmail.com> wrote: > >> Hey Ravi, >> >> Looking at your JProbe screenshots for the second time, I think you're >> misinterpreting the graphs (but I haven't used JProbe before, so I >> might be mistaking ;-) ). >> >> In your first screenshot (upper left corner) you can see the total >> time the getProperty method takes. >> This includes its self time and the time taken by its children. Its >> self time is 2781 and the child time is 29609. >> A large portion (around 85%) comes from the getLocalProperty and >> ValueBinding.getValue methods. >> >> However, these two methods don't do much, since they delegate to other >> methods to do the real work. Maybe even invoking application code, >> like managed beans. >> >> Can you provide a more detailed call tree with more info about the >> child methods that are invoked? I'm especially interested in the >> methods that are called by getLocalProperty and ValueBinding.getValue >> and their children. I'm not that familiar with JProbe, but I'm sure it >> supports something like a call tree >> ( >> http://www.ej-technologies.com/products/jprofiler/images/whatsnew/exceptional_methods_calltree.png >> ), >> so you can see the problematic method. >> >> Regards, >> Jan-Kees >> >> >> 2010/1/10 Ravi : >> > >> > Matthias, I think websphere 6.1 does not support JSF 1.2. I will >> > doublecheck, let me know if this is incorrect. This mans I cannot try >> > trinidad version 1.2.12 >> > >> > I will try out 1.0.11 release, but that is a minor release update and I >> > seriously doubt if it will fix such a performance issue. >> > >> > What other options do we have? Is there a way we can get somebody >> familiar >> > with trinidad architecture/code to look at this issue? This can even be a >> > paid assignment. >> > >> > Regards >> > Ravi >> > >> > >> > Matthias Wessendorf wrote: >> >> >> >> Hello Ravi, >> >> >> >> I wonder what our last release for JSF 1.1 (1.0.11) does? >> >> >> >> Not sure, perhaps you may also try the JSF 1.2 version ? (1.2.12) >> >> The JSF 1.2 version is the one that is best supported, these days. >> >> >> >> Trinidad 2.0 is now in alpha stage, and I can understand that you >> >> don't want to update on that version, now >> >> >> >> -Matthias >> >> >> >> On Sun, Jan 10, 2010 at 4:56 AM, Ravi wrote: >> >>> >> >>> Scott, we do not have CPUs available. The time trinidad is consuming is >> >>> supposed to be doing some other work. Hence this is costing us real >> >>> dollars >> >>> and hence our time and effort to resolve this. >> >>> >> >>> This is not initial hit of page. I always ignore the first hit on all >> >>> pages, >> >>> I am only measuring CPU from 2nd hit onwards. >> >>> >> >>> Ravi >> >>> >> >>> >> >>> Scott O'Bryan wrote: >> >> I don't know. I'm of the camp that if the CPU time is available, use >> it. That said, is this load consistant or are you just testing an >> initial hit of each page. >> >> Sent from my iPhone >> >> On Jan 8, 2010, at 11:25 PM, Ravi wrote: >> >> > Hi Jan-Kees, >> > >> > Now that I am reading your message again, I do want to answer your >> > questions in detail. First I agree reflection is cheap, that is why >> > reflection is not my concern. Time being spent in reflection is >> > almost negligible compared to time being spent in trinidad classes. >> > >> > Secondly IO and locking etc contribute to clock time but not to CPU >> > time. e.g. for IO, the thread may be in a wait state waiting for >> > data to arrive. In this case, the clock keeps ticking but such a >> > wait does not need CPU. My numbers are specifically CPU time. Which >> > means trinidad is not waiting but
