Since it is not happening consistently and seems to happen more under load it could well be that the instantiation of an object is triggering a garbage collection so it might be unrelated to the <s:bean> itself and more to hanging onto some other objects for too long.
Chris -----Original Message----- From: Musachy Barroso <musa...@gmail.com> To: Struts Users Mailing List <user@struts.apache.org> Sent: Tue, Nov 3, 2009 8:04 am Subject: Re: Performance issue using <s:bean/> tag I would suggest you to use a profiler to find out for sure what is aking the time. You can use VisualVM which comes with java 6 or the xcellent jrockit mission control(free as well). musachy On Mon, Nov 2, 2009 at 2:50 PM, CS Wong <lilw...@gmail.com> wrote: Hi, thanks for answering, I noticed that the quoted text in your reply seemed to be garbled so I guess something screwed up when I sent in my question. I've pasted my original question in a pastebin here ( http://paste2.org/p/495951) so that you can read it better. Sorry for any inconvenience caused. Well, I don't want to be an ass, Musachy, but I think I can prove that the EJB is not the problem. I've timed the logs precisely and the delay happens before the EJB invocation. Here's an example: 1. At the end of the action class, just before returning SUCCESS, I made a log statement. This occurs at 10:03:07. 2. After the log statement, I immediately return SUCCESS. 3. The next logged line would be from PayerAccountsWithBalance bean itself. 4. setTransType() is just a normal setter method that assigns the input to a private attribute (differs from what I said below, sorry my mistake) 5. setInitClass() has the lines that I pasted in a pastebin here: http://paste2.org/p/495948 6. Line 9 of the code pasted is where I make my call to the EJB, yet, the time recorded for line 4, which is a log statement, is at 10:05:23! 7. This means that, over 2 minutes has passed between when the action class completed its execution and when the bean was instantiated and reach the log statement. And this is definitely before the EJB call. 8. So this would exclude the possibility that the delay was caused by the EJB lookup / execution I hope my analysis above is correct. Hope someone with more experience can provide their input here as I'm really getting pasted about the performance issue on a daily basis. Thanks! Wong On Tue, Nov 3, 2009 at 6:27 AM, Musachy Barroso <musa...@gmail.com> wrote: > It is the same struts code running all the time, so it should as > fast(or slow) every time. The only thing that changes is the call to > the EJB, so I would bet that the problem is there. > > musachy > > On Mon, Nov 2, 2009 at 9:57 AM, CS Wong <lilw...@gmail.com> wrote: > > Hi, > > > > I seem to be having a performance issue in some of my Struts 2 actions. > On > > several of my pages, I render a couple of drop down tags in my output > page. > > I populate the drop down tags by instantiating an <s:bean/> tag and > invoking > > the methods in the bean to call an EJB service and populating a > collection > > property from the results. The collection is then passed to a <s:select/> > > tag for rendering. The JSP looks something like this: <s:bean > > name="com.valueObject.PayerAccountsWithBalance" id="payerAccount"> > <s:param > > name="transType">9</s:param> <s:param name="initClass"></s:param> > </s:bean> > > <s:select label ="Transfer From / Pay By Account" name > > ="selectedFromAccount" value ="selectedFromAccount" required ="true" list > = > > "#payerAccount.accountsList" listKey = "key" listValue= "value" headerKey > > ="-1" headerValue="Please Select" cssClass ="clsSelectedOpt accountType" > id > > ="selectedFromAccount" /> com.valueObject.PayerAccountsWithBalance is > just a > > normal Java bean with methods "setTransType()", "setInitClass()" and > > "getAccountsList()" exposed. I populate the accounts list by calling an > EJB > > service. I chose to do it this way instead of populating the collection > in > > the action class itself because I felt that the populating of the > collection > > was not really related to the core business logic of the action itself. > > Functionally, this works great and up till recently, it was working fine > in > > production as well. But people started complaining about load times of > the > > action. Upon investigating, I found that under peak loads, my action was > > taking up to 200 seconds to complete loading. The pattern is > inconsistent. I > > could be getting a 3-8 second response on the action for 5 consecutive > users > > and then it jumps to over 100 seconds for a couple of users before > dropping > > back down again. I had initially thought that my EJBs were the bottleneck > > but after I played around with the logs, I don't think so. I placed a log > > statement at the last line of the action class and the first line of the > > setTransType() method in PayerAccountsWithBalance and found that when a > > significant delay happens, there was a very big delay gap between the > action > > and the bean. The context look up for the EJB only happens in > setInitClass() > > so it looks more like the container was waiting for a new instance of > > PayerAccountsWithBalance to be created. Since the number of > > PayerAccountsWithBalance instances that is needed is roughly commensurate > > with the number of action class instances, I'm not sure what kind of > tuning > > is necessary for me to achieve this. Does anybody else have this problem? > > The version of Struts2 deployed in production is 2.0.11. Thanks! Wong > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > --------------------------------------------------------------------- o unsubscribe, e-mail: user-unsubscr...@struts.apache.org or additional commands, e-mail: user-h...@struts.apache.org
