Performance issue using <s:bean/> tag

[CS Wong]

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

[Musachy Barroso]

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 <lilwong@...> 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-unsubscribe@...
For additional commands, e-mail: user-help@...

[CS Wong]

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 <musachy@...> 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 <lilwong@...> 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-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

[Musachy Barroso]

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 <lilwong@...> 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 <musachy@...> 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 <lilwong@...> 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-unsubscribe@...
>> For additional commands, e-mail: user-help@...
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[musomesa]

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 <musachy@...>
To: Struts Users Mailing List <user@...>
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 <lilwong@...> 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 <musachy@...> 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 <lilwong@...> 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-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

---------------------------------------------------------------------
o unsubscribe, e-mail: user-unsubscribe@...
or additional commands, e-mail: user-help@...