I would suggest you to use a profiler to find out for sure what is taking the time. You can use VisualVM which comes with java 6 or the excellent 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
