You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by ivan nikitsenka <ni...@gmail.com> on 2014/04/04 11:46:01 UTC
Re: TomEE performance degrades gradually
David Blevins <david.blevins <at> gmail.com> writes:
I have noticed the same issue on my project. The EJB 2.x.
Exactly the same behavior as described on the top
First response is very quickly and then it becomes worse and aprox after 500
requests it performance becomes slower twice
First investigations shows the entity bean findAll query method is the
issue.
Here is the ejb-jar conf for this method:
<entity id="BreakReason">
<ejb-name>BreakReason</ejb-name>
<local-home>com.trizetto.workflow.ejb.BreakReasonLocalHome</local-
home>
<local>com.trizetto.workflow.ejb.BreakReasonLocal</local>
<ejb-class>com.trizetto.workflow.ejb.BreakReasonBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>com.trizetto.workflow.ejb.BreakReasonKey</prim-key-
class>
<reentrant>false</reentrant>
<cmp-version>2.x</cmp-version>
<abstract-schema-name>BreakReason</abstract-schema-name>
<cmp-field id="CMPAttribute_1061568652677">
<field-name>reasonID</field-name>
</cmp-field>
<cmp-field id="CMPAttribute_1061568657153">
<field-name>reasonDesc</field-name>
</cmp-field>
<cmp-field id="CMPAttribute_1241725251750">
<field-name>reasonType</field-name>
</cmp-field>
<query>
<description></description>
<query-method>
<method-name>findAll</method-name>
<method-params></method-params>
</query-method>
<ejb-ql>select object(o) from BreakReason o order by
o.reasonDesc</ejb-ql>
</query>
Re: TomEE performance degrades gradually
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
Any cache to optimize?
Prepared stmt activated on the pool?
Anyway, thanks for the relevant feedback and for helping in the diagnose
process.
JLouis
2014-04-04 11:46 GMT+02:00 ivan nikitsenka <ni...@gmail.com>:
> David Blevins <david.blevins <at> gmail.com> writes:
> I have noticed the same issue on my project. The EJB 2.x.
> Exactly the same behavior as described on the top
> First response is very quickly and then it becomes worse and aprox after
> 500
> requests it performance becomes slower twice
> First investigations shows the entity bean findAll query method is the
> issue.
> Here is the ejb-jar conf for this method:
> <entity id="BreakReason">
> <ejb-name>BreakReason</ejb-name>
> <local-home>com.trizetto.workflow.ejb.BreakReasonLocalHome</local-
> home>
> <local>com.trizetto.workflow.ejb.BreakReasonLocal</local>
> <ejb-class>com.trizetto.workflow.ejb.BreakReasonBean</ejb-class>
> <persistence-type>Container</persistence-type>
> <prim-key-class>com.trizetto.workflow.ejb.BreakReasonKey</prim-key-
> class>
> <reentrant>false</reentrant>
> <cmp-version>2.x</cmp-version>
> <abstract-schema-name>BreakReason</abstract-schema-name>
> <cmp-field id="CMPAttribute_1061568652677">
> <field-name>reasonID</field-name>
> </cmp-field>
> <cmp-field id="CMPAttribute_1061568657153">
> <field-name>reasonDesc</field-name>
> </cmp-field>
> <cmp-field id="CMPAttribute_1241725251750">
> <field-name>reasonType</field-name>
> </cmp-field>
> <query>
> <description></description>
> <query-method>
> <method-name>findAll</method-name>
> <method-params></method-params>
> </query-method>
> <ejb-ql>select object(o) from BreakReason o order by
> o.reasonDesc</ejb-ql>
> </query>
>
>
--
Jean-Louis
Re: TomEE performance degrades gradually
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Fri, Apr 4, 2014 at 7:21 AM, Jean-Louis MONTEIRO <je...@gmail.com>wrote:
> I tend to disagree with that.
> Each part of a system has it's own goal and scope.
>
> Database is for data so I tend to use it as much as possible for sorting,
> joining, etc, instead of relaying on Java for sorting collections or even
> JPA to get a parent, then all childs, then all childs but applying a
> filter.
>
> But I would agree on the sense that each part (App Server, Database, etc)
> must be tuned according to your SLA and the overall architecture.
> So yes, take care of returning a large resultset to avoid heavy GC
> workload, and check if you have an index and if it's used (explain in mysql
> or any other database specific way to check the execution plan).
>
> JLouis
>
>
+1 I agree, Jean-Louis. Thanks! :)
Re: TomEE performance degrades gradually
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1
just use a tool to get why it is slow. sirona, jamon are easy to set
up or just use a profiler if you have time but not what id do first.
supposing something is slow will just make you loose time, check what
it is is what you need.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-04-04 13:21 GMT+02:00 Jean-Louis MONTEIRO <je...@gmail.com>:
> I tend to disagree with that.
> Each part of a system has it's own goal and scope.
>
> Database is for data so I tend to use it as much as possible for sorting,
> joining, etc, instead of relaying on Java for sorting collections or even
> JPA to get a parent, then all childs, then all childs but applying a filter.
>
> But I would agree on the sense that each part (App Server, Database, etc)
> must be tuned according to your SLA and the overall architecture.
> So yes, take care of returning a large resultset to avoid heavy GC
> workload, and check if you have an index and if it's used (explain in mysql
> or any other database specific way to check the execution plan).
>
> JLouis
>
>
> 2014-04-04 12:39 GMT+02:00 Howard W. Smith, Jr. <sm...@gmail.com>:
>
>> On Fri, Apr 4, 2014 at 5:46 AM, ivan nikitsenka <nikitsenka@gmail.com
>> >wrote:
>>
>> >
>> > <query>
>> > <description></description>
>> > <query-method>
>> > <method-name>findAll</method-name>
>> > <method-params></method-params>
>> > </query-method>
>> > <ejb-ql>select object(o) from BreakReason o order by
>> > o.reasonDesc</ejb-ql>
>> > </query>
>>
>>
>> Seriously? ORDER BY a 'reasonDesc'?
>>
>> Every now and then, I am opening jvisualvm (Java Visual VM) and profiling
>> (or checking the performance) on certain parts of my app, and more and
>> more, I am removing,
>>
>> ORDER BY ...
>>
>> from my queries, and reverting to Collections.sort() + Comparator.
>>
>> Is there an index on this 'reasonDesc'? What is 'reasonDesc'.length(), on
>> average?
>>
>> If this is the reason why TomEE [and your app] is degrading, then please
>> change your query, and remove the ORDER BY ..., and sort your data some
>> other way.
>>
>> Refer to your database tuning document. I use Apache Derby, and they have a
>> very nice/comprehensive 'Tuning Derby' guide that I have referred to in the
>> past, when my app went to production.
>>
>
>
>
> --
> Jean-Louis
Re: TomEE performance degrades gradually
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
I tend to disagree with that.
Each part of a system has it's own goal and scope.
Database is for data so I tend to use it as much as possible for sorting,
joining, etc, instead of relaying on Java for sorting collections or even
JPA to get a parent, then all childs, then all childs but applying a filter.
But I would agree on the sense that each part (App Server, Database, etc)
must be tuned according to your SLA and the overall architecture.
So yes, take care of returning a large resultset to avoid heavy GC
workload, and check if you have an index and if it's used (explain in mysql
or any other database specific way to check the execution plan).
JLouis
2014-04-04 12:39 GMT+02:00 Howard W. Smith, Jr. <sm...@gmail.com>:
> On Fri, Apr 4, 2014 at 5:46 AM, ivan nikitsenka <nikitsenka@gmail.com
> >wrote:
>
> >
> > <query>
> > <description></description>
> > <query-method>
> > <method-name>findAll</method-name>
> > <method-params></method-params>
> > </query-method>
> > <ejb-ql>select object(o) from BreakReason o order by
> > o.reasonDesc</ejb-ql>
> > </query>
>
>
> Seriously? ORDER BY a 'reasonDesc'?
>
> Every now and then, I am opening jvisualvm (Java Visual VM) and profiling
> (or checking the performance) on certain parts of my app, and more and
> more, I am removing,
>
> ORDER BY ...
>
> from my queries, and reverting to Collections.sort() + Comparator.
>
> Is there an index on this 'reasonDesc'? What is 'reasonDesc'.length(), on
> average?
>
> If this is the reason why TomEE [and your app] is degrading, then please
> change your query, and remove the ORDER BY ..., and sort your data some
> other way.
>
> Refer to your database tuning document. I use Apache Derby, and they have a
> very nice/comprehensive 'Tuning Derby' guide that I have referred to in the
> past, when my app went to production.
>
--
Jean-Louis
Re: TomEE performance degrades gradually
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Fri, Apr 4, 2014 at 7:07 AM, Howard W. Smith, Jr. <smithh032772@gmail.com
> wrote:
> yes, I have some quite complex SQL, and when I profile the app (via
> jvisualvm), I find that Apache Derby source code is not performing well
> with [my] SQL and/or [my] database design, etc...
Correction, EclipseLink and/or Derby may not be performing well with 'my'
SQL in 'my' app. :)
Re: TomEE performance degrades gradually
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Fri, Apr 4, 2014 at 6:39 AM, Howard W. Smith, Jr. <smithh032772@gmail.com
> wrote:
>
> On Fri, Apr 4, 2014 at 5:46 AM, ivan nikitsenka <ni...@gmail.com>wrote:
>
>>
>> <query>
>> <description></description>
>> <query-method>
>> <method-name>findAll</method-name>
>> <method-params></method-params>
>> </query-method>
>> <ejb-ql>select object(o) from BreakReason o order by
>> o.reasonDesc</ejb-ql>
>> </query>
>
>
> Seriously? ORDER BY a 'reasonDesc'?
>
> Every now and then, I am opening jvisualvm (Java Visual VM) and profiling
> (or checking the performance) on certain parts of my app, and more and
> more, I am removing,
>
> ORDER BY ...
>
> from my queries, and reverting to Collections.sort() + Comparator.
>
> Is there an index on this 'reasonDesc'? What is 'reasonDesc'.length(), on
> average?
>
> If this is the reason why TomEE [and your app] is degrading, then please
> change your query, and remove the ORDER BY ..., and sort your data some
> other way.
>
> Refer to your database tuning document. I use Apache Derby, and they have
> a very nice/comprehensive 'Tuning Derby' guide that I have referred to in
> the past, when my app went to production.
>
>
I have seen/heard MyFaces and/or TomEE committers say/recommend that they
do a lot of 'caching' to improve the performance of their app. Caching
what? Caching data that can [or should] be cached.
Can the result set of the following be cached in an @ApplicationScoped bean
(when app starts OR on the first time that the query is needed/executed)?
<ejb-ql>select object(o) from BreakReason o order by o.reasonDesc</ejb-ql>
In my app, there are a few queries, where the result set is used in a
dropdown (or JSF selectOneMenu). I cache the result set of those queries in
@PostConstruct of my [one and only] @ApplicationScoped bean.
Will TomEE [or my/your app] 'degrade' when caching such result sets? No,
because TomEE [or my/your app] will not need [or refer to] a @Stateless
@EJB to get this data during runtime...so many times.
Also to clarify what I said earlier about removing ORDER BY ...,
yes, I have some quite complex SQL, and when I profile the app (via
jvisualvm), I find that Apache Derby source code is not performing well
with [my] SQL and/or [my] database design, etc...
So, I replace ORDER BY ... with Collections.sort() + Comparator.
Also, as Jean-Louis asked/recommended, I have a [small] statement cache
setting on my database <Resource .../>
<Resource id="jdbc/mcmsJta" type="javax.sql.DataSource">
JdbcDriver org.apache.derby.jdbc.EmbeddedDriver
JdbcUrl jdbc:derby:C:/javadb/databases/...;create=true
...
jdbcInterceptors=StatementCache(max=128)
</Resource>
Also, I am using JPA @NamedQueries on many of the popular/most-used queries
in the app, especially those that are more complex and don't [always]
perform well.
Also, my JPA = EclipseLink, and I use query hints, see below.
public List<Driver> findAllAvailableSelectOne() {
return em.createNamedQuery("Driver.findAllAvailableSelectOne")
.setHint("eclipselink.query-results-cache", "true")
.setHint("eclipselink.read-only", "true")
.getResultList();
}
where the @NamedQuery is defined as follows:
@NamedQuery(name = "Driver.findAllAvailableSelectOne", query = "SELECT
d FROM Driver d WHERE d.includeInLookupList = 'Y' ORDER BY d.driverName"),
Interesting, I could probably cache the result set of this query in my
@ApplicationScoped bean, but d.includeInLookupList can/may be changed by
enduser, sometime during runtime, but enduser does not change that value
unless Driver/Employee is terminated or hired. :)
I may have to write some code to cache this result set in my
@ApplicationScoped bean, and if enduser changes any 'Driver' in the
database, then I will have to update the List<Driver> in my
@ApplicationScoped bean. Hmmm, thanks for calling my attention to this
query in my app. :)
Re: TomEE performance degrades gradually
Posted by ivan_nikitsenka <ni...@gmail.com>.
Yes, i'm using next cache properties
openjpa.QueryCache=true(CacheSize=1000, SoftReferenceSize=100)
openjpa.DataCache=true(CacheSize=5000, SoftReferenceSize=0)
openjpa.RemoteCommitProvider=sjvm
but the issue exist independently of cache. The only difference is with
cache enabled it has better initial performance but after 500 and more
requests it becomes twice worse.
--
View this message in context: http://openejb.979440.n4.nabble.com/TomEE-performance-degrades-gradually-tp4668090p4668650.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: TomEE performance degrades gradually
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Fri, Apr 4, 2014 at 5:46 AM, ivan nikitsenka <ni...@gmail.com>wrote:
>
> <query>
> <description></description>
> <query-method>
> <method-name>findAll</method-name>
> <method-params></method-params>
> </query-method>
> <ejb-ql>select object(o) from BreakReason o order by
> o.reasonDesc</ejb-ql>
> </query>
Seriously? ORDER BY a 'reasonDesc'?
Every now and then, I am opening jvisualvm (Java Visual VM) and profiling
(or checking the performance) on certain parts of my app, and more and
more, I am removing,
ORDER BY ...
from my queries, and reverting to Collections.sort() + Comparator.
Is there an index on this 'reasonDesc'? What is 'reasonDesc'.length(), on
average?
If this is the reason why TomEE [and your app] is degrading, then please
change your query, and remove the ORDER BY ..., and sort your data some
other way.
Refer to your database tuning document. I use Apache Derby, and they have a
very nice/comprehensive 'Tuning Derby' guide that I have referred to in the
past, when my app went to production.