Re: [JBoss-user] Entity Bean Performance Tuning Help
Would this allow JBossQL be used in an ad-hoc manner? So you could use it in a very similar way to JDBC, but in the EJB domain rather than the database domain? A simple solution might be to have a JBossQL - Native SQL convertor, so you can use the standard JDBC functionality provided by your database, but write your queries in JBossQL. I expect this functionality must already exist somewhere. On Tue, 2002-11-12 at 19:10, Dain Sundstrom wrote: Pete, To better support complex reporting we just need to add more features to JBossQL select statements (e.g., group by, having, sub queries, and multiple fields in the select clause). I plan on adding most of these features. It would be cool if sun added this stuff, but I find it incredibly unlikely. What Michael is proposing is adding INSERT, UPDATE, and DELETE statements to JBossQL. This is a very cool idea and I hope he spends some time designing a grammar. Once we have a grammar the implementation should be fairly easy. -dain -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-- Experts in e-business and e-commerce --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
What you have described is almost all available now. You can execute any JBossQL at runtime using DynamicQL. To make it available to any code, just add a home method to some bean the calls an internal ejbSelect method that is mapped to DynamicQL. What this doesn't get you is the ability to query across applications. I also don't know what you mean by standard JDBC functionality. -dain Pete Beck wrote: Would this allow JBossQL be used in an ad-hoc manner? So you could use it in a very similar way to JDBC, but in the EJB domain rather than the database domain? A simple solution might be to have a JBossQL - Native SQL convertor, so you can use the standard JDBC functionality provided by your database, but write your queries in JBossQL. I expect this functionality must already exist somewhere. On Tue, 2002-11-12 at 19:10, Dain Sundstrom wrote: Pete, To better support complex reporting we just need to add more features to JBossQL select statements (e.g., group by, having, sub queries, and multiple fields in the select clause). I plan on adding most of these features. It would be cool if sun added this stuff, but I find it incredibly unlikely. What Michael is proposing is adding INSERT, UPDATE, and DELETE statements to JBossQL. This is a very cool idea and I hope he spends some time designing a grammar. Once we have a grammar the implementation should be fairly easy. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Michael Bartmann wrote: Dain, I could help defining the grammar; unfortunately I'm quite busy this week and on a long sought vacation next week, so you'll have to be patient with me. No rush; I won't be able to get to it for a while anyway. The current grammar for JBossQL is not exactly tiny, at least the JavaCC representation is a bit difficult to read due to the way JavaCC grammars model nested expressions. But the things we will have to extend work on a higher syntactical level mostly, as in UPDATE SomeEntity SET SomeField=expression which could use similar low level tokens as the existing grammar when doing SELECT ... WHERE SomeField=expression Agreed We'll also have to decide which features are to be supported; One thing to think about is resultset postprocessing: e.g. in the case of a container iterating over a resultset it _could_ do some postprocessing if there is no adequate sql equivalent of the eql query. Example: SELECT arcsinh(SomeField) ... with a database not supporting that function. This smells like jet-engine anyway; I would speak against such postprocessing. One reason is my original wish to support providing the generated sql to any SLSB, and the session would simply pump it into a jdbc driver without any knowledge about need for postprocessing. So are we speaking only of a transformation engine mapping eql/jbossql to db specific sql, as would suffice in the case of UPDATES, where there is no need to postprocess anyway? I have no plans to do any post processing. I also don't have plans for a real query engine. All I plan on writing my self is a cross compiler. If someone wants to write it, that would be cool. That leaves the problem of function support across all databases. My current plan it to simply throw some sort of unsupported function exception when the query is compiled (deployment or at runtime for DynamicQL). -dain --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help (intersection)
That shouldn't be to hard once we add support for sub queries, but
unless it is supported by most of the major vendors (postgres, oracle,
ms, ibm), it wouldn't be worth the work.
-dain
[EMAIL PROTECTED] wrote:
On Tue, Nov 12, 2002 at 04:53:28PM -0600, Dain Sundstrom wrote:
What is an INTERSECTION query?
From postgresql-help:
Syntax:
SELECT [ ALL | DISTINCT [ ON ( expression [, ...] ) ] ]
* | expression [ AS output_name ] [, ...]
[ FROM from_item [, ...] ]
[ WHERE condition ]
[ GROUP BY expression [, ...] ]
[ HAVING condition [, ...] ]
***[ { UNION | INTERSECT | EXCEPT [ ALL ] } select ] ***
[ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
[ FOR UPDATE [ OF tablename [, ...] ] ]
[ LIMIT { count | ALL } [ { OFFSET | , } start ]]
I think it is used like:
SELECT personID from persondata where datatype=1 AND value=ln1
INTERSECT
SELECT personID from persondata where datatype=2 AND value=ln2
finds the persons registered with ln1 as datatype 1 and ln2 as datatype 2.
I think the obvious solution SELECT personID from persondata where (datatype=1 AND value=ln1) AND (datatype=2 AND value=ln2) doesn't work, as it compares one and one row.
In this table, personID isn't unique.
Is it widely supported?
I suppose so in the major DBs, if it isn't a simpler solution to this problem (using just one SQL statement).
In addition UNION and EXCEPT should be implemented (if these are not possible to work around).
---
This sf.net email is sponsored by: Are you worried about
your web server security? Click here for a FREE Thawte
Apache SSL Guide and answer your Apache SSL security
needs: http://www.gothawte.com/rd523.html
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help (intersection)
Don't know who supports it, but it is standard sql-92 (intermed level, not
entry)
david jencks
On 2002.11.13 10:12:35 -0500 Dain Sundstrom wrote:
That shouldn't be to hard once we add support for sub queries, but
unless it is supported by most of the major vendors (postgres, oracle,
ms, ibm), it wouldn't be worth the work.
-dain
[EMAIL PROTECTED] wrote:
On Tue, Nov 12, 2002 at 04:53:28PM -0600, Dain Sundstrom wrote:
What is an INTERSECTION query?
From postgresql-help:
Syntax:
SELECT [ ALL | DISTINCT [ ON ( expression [, ...] ) ] ]
* | expression [ AS output_name ] [, ...]
[ FROM from_item [, ...] ]
[ WHERE condition ]
[ GROUP BY expression [, ...] ]
[ HAVING condition [, ...] ]
***[ { UNION | INTERSECT | EXCEPT [ ALL ] } select ] ***
[ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
[ FOR UPDATE [ OF tablename [, ...] ] ]
[ LIMIT { count | ALL } [ { OFFSET | , } start ]]
I think it is used like:
SELECT personID from persondata where datatype=1 AND value=ln1
INTERSECT
SELECT personID from persondata where datatype=2 AND value=ln2
finds the persons registered with ln1 as datatype 1 and ln2 as datatype
2.
I think the obvious solution SELECT personID from persondata where
(datatype=1 AND value=ln1) AND (datatype=2 AND value=ln2) doesn't
work, as it compares one and one row.
In this table, personID isn't unique.
Is it widely supported?
I suppose so in the major DBs, if it isn't a simpler solution to this
problem (using just one SQL statement).
In addition UNION and EXCEPT should be implemented (if these are not
possible to work around).
---
This sf.net email is sponsored by: Are you worried about
your web server security? Click here for a FREE Thawte
Apache SSL Guide and answer your Apache SSL security
needs: http://www.gothawte.com/rd523.html
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: Are you worried about
your web server security? Click here for a FREE Thawte
Apache SSL Guide and answer your Apache SSL security
needs: http://www.gothawte.com/rd523.html
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Even better would be if Sun added something to the spec. It seems to me that this is a fundamental limitation of CMP 2. No matter how fast the container, it is difficult to see how it would ever be able to do complex reports using CMP without such a feature. Some reports may only return a few records, but might require millions of database records to be processed first. On Fri, 2002-11-08 at 17:08, Dain Sundstrom wrote: That is a super cool idea. This could easily fit into the 4.0 architecture. Do you want to work on proposing a grammar for insert, update, and delete? Once we have a grammar the conversation to sql is simple, and we can easily throw in cache updating logic. -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-- Experts in e-business and e-commerce --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Pete, To better support complex reporting we just need to add more features to JBossQL select statements (e.g., group by, having, sub queries, and multiple fields in the select clause). I plan on adding most of these features. It would be cool if sun added this stuff, but I find it incredibly unlikely. What Michael is proposing is adding INSERT, UPDATE, and DELETE statements to JBossQL. This is a very cool idea and I hope he spends some time designing a grammar. Once we have a grammar the implementation should be fairly easy. -dain Pete Beck wrote: Even better would be if Sun added something to the spec. It seems to me that this is a fundamental limitation of CMP 2. No matter how fast the container, it is difficult to see how it would ever be able to do complex reports using CMP without such a feature. Some reports may only return a few records, but might require millions of database records to be processed first. On Fri, 2002-11-08 at 17:08, Dain Sundstrom wrote: That is a super cool idea. This could easily fit into the 4.0 architecture. Do you want to work on proposing a grammar for insert, update, and delete? Once we have a grammar the conversation to sql is simple, and we can easily throw in cache updating logic. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help (intersection)
What about adding INTERSECTION-queries (whis is possible in postgresql)? Or is it possible by some easy workaround now? On tir, 2002-11-12 at 20:10, Dain Sundstrom wrote: Pete, To better support complex reporting we just need to add more features to JBossQL select statements (e.g., group by, having, sub queries, and multiple fields in the select clause). I plan on adding most of these features. It would be cool if sun added this stuff, but I find it incredibly unlikely. What Michael is proposing is adding INSERT, UPDATE, and DELETE statements to JBossQL. This is a very cool idea and I hope he spends some time designing a grammar. Once we have a grammar the implementation should be fairly easy. -dain Pete Beck wrote: Even better would be if Sun added something to the spec. It seems to me that this is a fundamental limitation of CMP 2. No matter how fast the container, it is difficult to see how it would ever be able to do complex reports using CMP without such a feature. Some reports may only return a few records, but might require millions of database records to be processed first. On Fri, 2002-11-08 at 17:08, Dain Sundstrom wrote: That is a super cool idea. This could easily fit into the 4.0 architecture. Do you want to work on proposing a grammar for insert, update, and delete? Once we have a grammar the conversation to sql is simple, and we can easily throw in cache updating logic. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help (intersection)
What is an INTERSECTION query? Is it widely supported? -dain Marius Kotsbak wrote: What about adding INTERSECTION-queries (whis is possible in postgresql)? Or is it possible by some easy workaround now? On tir, 2002-11-12 at 20:10, Dain Sundstrom wrote: Pete, To better support complex reporting we just need to add more features to JBossQL select statements (e.g., group by, having, sub queries, and multiple fields in the select clause). I plan on adding most of these features. It would be cool if sun added this stuff, but I find it incredibly unlikely. What Michael is proposing is adding INSERT, UPDATE, and DELETE statements to JBossQL. This is a very cool idea and I hope he spends some time designing a grammar. Once we have a grammar the implementation should be fairly easy. -dain Pete Beck wrote: Even better would be if Sun added something to the spec. It seems to me that this is a fundamental limitation of CMP 2. No matter how fast the container, it is difficult to see how it would ever be able to do complex reports using CMP without such a feature. Some reports may only return a few records, but might require millions of database records to be processed first. On Fri, 2002-11-08 at 17:08, Dain Sundstrom wrote: That is a super cool idea. This could easily fit into the 4.0 architecture. Do you want to work on proposing a grammar for insert, update, and delete? Once we have a grammar the conversation to sql is simple, and we can easily throw in cache updating logic. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Dain, I could help defining the grammar; unfortunately I'm quite busy this week and on a long sought vacation next week, so you'll have to be patient with me. The current grammar for JBossQL is not exactly tiny, at least the JavaCC representation is a bit difficult to read due to the way JavaCC grammars model nested expressions. But the things we will have to extend work on a higher syntactical level mostly, as in UPDATE SomeEntity SET SomeField=expression which could use similar low level tokens as the existing grammar when doing SELECT ... WHERE SomeField=expression We'll also have to decide which features are to be supported; One thing to think about is resultset postprocessing: e.g. in the case of a container iterating over a resultset it _could_ do some postprocessing if there is no adequate sql equivalent of the eql query. Example: SELECT arcsinh(SomeField) ... with a database not supporting that function. This smells like jet-engine anyway; I would speak against such postprocessing. One reason is my original wish to support providing the generated sql to any SLSB, and the session would simply pump it into a jdbc driver without any knowledge about need for postprocessing. So are we speaking only of a transformation engine mapping eql/jbossql to db specific sql, as would suffice in the case of UPDATES, where there is no need to postprocess anyway? Regards, Michael Bartmann Dain Sundstrom wrote: Pete, To better support complex reporting we just need to add more features to JBossQL select statements (e.g., group by, having, sub queries, and multiple fields in the select clause). I plan on adding most of these features. It would be cool if sun added this stuff, but I find it incredibly unlikely. What Michael is proposing is adding INSERT, UPDATE, and DELETE statements to JBossQL. This is a very cool idea and I hope he spends some time designing a grammar. Once we have a grammar the implementation should be fairly easy. -dain Pete Beck wrote: Even better would be if Sun added something to the spec. It seems to me that this is a fundamental limitation of CMP 2. No matter how fast the container, it is difficult to see how it would ever be able to do complex reports using CMP without such a feature. Some reports may only return a few records, but might require millions of database records to be processed first. On Fri, 2002-11-08 at 17:08, Dain Sundstrom wrote: That is a super cool idea. This could easily fit into the 4.0 architecture. Do you want to work on proposing a grammar for insert, update, and delete? Once we have a grammar the conversation to sql is simple, and we can easily throw in cache updating logic. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
That is a super cool idea. This could easily fit into the 4.0 architecture. Do you want to work on proposing a grammar for insert, update, and delete? Once we have a grammar the conversation to sql is simple, and we can easily throw in cache updating logic. -dain Michael Bartmann wrote: Dain, please be patient with me, perhaps I simply don't know enough of what is possible with cmp2. Is there a way to let a SLSB perform a statement directly on the jdbc datasource using _only_ eql? So do something like: update SomeEntity set SomeField=5 where SomeOtherField=3 instead of: update SomeTable set SomeColumn=5 where SomeOtherColumn=3 With directly on the jdbc ds I mean that the result should be the same as if I did invoke the equivalent sql through the jdbc driver. No bean cache affected, simply transform eql to sql and feed it into a jdbc statement. I am aware that update has no meaning for eql finders, but I hope you get the idea. Regards, Michael Dain Sundstrom wrote: Now I am completely confused. What exactly do you want that you can't do today? -dain Michael Bartmann wrote: Dain, I'm a bit confused (especially by your phrase in memory query) and I don't know if you misunderstood me (or Pete's original post) or I misunderstand you. I'll try to make clear what I meant: 1) we have a jboss with cmp2 container and deployed entities, so this container knows how to handle eql, transform it into sql and send it to the jdbc layer. 2a) if you do mass queries or updates and you decide that you want to circumvent the container/cache/interceptors for performance reasons you are normally bound to plain sql queries to the jdbc layer. So you are forced to circumvent the tablename - entityname abstraction, the columnname - methodname abstraction and must handle db specific sql dialects. 2b) if we had means to let the container translate eql to sql because it knows the relevant metadata, we could use it to feed it into jdbc, and only need to handle the ResultSet iteration programmatically. There is no such thing as in memor sql; we would use the normal oracle/hypersonic whatsoever db the container uses for is transactions. You might argue that we should not need to use 2a or 2b anyway if make the container really fast. And even readonly sql has to do transaction isolation right to not interfere with the container and deadlock in the worst case. But I must admit that we use plain sql in our application (which was developed under jboss 2.4 first, which might count as an excuse). And loosing the eql abstraction is a maintenance nightmare. Just my 2cent, Michael Dain Sundstrom wrote: Michael, The idea for an in memory query engine is interesting, but this requires that all of you data to fit into memory and actually be in memory. If you want to write it, that would be cool, but I think there are way more important things to make CMP fast. -dain Michael Bartmann wrote: Comments inline, Regards, Michael saroj kumar wrote: Running EJB-QL without Container/EB We need to consider few points. 1) If there is no container then how do we parse the XML? As I understand the main usecase: We _have_ entities (tereby xml) and containers, but have a way to circumvent the container in case of queries, which would otherwise done so in an inferiour fashion (pure sql). 2) If there are no Entity beans then how do you query? We could have an mbean which has enough information from the container config to convert eql to sql. 3) If Above points are sorted out then how do we achieve complex joins/unions? Good question; this is a shortcomming of eql (by design?). 4) Moreover, In case of large projects, describing the schema in XML may require some tools Otherwise, the sheer sixe of DB will prevent users. Again, we only consider a way to prevent a mixture of entities and plain sql in the application, so thing can only get better. This becomes crucial if the changes to DB are quite frequent. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Michael Bartmann Sent: Wednesday, November 06, 2002 6:09 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Absolutely! I don't have to add much to this, but I think that this request (non-container ejb-ql) is so important (and a good workaround, too), that I simply couldn't resist to reply. Anyway, would this be difficult to achieve? Regards, Michael Bartmann Pete Beck wrote: On Tue, 2002-10-29 at 17:28, Bill Burke wrote: JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group
Re: [JBoss-user] Entity Bean Performance Tuning Help
Dain, please be patient with me, perhaps I simply don't know enough of what is possible with cmp2. Is there a way to let a SLSB perform a statement directly on the jdbc datasource using _only_ eql? So do something like: update SomeEntity set SomeField=5 where SomeOtherField=3 instead of: update SomeTable set SomeColumn=5 where SomeOtherColumn=3 With directly on the jdbc ds I mean that the result should be the same as if I did invoke the equivalent sql through the jdbc driver. No bean cache affected, simply transform eql to sql and feed it into a jdbc statement. I am aware that update has no meaning for eql finders, but I hope you get the idea. Regards, Michael Dain Sundstrom wrote: Now I am completely confused. What exactly do you want that you can't do today? -dain Michael Bartmann wrote: Dain, I'm a bit confused (especially by your phrase in memory query) and I don't know if you misunderstood me (or Pete's original post) or I misunderstand you. I'll try to make clear what I meant: 1) we have a jboss with cmp2 container and deployed entities, so this container knows how to handle eql, transform it into sql and send it to the jdbc layer. 2a) if you do mass queries or updates and you decide that you want to circumvent the container/cache/interceptors for performance reasons you are normally bound to plain sql queries to the jdbc layer. So you are forced to circumvent the tablename - entityname abstraction, the columnname - methodname abstraction and must handle db specific sql dialects. 2b) if we had means to let the container translate eql to sql because it knows the relevant metadata, we could use it to feed it into jdbc, and only need to handle the ResultSet iteration programmatically. There is no such thing as in memor sql; we would use the normal oracle/hypersonic whatsoever db the container uses for is transactions. You might argue that we should not need to use 2a or 2b anyway if make the container really fast. And even readonly sql has to do transaction isolation right to not interfere with the container and deadlock in the worst case. But I must admit that we use plain sql in our application (which was developed under jboss 2.4 first, which might count as an excuse). And loosing the eql abstraction is a maintenance nightmare. Just my 2cent, Michael Dain Sundstrom wrote: Michael, The idea for an in memory query engine is interesting, but this requires that all of you data to fit into memory and actually be in memory. If you want to write it, that would be cool, but I think there are way more important things to make CMP fast. -dain Michael Bartmann wrote: Comments inline, Regards, Michael saroj kumar wrote: Running EJB-QL without Container/EB We need to consider few points. 1) If there is no container then how do we parse the XML? As I understand the main usecase: We _have_ entities (tereby xml) and containers, but have a way to circumvent the container in case of queries, which would otherwise done so in an inferiour fashion (pure sql). 2) If there are no Entity beans then how do you query? We could have an mbean which has enough information from the container config to convert eql to sql. 3) If Above points are sorted out then how do we achieve complex joins/unions? Good question; this is a shortcomming of eql (by design?). 4) Moreover, In case of large projects, describing the schema in XML may require some tools Otherwise, the sheer sixe of DB will prevent users. Again, we only consider a way to prevent a mixture of entities and plain sql in the application, so thing can only get better. This becomes crucial if the changes to DB are quite frequent. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Michael Bartmann Sent: Wednesday, November 06, 2002 6:09 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Absolutely! I don't have to add much to this, but I think that this request (non-container ejb-ql) is so important (and a good workaround, too), that I simply couldn't resist to reply. Anyway, would this be difficult to achieve? Regards, Michael Bartmann Pete Beck wrote: On Tue, 2002-10-29 at 17:28, Bill Burke wrote: JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. Regarding Bill's comment about reporting; this is *so* true. IMHO this is one of the biggest problems that needs to be addressed in the EJB spec. However dropping to JDBC is not the answer either. Unfortunately, there is currently little choice. What is needed is the ability to run
RE: [JBoss-user] Entity Bean Performance Tuning Help
On Tue, 2002-10-29 at 17:28, Bill Burke wrote: JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. Regarding Bill's comment about reporting; this is *so* true. IMHO this is one of the biggest problems that needs to be addressed in the EJB spec. However dropping to JDBC is not the answer either. Unfortunately, there is currently little choice. What is needed is the ability to run queries directly in EJB-QL. Having to use JDBC means your application is dependent on the database domain. In other words, the application designer has to know about the implementation specifics of the persistence layer (database). Being able to execute queries in EJB-QL would allow us to use bean names and property names. -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-- Experts in e-business and e-commerce --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Absolutely! I don't have to add much to this, but I think that this request (non-container ejb-ql) is so important (and a good workaround, too), that I simply couldn't resist to reply. Anyway, would this be difficult to achieve? Regards, Michael Bartmann Pete Beck wrote: On Tue, 2002-10-29 at 17:28, Bill Burke wrote: JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. Regarding Bill's comment about reporting; this is *so* true. IMHO this is one of the biggest problems that needs to be addressed in the EJB spec. However dropping to JDBC is not the answer either. Unfortunately, there is currently little choice. What is needed is the ability to run queries directly in EJB-QL. Having to use JDBC means your application is dependent on the database domain. In other words, the application designer has to know about the implementation specifics of the persistence layer (database). Being able to execute queries in EJB-QL would allow us to use bean names and property names. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
Running EJB-QL without Container/EB We need to consider few points. 1) If there is no container then how do we parse the XML? 2) If there are no Entity beans then how do you query? 3) If Above points are sorted out then how do we achieve complex joins/unions? 4) Moreover, In case of large projects, describing the schema in XML may require some tools Otherwise, the sheer sixe of DB will prevent users. This becomes crucial if the changes to DB are quite frequent. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Michael Bartmann Sent: Wednesday, November 06, 2002 6:09 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Absolutely! I don't have to add much to this, but I think that this request (non-container ejb-ql) is so important (and a good workaround, too), that I simply couldn't resist to reply. Anyway, would this be difficult to achieve? Regards, Michael Bartmann Pete Beck wrote: On Tue, 2002-10-29 at 17:28, Bill Burke wrote: JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. Regarding Bill's comment about reporting; this is *so* true. IMHO this is one of the biggest problems that needs to be addressed in the EJB spec. However dropping to JDBC is not the answer either. Unfortunately, there is currently little choice. What is needed is the ability to run queries directly in EJB-QL. Having to use JDBC means your application is dependent on the database domain. In other words, the application designer has to know about the implementation specifics of the persistence layer (database). Being able to execute queries in EJB-QL would allow us to use bean names and property names. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user **Disclaimer** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited.
Re: [JBoss-user] Entity Bean Performance Tuning Help
Comments inline, Regards, Michael saroj kumar wrote: Running EJB-QL without Container/EB We need to consider few points. 1) If there is no container then how do we parse the XML? As I understand the main usecase: We _have_ entities (tereby xml) and containers, but have a way to circumvent the container in case of queries, which would otherwise done so in an inferiour fashion (pure sql). 2) If there are no Entity beans then how do you query? We could have an mbean which has enough information from the container config to convert eql to sql. 3) If Above points are sorted out then how do we achieve complex joins/unions? Good question; this is a shortcomming of eql (by design?). 4) Moreover, In case of large projects, describing the schema in XML may require some tools Otherwise, the sheer sixe of DB will prevent users. Again, we only consider a way to prevent a mixture of entities and plain sql in the application, so thing can only get better. This becomes crucial if the changes to DB are quite frequent. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Michael Bartmann Sent: Wednesday, November 06, 2002 6:09 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Absolutely! I don't have to add much to this, but I think that this request (non-container ejb-ql) is so important (and a good workaround, too), that I simply couldn't resist to reply. Anyway, would this be difficult to achieve? Regards, Michael Bartmann Pete Beck wrote: On Tue, 2002-10-29 at 17:28, Bill Burke wrote: JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. Regarding Bill's comment about reporting; this is *so* true. IMHO this is one of the biggest problems that needs to be addressed in the EJB spec. However dropping to JDBC is not the answer either. Unfortunately, there is currently little choice. What is needed is the ability to run queries directly in EJB-QL. Having to use JDBC means your application is dependent on the database domain. In other words, the application designer has to know about the implementation specifics of the persistence layer (database). Being able to execute queries in EJB-QL would allow us to use bean names and property names. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user **Disclaimer** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
onsdagen den 6 november 2002 kl 13.51 skrev saroj kumar: 1) If there is no container then how do we parse the XML? 2) If there are no Entity beans then how do you query? 3) If Above points are sorted out then how do we achieve complex joins/unions? How would Hibernate stand up ? ... As a bonus Hibernate has a JMX component to be run in jboss - how-to configure Hibernate JMX in JBoss in the FAQ section. /peter_f *** from Performance QA @ http://hibernate.sourceforge.net/ We claim that Hibernate performs well, in the sense that its performance is limited by the underlying JDBC driver / relational database combination. (Generally the overhead is between 5% and 15% of the JDBC calls.) *** *** from About Hibernate FAQ @ http://hibernate.sourceforge.net/ Use a Session EJB to control transactional scope, security, threading and remoteablity. Use Hibernate for persistence. Arguably, the J2EE architecture went wrong when it tried to address too many separate problems with a one-size-fits-all solution. Most business objects are too fine grained to make good entity beans. *** *** from Best Practices @ http://hibernate.sourceforge.net/ use hand-coded JDBC in bottlenecks In performance-critical areas of the system, some kinds of operations (eg. mass update / delete) might benefit from direct JDBC. But please, wait until you know something is a bottleneck. And don''t assume that direct JDBC is necessarily faster. If you need to use direct JDBC, it might be worth opening a Hibernate Session and using that SQL connection. That way you can still use the same transaction strategy and underlying connection provider. *** --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Michael, The idea for an in memory query engine is interesting, but this requires that all of you data to fit into memory and actually be in memory. If you want to write it, that would be cool, but I think there are way more important things to make CMP fast. -dain Michael Bartmann wrote: Comments inline, Regards, Michael saroj kumar wrote: Running EJB-QL without Container/EB We need to consider few points. 1) If there is no container then how do we parse the XML? As I understand the main usecase: We _have_ entities (tereby xml) and containers, but have a way to circumvent the container in case of queries, which would otherwise done so in an inferiour fashion (pure sql). 2) If there are no Entity beans then how do you query? We could have an mbean which has enough information from the container config to convert eql to sql. 3) If Above points are sorted out then how do we achieve complex joins/unions? Good question; this is a shortcomming of eql (by design?). 4) Moreover, In case of large projects, describing the schema in XML may require some tools Otherwise, the sheer sixe of DB will prevent users. Again, we only consider a way to prevent a mixture of entities and plain sql in the application, so thing can only get better. This becomes crucial if the changes to DB are quite frequent. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Michael Bartmann Sent: Wednesday, November 06, 2002 6:09 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Absolutely! I don't have to add much to this, but I think that this request (non-container ejb-ql) is so important (and a good workaround, too), that I simply couldn't resist to reply. Anyway, would this be difficult to achieve? Regards, Michael Bartmann Pete Beck wrote: On Tue, 2002-10-29 at 17:28, Bill Burke wrote: JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. Regarding Bill's comment about reporting; this is *so* true. IMHO this is one of the biggest problems that needs to be addressed in the EJB spec. However dropping to JDBC is not the answer either. Unfortunately, there is currently little choice. What is needed is the ability to run queries directly in EJB-QL. Having to use JDBC means your application is dependent on the database domain. In other words, the application designer has to know about the implementation specifics of the persistence layer (database). Being able to execute queries in EJB-QL would allow us to use bean names and property names. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user **Disclaimer** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Dain, I'm a bit confused (especially by your phrase in memory query) and I don't know if you misunderstood me (or Pete's original post) or I misunderstand you. I'll try to make clear what I meant: 1) we have a jboss with cmp2 container and deployed entities, so this container knows how to handle eql, transform it into sql and send it to the jdbc layer. 2a) if you do mass queries or updates and you decide that you want to circumvent the container/cache/interceptors for performance reasons you are normally bound to plain sql queries to the jdbc layer. So you are forced to circumvent the tablename - entityname abstraction, the columnname - methodname abstraction and must handle db specific sql dialects. 2b) if we had means to let the container translate eql to sql because it knows the relevant metadata, we could use it to feed it into jdbc, and only need to handle the ResultSet iteration programmatically. There is no such thing as in memor sql; we would use the normal oracle/hypersonic whatsoever db the container uses for is transactions. You might argue that we should not need to use 2a or 2b anyway if make the container really fast. And even readonly sql has to do transaction isolation right to not interfere with the container and deadlock in the worst case. But I must admit that we use plain sql in our application (which was developed under jboss 2.4 first, which might count as an excuse). And loosing the eql abstraction is a maintenance nightmare. Just my 2cent, Michael Dain Sundstrom wrote: Michael, The idea for an in memory query engine is interesting, but this requires that all of you data to fit into memory and actually be in memory. If you want to write it, that would be cool, but I think there are way more important things to make CMP fast. -dain Michael Bartmann wrote: Comments inline, Regards, Michael saroj kumar wrote: Running EJB-QL without Container/EB We need to consider few points. 1) If there is no container then how do we parse the XML? As I understand the main usecase: We _have_ entities (tereby xml) and containers, but have a way to circumvent the container in case of queries, which would otherwise done so in an inferiour fashion (pure sql). 2) If there are no Entity beans then how do you query? We could have an mbean which has enough information from the container config to convert eql to sql. 3) If Above points are sorted out then how do we achieve complex joins/unions? Good question; this is a shortcomming of eql (by design?). 4) Moreover, In case of large projects, describing the schema in XML may require some tools Otherwise, the sheer sixe of DB will prevent users. Again, we only consider a way to prevent a mixture of entities and plain sql in the application, so thing can only get better. This becomes crucial if the changes to DB are quite frequent. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Michael Bartmann Sent: Wednesday, November 06, 2002 6:09 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Absolutely! I don't have to add much to this, but I think that this request (non-container ejb-ql) is so important (and a good workaround, too), that I simply couldn't resist to reply. Anyway, would this be difficult to achieve? Regards, Michael Bartmann Pete Beck wrote: On Tue, 2002-10-29 at 17:28, Bill Burke wrote: JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. Regarding Bill's comment about reporting; this is *so* true. IMHO this is one of the biggest problems that needs to be addressed in the EJB spec. However dropping to JDBC is not the answer either. Unfortunately, there is currently little choice. What is needed is the ability to run queries directly in EJB-QL. Having to use JDBC means your application is dependent on the database domain. In other words, the application designer has to know about the implementation specifics of the persistence layer (database). Being able to execute queries in EJB-QL would allow us to use bean names and property names. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user **Disclaimer
Re: [JBoss-user] Entity Bean Performance Tuning Help
Now I am completely confused. What exactly do you want that you can't do today? -dain Michael Bartmann wrote: Dain, I'm a bit confused (especially by your phrase in memory query) and I don't know if you misunderstood me (or Pete's original post) or I misunderstand you. I'll try to make clear what I meant: 1) we have a jboss with cmp2 container and deployed entities, so this container knows how to handle eql, transform it into sql and send it to the jdbc layer. 2a) if you do mass queries or updates and you decide that you want to circumvent the container/cache/interceptors for performance reasons you are normally bound to plain sql queries to the jdbc layer. So you are forced to circumvent the tablename - entityname abstraction, the columnname - methodname abstraction and must handle db specific sql dialects. 2b) if we had means to let the container translate eql to sql because it knows the relevant metadata, we could use it to feed it into jdbc, and only need to handle the ResultSet iteration programmatically. There is no such thing as in memor sql; we would use the normal oracle/hypersonic whatsoever db the container uses for is transactions. You might argue that we should not need to use 2a or 2b anyway if make the container really fast. And even readonly sql has to do transaction isolation right to not interfere with the container and deadlock in the worst case. But I must admit that we use plain sql in our application (which was developed under jboss 2.4 first, which might count as an excuse). And loosing the eql abstraction is a maintenance nightmare. Just my 2cent, Michael Dain Sundstrom wrote: Michael, The idea for an in memory query engine is interesting, but this requires that all of you data to fit into memory and actually be in memory. If you want to write it, that would be cool, but I think there are way more important things to make CMP fast. -dain Michael Bartmann wrote: Comments inline, Regards, Michael saroj kumar wrote: Running EJB-QL without Container/EB We need to consider few points. 1) If there is no container then how do we parse the XML? As I understand the main usecase: We _have_ entities (tereby xml) and containers, but have a way to circumvent the container in case of queries, which would otherwise done so in an inferiour fashion (pure sql). 2) If there are no Entity beans then how do you query? We could have an mbean which has enough information from the container config to convert eql to sql. 3) If Above points are sorted out then how do we achieve complex joins/unions? Good question; this is a shortcomming of eql (by design?). 4) Moreover, In case of large projects, describing the schema in XML may require some tools Otherwise, the sheer sixe of DB will prevent users. Again, we only consider a way to prevent a mixture of entities and plain sql in the application, so thing can only get better. This becomes crucial if the changes to DB are quite frequent. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Michael Bartmann Sent: Wednesday, November 06, 2002 6:09 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Absolutely! I don't have to add much to this, but I think that this request (non-container ejb-ql) is so important (and a good workaround, too), that I simply couldn't resist to reply. Anyway, would this be difficult to achieve? Regards, Michael Bartmann Pete Beck wrote: On Tue, 2002-10-29 at 17:28, Bill Burke wrote: JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. Regarding Bill's comment about reporting; this is *so* true. IMHO this is one of the biggest problems that needs to be addressed in the EJB spec. However dropping to JDBC is not the answer either. Unfortunately, there is currently little choice. What is needed is the ability to run queries directly in EJB-QL. Having to use JDBC means your application is dependent on the database domain. In other words, the application designer has to know about the implementation specifics of the persistence layer (database). Being able to execute queries in EJB-QL would allow us to use bean names and property names. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
I just tested on JBoss3.0.4 (all previous tests were on 3.0.3). The times are not any better. Heres the output: 19:45:41,671 INFO [STDOUT] testing retrival speed... 19:45:41,671 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache. 19:45:41,937 INFO [STDOUT] finder took 266ms. 19:45:44,640 INFO [STDOUT] External ValueObject creation took 2703ms for 1000 objects. 19:45:45,343 INFO [STDOUT] Internal ValueObject creation took 703ms for 1000 objects. 19:45:45,343 INFO [STDOUT] Secondary Retrival, beans are in cache. 19:45:45,546 INFO [STDOUT] finder took 203ms. 19:45:48,203 INFO [STDOUT] External ValueObject creation took 2657ms for 1000 objects. 19:45:48,890 INFO [STDOUT] Internal ValueObject creation took 687ms for 1000 objects. -Original Message- From: Stephen Coy [mailto:steve;whitesmiths.com.au] Sent: Tuesday, November 05, 2002 5:29 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Hi, Have you tried your tests out on 3.0.4 yet? Some CMR performance optimisations made it into 3.0.4, because we desperately needed them for our own application. Steve Coy On Wednesday, November 6, 2002, at 06:37 AM, Luttrell, Peter wrote: Nope it's defiantly cached. The first time it takes almost 12,000ms to build the beans. Yes that is 10 times slower...course it does have to initiate the db connections, and the db isn't very fast. .peter -Original Message- From: Dain Sundstrom [mailto:dain;daingroup.com] Sent: Monday, November 04, 2002 7:09 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Luttrell, Peter wrote: It is faster. I tried it in response to danch's message early in the thread. Thus I have the same question (which no one commented on): Time ~1200ms is a lot better then the original 2200, but can this still be acceptable for reading ~10 fields from 750ejbs that are 100% cached? Here is the email in this thread reporting the results: I think you will get the same answer, run a profiler and find out what is taking the 1200 ms. It should be obvious. If you can't fix whatever is taking all the time, come back and complain about x being really slow. My guess is the data isn't cached and it is taking 1199 ms to get it from the database and 1 ms to build the value object. -dain --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and will use any and all information and reserve the right to publish or disclose any information you share with us. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Hi, Have you tried your tests out on 3.0.4 yet? Some CMR performance optimisations made it into 3.0.4, because we desperately needed them for our own application. Steve Coy On Wednesday, November 6, 2002, at 06:37 AM, Luttrell, Peter wrote: Nope it's defiantly cached. The first time it takes almost 12,000ms to build the beans. Yes that is 10 times slower...course it does have to initiate the db connections, and the db isn't very fast. .peter -Original Message- From: Dain Sundstrom [mailto:dain;daingroup.com] Sent: Monday, November 04, 2002 7:09 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Luttrell, Peter wrote: It is faster. I tried it in response to danch's message early in the thread. Thus I have the same question (which no one commented on): Time ~1200ms is a lot better then the original 2200, but can this still be acceptable for reading ~10 fields from 750ejbs that are 100% cached? Here is the email in this thread reporting the results: I think you will get the same answer, run a profiler and find out what is taking the 1200 ms. It should be obvious. If you can't fix whatever is taking all the time, come back and complain about x being really slow. My guess is the data isn't cached and it is taking 1199 ms to get it from the database and 1 ms to build the value object. -dain --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
Bills suggestion was that the dataobject creation was the problem. Which i
would agree with based on the trace i had put in.
Bill also suggested that it was my code, which i don't think is the case. I
could be wrong ~ can anyone suggest how i can optimize this constructor:
public MyValueObject(SomeLocalInterface ejb){
name = ejb.getName();
id = ejb.getId();
someOtherField = ejb.getSomeOtherField();
}
There are about 10 fields or so. I did double check and realize that one of
them is a field on a relationship, which may be the source of the problem.
I'll see if i have time this week for a quick sample. Last week was
deployment week.
.peter
-Original Message-
From: Sacha Labourey [mailto:Sacha.Labourey;ml.cogito-info.ch]
Sent: Wednesday, October 30, 2002 3:14 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help
Georg,
It seems that my (and, at least to some degree, Peter's) specific
problem is misunderstood.
...
into a collection of value objects. None of the previous posts (except
Peter's) touches upon this subject.
That's wrong: Bill suggested something wrt to your value object and I
suggested that you provide a small test case on which we could work.
cheers,
Sacha
P.S.: BTW, is your for loop running in a single transaction? What is the
transaction attribute of the code running in the for loop?
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
This transmission contains information solely for intended recipient and may
be privileged, confidential and/or otherwise protect from disclosure. If
you are not the intended recipient, please contact the sender and delete all
copies of this transmission. This message and/or the materials contained
herein are not an offer to sell, or a solicitation of an offer to buy, any
securities or other instruments. The information has been obtained or
derived from sources believed by us to be reliable, but we do not represent
that it is accurate or complete. Any opinions or estimates contained in
this information constitute our judgment as of this date and are subject to
change without notice. Any information you share with us will be used in
the operation of our business, and we do not request and do not want any
material, nonpublic information. Absent an express prior written agreement,
we are not agreeing to treat any information confidentially and will use any
and all information and reserve the right to publish or disclose any
information you share with us.
---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
I was using read-ahead, as it's on by default. See original posting. -Original Message- From: Emerson Cargnin - SICREDI Serviços [mailto:emersonc;sicredi.com.br] Sent: Tuesday, October 29, 2002 1:35 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help i think that maybe using a read-ahead configuration for cmr could turn CMP usable, hence the cause of the slowness (IMHO) is the great number of selects as you navigate through each BEAN. Jason Westra wrote: Dain wrote: I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. This was my point. Sounds like you agree. :) The current CMP design has problems with large, complex reads. You can't effectivly use CMP for everything, nor was the EJB spec's CMP section able solve ALL data query problems. J -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 29, 2002 11:43 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Jason Westra wrote: Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them. I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. The JBoss 4.0 design will be able to benefit from hand tuned queries. I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss fixed. Until then, I'd recommend a different approach than CMP. My goal for the 4.0 architecture is to enable the easy use of a hybrid approach to CMP. In this design you can use CMP for the 98% of you app that performs well under the current code and for the 2% that needs hand code you can plug in a custom interceptor to tune queries. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and will use any and all information and reserve the right to publish or disclose any information you share with us. --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ JBoss-user mailing list
RE: [JBoss-user] Entity Bean Performance Tuning Help
Thanks for the advice. I'll checkout SwiftMQ. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid;ti.com] Sent: Tuesday, October 29, 2002 11:28 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Peter, it's a great relief to see, that I am not the only one... I have not given up hope yet, but I cannot crank out enough hours to get to the core of the problem. In the app I did before the current one, I used the paging and web layer caching approach you suggest, albeit on a small scale. Then I embraced EJB and CMP2.0. Despite my current problems I am still convinced that it was the right decision. I find it more convenient to put my tables inside a div using the overflow:auto css style, so I can simply scroll down the complete list without paging. I am using the JSTL to do the presentation layer. Actually I had JBoss running under OptimizeIt two weeks ago, but then I was distracted and now my evaluation license expired. May be you try to use SwiftMQ (they used to have docs on how to integrate with Jboss on their website). My company did a performance comparison against IBM MQ Series, and SwiftMQ was significantly faster (lean and mean, so to say, but no work flow component etc.). Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Luttrell, Peter Sent: Tuesday, October 29, 2002 17:39 To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg, I used 2 other non-ejb solutions to get what I needed done. Cache the dataobjects in the webtier. It will only work in certain cases, 2/3 in my case. I know it's duplicating work that the ejb container should do, but if there is noting that can be done to JBoss to get performance acceptable then... Paginate the results. Checkout this taglib, it does it all for you automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it better because IE can render the pages very fast, compared to the super long time it takes with large tables. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid;ti.com] Sent: Tuesday, October 29, 2002 2:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a select * from BeanTable. For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so
Re: [JBoss-user] Entity Bean Performance Tuning Help
Luttrell, Peter wrote:
Bill also suggested that it was my code, which i don't think is the case. I
could be wrong ~ can anyone suggest how i can optimize this constructor:
public MyValueObject(SomeLocalInterface ejb){
name = ejb.getName();
id = ejb.getId();
someOtherField = ejb.getSomeOtherField();
}
There are about 10 fields or so. I did double check and realize that one of
them is a field on a relationship, which may be the source of the problem.
You are doing 10 invocations through the ejb layers. The code will be
way more efficient if you put the value object creation code inside the
entity bean. For example
public abstract class MyEntityBean extends EJBObject {
public MyValueObject getValueObject() {
MyValueObject valueObject = new MyValueObject();
valueObject.setName(getName());
valueObject.setId(getId());
valueObject.setSomeOtherField(getSomeOtherField());
}
}
The important difference is the loading of the value object gets all of
the data from the ejb using calls inside of the bean instance and
specifically the calls don't travel over a Remote or Local interface.
This means there is no code interpositioned.
-dain
---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
just a note : extends EJBObject - extends EntityBean
Dain Sundstrom wrote:
Luttrell, Peter wrote:
Bill also suggested that it was my code, which i don't think is the
case. I
could be wrong ~ can anyone suggest how i can optimize this constructor:
public MyValueObject(SomeLocalInterface ejb){
name = ejb.getName();
id = ejb.getId();
someOtherField = ejb.getSomeOtherField();
}
There are about 10 fields or so. I did double check and realize that
one of
them is a field on a relationship, which may be the source of the
problem.
You are doing 10 invocations through the ejb layers. The code will be
way more efficient if you put the value object creation code inside the
entity bean. For example
public abstract class MyEntityBean extends EJBObject {
public MyValueObject getValueObject() {
MyValueObject valueObject = new MyValueObject();
valueObject.setName(getName());
valueObject.setId(getId());
valueObject.setSomeOtherField(getSomeOtherField());
}
}
The important difference is the loading of the value object gets all of
the data from the ejb using calls inside of the bean instance and
specifically the calls don't travel over a Remote or Local interface.
This means there is no code interpositioned.
-dain
---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
--
| Emerson Cargnin |
| Analista de Sistemas Sr. |
| Tel : (051) 3358-4959|
| SICREDI Serviços |
| Porto Alegre - Brasil|
|xx|
---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
It is faster. I tried it in response to danch's message early in the thread.
Thus I have the same question (which no one commented on): Time ~1200ms is
a lot better then the original 2200, but can this still be acceptable for
reading ~10 fields from 750ejbs that are 100% cached?
Here is the email in this thread reporting the results:
That makes sense for the weird timing observations.
I tried the value object pattern with a local ejbHome method. Utilizing a
finder this reduced my time from ~2200ms to ~1600, then i tried an
ejbSelect
which took it down to ~1400ms.
Then i tried your suggestion (bulk getter) and was able to get the time to
about ~1200ms. A lot better then the original 2200, but can this still be
acceptable for reading ~10 fields from 750ejbs that are 100% cached?
Also, the first time though (uncached), is still very long 11,000 ms for
the exact same code and data...course a bit of this is creating db pool
connections.
.peter
-Original Message-
From: Dain Sundstrom [mailto:dain;daingroup.com]
Sent: Monday, November 04, 2002 5:10 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help
Luttrell, Peter wrote:
Bill also suggested that it was my code, which i don't think is the case.
I
could be wrong ~ can anyone suggest how i can optimize this constructor:
public MyValueObject(SomeLocalInterface ejb){
name = ejb.getName();
id = ejb.getId();
someOtherField = ejb.getSomeOtherField();
}
There are about 10 fields or so. I did double check and realize that one
of
them is a field on a relationship, which may be the source of the problem.
You are doing 10 invocations through the ejb layers. The code will be
way more efficient if you put the value object creation code inside the
entity bean. For example
public abstract class MyEntityBean extends EJBObject {
public MyValueObject getValueObject() {
MyValueObject valueObject = new MyValueObject();
valueObject.setName(getName());
valueObject.setId(getId());
valueObject.setSomeOtherField(getSomeOtherField());
}
}
The important difference is the loading of the value object gets all of
the data from the ejb using calls inside of the bean instance and
specifically the calls don't travel over a Remote or Local interface.
This means there is no code interpositioned.
-dain
---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
This transmission contains information solely for intended recipient and may
be privileged, confidential and/or otherwise protect from disclosure. If
you are not the intended recipient, please contact the sender and delete all
copies of this transmission. This message and/or the materials contained
herein are not an offer to sell, or a solicitation of an offer to buy, any
securities or other instruments. The information has been obtained or
derived from sources believed by us to be reliable, but we do not represent
that it is accurate or complete. Any opinions or estimates contained in
this information constitute our judgment as of this date and are subject to
change without notice. Any information you share with us will be used in
the operation of our business, and we do not request and do not want any
material, nonpublic information. Absent an express prior written agreement,
we are not agreeing to treat any information confidentially and will use any
and all information and reserve the right to publish or disclose any
information you share with us.
---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Luttrell, Peter wrote: It is faster. I tried it in response to danch's message early in the thread. Thus I have the same question (which no one commented on): Time ~1200ms is a lot better then the original 2200, but can this still be acceptable for reading ~10 fields from 750ejbs that are 100% cached? Here is the email in this thread reporting the results: I think you will get the same answer, run a profiler and find out what is taking the 1200 ms. It should be obvious. If you can't fix whatever is taking all the time, come back and complain about x being really slow. My guess is the data isn't cached and it is taking 1199 ms to get it from the database and 1 ms to build the value object. -dain --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Have been having similar issues, and my 'psuedo-hack' tests show similar results to Georg, so thank you Georg for pointing out that the database lookups are not the problem, but the object conversion piece. I don't wish to sell other products, but for a reference, has anyone seen a difference if they switch to another CMP Persistance engine such as Gemstone? I tried their eval on Jboss3.0.3, but I couldn't get it to work in my environment. Would be nice to know as a reference if solving the entity-bean performance is clearly tied to CMP/Persistance, and also have available proven workarounds for people that have short timelines (yeah, I'm one of the many :-P). Please do not debate about commercial versus open-source methodology, just looking for solution to immediate business problems and methods to identify areas of improvements :-). Oh, and LIMIT/OFFSET's would be awesome!!! -D --__--__-- Message: 1 Date: Wed, 30 Oct 2002 14:14:06 -0600 From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Reply-To: [EMAIL PROTECTED] Georg Schmid wrote: It seems that my (and, at least to some degree, Peter's) specific problem is misunderstood. Sorry, that happens all the time on the lists In my case: the problem is NOT getting the data from the database fast (the finders execute fast enough). I think Jboss does not have a problem there, but that's my guess, as I do not have personal experience with other app servers. The performance is lost, when I try to convert the a collection of local entity bean references into a collection of value objects. None of the previous posts (except Peter's) touches upon this subject. I want to understand and, if possible, solve this 'value object conversion speed' problem: snip/ The for-loop should be able to convert 1000 local entity bean references per second or better for simple entity beans. Can you send me this code so I can test with a profiler? I want to know where all the time is spend. What version of JBoss are you using? I am not interested in any CMP vs non-CMP debate. TSS may be a better place for this. Agreed. It would be convenient, if the size of the result sets, that can be handled using CMP, coincides with the number of rows you should/could reasonably display in a dialog or page in your (web-based) GUI. This would remove the need to switch to raw JDBC, when doing the CMP equivalent of plain vanilla (for instance) select * from BeanTable where lastUpdate = '10/20/2002' queries. That's all I hope for. You lost me. JBoss 4.0 will have support the LIMIT someNumber OFFSET someNumber syntax. Is that what you are talking about. I would like to be able to support Date literals, but I don't want to get too far in front of the spec. Does anyone know where I can find the ANSI SQL spec on date literals? (I'm not interested in how Oracle does this... I want to know the standard). CMP will keep getting more powerful over time. Using it is 'Making the trend work for you'. Yep... keep the suggestions coming, and we can make this the best persistence engine period. -dain --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Darren Hartford wrote: Have been having similar issues, and my 'psuedo-hack' tests show similar results to Georg, so thank you Georg for pointing out that the database lookups are not the problem, but the object conversion piece. I don't wish to sell other products, but for a reference, has anyone seen a difference if they switch to another CMP Persistance engine such as Gemstone? I tried their eval on Jboss3.0.3, but I couldn't get it to work in my environment. Would be nice to know as a reference if solving I don't mind you selling Gemstone as they are a JBoss partner. Gemstone should be significantly faster then almost any persistence code as it is using a fast persistent object cache under the covers so there is no object conversion. Also relationship navigation is super fast because they have live references in cache and I need to do a db call. the entity-bean performance is clearly tied to CMP/Persistance, and also have available proven workarounds for people that have short timelines (yeah, I'm one of the many :-P). Please do not debate about commercial versus open-source methodology, just looking for solution to immediate business problems and methods to identify areas of improvements :-). I plan on running Gerog's test soon as there is really no reason for the code to be any slower, but I am working on a new prefetch cache that can merge at the end of a tx. Oh, and LIMIT/OFFSET's would be awesome!!! Agreed. -dain --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
Hello, Yes, in 4.0 there will be an abstraction layer between the cmp view of the world and the physical storage. This means that it will be possible to map several cmp beans in different applications to the same store. The real trick is keeping the caches in sync and this is where the new invalidation code comes into play. Another change is will be the Keeping cache in-synch for different CMP based on the same data is already possible with some semantic (there is no shared locking, etc.), you just need to set a tag in jboss.xml and gives to all related CMP the same cache-name. Cheers, Sacha --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
It seems that my (and, at least to some degree, Peter's) specific
problem is misunderstood.
In my case: the problem is NOT getting the data from the database fast
(the finders execute fast enough).
I think Jboss does not have a problem there, but that's my guess, as I
do not have personal experience
with other app servers.
The performance is lost, when I try to convert the a collection of local
entity bean references
into a collection of value objects. None of the previous posts (except
Peter's) touches upon this subject.
I want to understand and, if possible, solve this 'value object
conversion speed' problem:
Collection localBeanRefs = localHome.findBySomeCriterion(...); --
This is not the problem (good job, Dain) !!
Collection valueObjects = new ArrayList();
// The following for-loop is way too slow.
for (Iterator beanIter = localBeanRefs; beanIter.hasNext();) {
LocalBean localBean = (LocalBean)beanIter.next();
ValueObject valueObject = ValueObjectFactory.createValueObject(); //
Same as new ValueObjectImpl();
valueObjects.add( localBean.buildValueObject( valueObject ) ); //
does: valueObject.setAttr1( getAttr1() ); ...
}
The same using JDBC:
ResultSet rows = myJDBCWrapper.executeQuery( query, dataSource ); --
Needs same amount of time as finder above.
Collection valueObjects = new ArrayList();
// This is at least 3 times faster than the for-loop above.
while (rows.next()) {
ValueObject valueObject = ValueObjectFactory.createValueObject();
valueObject.buildFromRow( rows ); // valueObject.setAttr1(
rows.getString(...) ); etc.
valueObjects.add( valueObject );
}
The for-loop should be able to convert 1000 local entity bean references
per second or better for simple entity beans.
I am not interested in any CMP vs non-CMP debate. TSS may be a better
place for this.
It would be convenient, if the size of the result sets, that can be
handled using CMP, coincides with the number of rows
you should/could reasonably display in a dialog or page in your
(web-based) GUI. This would remove the need to switch
to raw JDBC, when doing the CMP equivalent of plain vanilla (for
instance) select * from BeanTable where lastUpdate = '10/20/2002'
queries. That's all I hope for.
CMP will keep getting more powerful over time. Using it is 'Making the
trend work for you'.
Regards
Georg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Dain
Sundstrom
Sent: Wednesday, October 30, 2002 01:07
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help
Emerson Cargnin - SICREDI Serviços wrote:
Dain Sundstrom wrote:
Emerson,
I disagree with you classification that cmp is not usable. There are
many people that find the performance completely with in their
expectations. It is only when you have a high expectation and a very
complex schema that you have problems.
what I really mean was that cmp would be alot more usable : )
by the way, we are in in a doubt about a point of architecture : as i
discussed before somew time ago, in a very big system (like the
financial one i'm on) there is the need to separate the modules of it,
like one for accounting, other for savings, etc. And each one would
need to talk with a couple of others. The problem : to separate and
allowing those to be separate deployable, you would have to get rid of
cmr's and make the modules talk with each other through session
facades. In this case even with cmr read-ahead would do nothing to
avoid the n*cmr needed to access each entity. And worse, how could I
manage the constraints between 2 related (and module separated)
entities? one would need to consult the dependent module (via session
facade) to see if it could be deleted...
I don't know what going be the solution, throwing entities away, or
making up a monolitic system using cmr.
any suggestions?
Yes, in 4.0 there will be an abstraction layer between the cmp view of
the world and the physical storage. This means that it will be possible
to map several cmp beans in different applications to the same store.
The real trick is keeping the caches in sync and this is where the new
invalidation code comes into play. Another change is will be the
introduction of a domain concept above applications. Applications in
the same domain will be able to share a common store manager. These big
architectural changes are designed to make this type of application
possible. (Note: all of these, except the invalidation code, are still
in the concept stage of development)
-dain
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf ___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
Georg - one thing that may help here is to create a LocalBean object outside of the
loop and then set it each time in the loop as follows:-
// The following for-loop is way too slow.
LocalBean localBean = null;
for (Iterator beanIter = localBeanRefs; beanIter.hasNext();) {
localBean = (LocalBean)beanIter.next();
ValueObject valueObject = ValueObjectFactory.createValueObject(); //
...
This should reduce the overhead required in creating a localbean object each time. In
fact you may be able to do the same with ValueObject too.
hth
Alan.
-Original Message-
From: Georg Schmid [mailto:georg-schmid;ti.com]
Sent: Wednesday, 30 October 2002 4:34 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help
It seems that my (and, at least to some degree, Peter's) specific
problem is misunderstood.
In my case: the problem is NOT getting the data from the database fast
(the finders execute fast enough).
I think Jboss does not have a problem there, but that's my guess, as I
do not have personal experience
with other app servers.
The performance is lost, when I try to convert the a collection of local
entity bean references
into a collection of value objects. None of the previous posts (except
Peter's) touches upon this subject.
I want to understand and, if possible, solve this 'value object
conversion speed' problem:
Collection localBeanRefs = localHome.findBySomeCriterion(...); --
This is not the problem (good job, Dain) !!
Collection valueObjects = new ArrayList();
// The following for-loop is way too slow.
for (Iterator beanIter = localBeanRefs; beanIter.hasNext();) {
LocalBean localBean = (LocalBean)beanIter.next();
ValueObject valueObject = ValueObjectFactory.createValueObject(); //
Same as new ValueObjectImpl();
valueObjects.add( localBean.buildValueObject( valueObject ) ); //
does: valueObject.setAttr1( getAttr1() ); ...
}
The same using JDBC:
ResultSet rows = myJDBCWrapper.executeQuery( query, dataSource ); --
Needs same amount of time as finder above.
Collection valueObjects = new ArrayList();
// This is at least 3 times faster than the for-loop above.
while (rows.next()) {
ValueObject valueObject = ValueObjectFactory.createValueObject();
valueObject.buildFromRow( rows ); // valueObject.setAttr1(
rows.getString(...) ); etc.
valueObjects.add( valueObject );
}
The for-loop should be able to convert 1000 local entity bean references
per second or better for simple entity beans.
I am not interested in any CMP vs non-CMP debate. TSS may be a better
place for this.
It would be convenient, if the size of the result sets, that can be
handled using CMP, coincides with the number of rows
you should/could reasonably display in a dialog or page in your
(web-based) GUI. This would remove the need to switch
to raw JDBC, when doing the CMP equivalent of plain vanilla (for
instance) select * from BeanTable where lastUpdate = '10/20/2002'
queries. That's all I hope for.
CMP will keep getting more powerful over time. Using it is 'Making the
trend work for you'.
Regards
Georg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Dain
Sundstrom
Sent: Wednesday, October 30, 2002 01:07
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help
Emerson Cargnin - SICREDI Serviços wrote:
Dain Sundstrom wrote:
Emerson,
I disagree with you classification that cmp is not usable. There are
many people that find the performance completely with in their
expectations. It is only when you have a high expectation and a very
complex schema that you have problems.
what I really mean was that cmp would be alot more usable : )
by the way, we are in in a doubt about a point of architecture : as i
discussed before somew time ago, in a very big system (like the
financial one i'm on) there is the need to separate the modules of it,
like one for accounting, other for savings, etc. And each one would
need to talk with a couple of others. The problem : to separate and
allowing those to be separate deployable, you would have to get rid of
cmr's and make the modules talk with each other through session
facades. In this case even with cmr read-ahead would do nothing to
avoid the n*cmr needed to access each entity. And worse, how could I
manage the constraints between 2 related (and module separated)
entities? one would need to consult the dependent module (via session
facade) to see if it could be deleted...
I don't know what going be the solution, throwing entities away, or
making up a monolitic system using cmr.
any suggestions?
Yes, in 4.0 there will be an abstraction layer between the cmp view of
the world and the physical storage. This means that it will be possible
to map several cmp beans in different applications to the same store.
The real trick is keeping the caches in sync
RE: [JBoss-user] Entity Bean Performance Tuning Help
Georg, It seems that my (and, at least to some degree, Peter's) specific problem is misunderstood. ... into a collection of value objects. None of the previous posts (except Peter's) touches upon this subject. That's wrong: Bill suggested something wrt to your value object and I suggested that you provide a small test case on which we could work. cheers, Sacha P.S.: BTW, is your for loop running in a single transaction? What is the transaction attribute of the code running in the for loop? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Georg Schmid wrote: It seems that my (and, at least to some degree, Peter's) specific problem is misunderstood. Sorry, that happens all the time on the lists In my case: the problem is NOT getting the data from the database fast (the finders execute fast enough). I think Jboss does not have a problem there, but that's my guess, as I do not have personal experience with other app servers. The performance is lost, when I try to convert the a collection of local entity bean references into a collection of value objects. None of the previous posts (except Peter's) touches upon this subject. I want to understand and, if possible, solve this 'value object conversion speed' problem: snip/ The for-loop should be able to convert 1000 local entity bean references per second or better for simple entity beans. Can you send me this code so I can test with a profiler? I want to know where all the time is spend. What version of JBoss are you using? I am not interested in any CMP vs non-CMP debate. TSS may be a better place for this. Agreed. It would be convenient, if the size of the result sets, that can be handled using CMP, coincides with the number of rows you should/could reasonably display in a dialog or page in your (web-based) GUI. This would remove the need to switch to raw JDBC, when doing the CMP equivalent of plain vanilla (for instance) select * from BeanTable where lastUpdate = '10/20/2002' queries. That's all I hope for. You lost me. JBoss 4.0 will have support the LIMIT someNumber OFFSET someNumber syntax. Is that what you are talking about. I would like to be able to support Date literals, but I don't want to get too far in front of the spec. Does anyone know where I can find the ANSI SQL spec on date literals? (I'm not interested in how Oracle does this... I want to know the standard). CMP will keep getting more powerful over time. Using it is 'Making the trend work for you'. Yep... keep the suggestions coming, and we can make this the best persistence engine period. -dain --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a select * from BeanTable. For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over. I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in jboss-service.xml to uncomment it. Gives you # contentions in table with bean beans. Also gives averages and other stats. I'll be adding this to docs eventually. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net]On Behalf Of Georg Schmid Sent: Monday, October 21, 2002 4:32 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Peter, I have a similar problem and tried to dig into it. You may have a look at the thread http://www.jboss.org/forums/thread.jsp?forum=46thread=20827 in the forums. To summarize: the EB caching works perfectly (I guess it is as fast as you can get with JDBC), but getting the rows in memory into a data or value object is slow. Creating n value objects for n EB instances involves going through the interceptor stack n times, and this is, where the time is lost. I incrementally stripped down the interceptor stack using a custom configuration in my jboss.xml, but without much success. The only way to really speed up things that I found was removing the synchronization interceptor, which improves performance by a factor of 2, if no or only one attribute is read, but makes it worse, if many attributes have to be read. BTW: I used commit option B, read-ahead on-load, and the Instance Per Transaction setup in my experiments. The pattern you found is interesting. Because there are so many things impacting the performance, it is hard to tell, whom to ask (Dain, Bill, David,...). Bill Burke did some performance tests using ECPerf. Maybe he can report a bit on the results. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Luttrell, Peter Sent: Saturday, October 19, 2002 02:17 To: '[EMAIL PROTECTED]' Subject: [JBoss-user] Entity Bean Performance Tuning Help I have something that is taking longer then I would like and am trying to tune jboss to reduce the time it takes. My test scenario is as such: JBoss3.0.3 on jdk1.4.1_01 1
RE: [JBoss-user] Entity Bean Performance Tuning Help
Hello Georg, Do you mean that your slowness problem occurs when accessing the collection *even* in mono-threaded behaviour? If I understand your scenario, you have something like this: - a web page that display the content of 4000 entity beans (either directly or using a SLSB) - the entity beans are loaded at once (no N+1 issue wrt data loading) - everything occurs in a single transaction - you hit the refresh page of your browser (i.e. only 1 access on the whole system) - you get really bad data at the synchronisation level. Right? As what you describes seems to be an experiment, do you have a very small example (EAR) that contains: - the CMP that you use - a servlet/JSP that uses direct JDBC call to retrieve this data (with a time counter) - a servlet/JSP that uses the CMP to retrieve the data (with a time counter) - this would be using the embedded HSQL DB - a servlet/JSP that can be used to populate the DB with dummy values Maybe, if we are lucky, you already have this small setup ready: would you agree to send it? cheers, Sacha My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a select * from BeanTable. For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
JBoss is losing credibility in our firm due to this performance problem as well as the issues i've noted about JMS performance. If anyone cares whether JBoss is actually used in the production environment, the team might consider investing time in making it perform well. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid;ti.com] Sent: Tuesday, October 29, 2002 2:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a select * from BeanTable. For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over. I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in jboss-service.xml to uncomment it. Gives you # contentions in table with bean beans. Also gives averages and other stats. I'll be adding this to docs eventually. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net]On Behalf Of Georg Schmid Sent: Monday, October 21, 2002 4:32 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Peter, I have a similar problem and tried to dig into it. You may have a look at the thread http://www.jboss.org/forums/thread.jsp?forum=46thread=20827 in the forums. To summarize: the EB caching works perfectly (I guess it is as fast as you can get with JDBC), but getting the rows in memory into a data or value object is slow. Creating n value objects for n EB instances involves going through the interceptor stack n times, and this is, where the time is lost. I incrementally stripped down the interceptor stack using a custom configuration in my jboss.xml, but without much success. The only way to really speed up things that I found was removing the synchronization interceptor, which improves performance by a factor of 2, if no or only one attribute is read, but makes it worse, if many attributes have to be read. BTW: I used commit option B, read-ahead on-load, and the Instance Per Transaction setup in my experiments. The pattern you found is interesting. Because there are so many things impacting the performance, it is hard to tell, whom to ask (Dain, Bill, David,...). Bill Burke did some performance tests using ECPerf. Maybe he can
RE: [JBoss-user] Entity Bean Performance Tuning Help
Georg, I used 2 other non-ejb solutions to get what I needed done. Cache the dataobjects in the webtier. It will only work in certain cases, 2/3 in my case. I know it's duplicating work that the ejb container should do, but if there is noting that can be done to JBoss to get performance acceptable then... Paginate the results. Checkout this taglib, it does it all for you automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it better because IE can render the pages very fast, compared to the super long time it takes with large tables. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid;ti.com] Sent: Tuesday, October 29, 2002 2:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a select * from BeanTable. For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over. I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in jboss-service.xml to uncomment it. Gives you # contentions in table with bean beans. Also gives averages and other stats. I'll be adding this to docs eventually. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net]On Behalf Of Georg Schmid Sent: Monday, October 21, 2002 4:32 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Peter, I have a similar problem and tried to dig into it. You may have a look at the thread http://www.jboss.org/forums/thread.jsp?forum=46thread=20827 in the forums. To summarize: the EB caching works perfectly (I guess it is as fast as you can get with JDBC), but getting the rows in memory into a data or value object is slow. Creating n value objects for n EB instances involves going through the interceptor stack n times, and this is, where the time is lost. I incrementally stripped down the interceptor stack using a custom configuration in my jboss.xml, but without much success. The only way to really speed up things that I found was removing the synchronization interceptor, which improves performance by a factor of 2, if no or only one attribute is read, but makes it worse, if many attributes have to be read. BTW: I used commit option B, read-ahead on-load
RE: [JBoss-user] Entity Bean Performance Tuning Help
Peter, it's a great relief to see, that I am not the only one... I have not given up hope yet, but I cannot crank out enough hours to get to the core of the problem. In the app I did before the current one, I used the paging and web layer caching approach you suggest, albeit on a small scale. Then I embraced EJB and CMP2.0. Despite my current problems I am still convinced that it was the right decision. I find it more convenient to put my tables inside a div using the overflow:auto css style, so I can simply scroll down the complete list without paging. I am using the JSTL to do the presentation layer. Actually I had JBoss running under OptimizeIt two weeks ago, but then I was distracted and now my evaluation license expired. May be you try to use SwiftMQ (they used to have docs on how to integrate with Jboss on their website). My company did a performance comparison against IBM MQ Series, and SwiftMQ was significantly faster (lean and mean, so to say, but no work flow component etc.). Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Luttrell, Peter Sent: Tuesday, October 29, 2002 17:39 To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg, I used 2 other non-ejb solutions to get what I needed done. Cache the dataobjects in the webtier. It will only work in certain cases, 2/3 in my case. I know it's duplicating work that the ejb container should do, but if there is noting that can be done to JBoss to get performance acceptable then... Paginate the results. Checkout this taglib, it does it all for you automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it better because IE can render the pages very fast, compared to the super long time it takes with large tables. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid;ti.com] Sent: Tuesday, October 29, 2002 2:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a select * from BeanTable. For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over. I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in jboss-service.xml to uncomment it. Gives you # contentions
Re: [JBoss-user] Entity Bean Performance Tuning Help
Peter, I honestly wish you the best of luck with your project. There are some application that need performance beyond what CMP can offer. Usually people come to this conclusion way to early, but I bet you spent a long time looking at you specific problem. It really comes down to a trace off, highly skilled programmer time to implement a custom JDBC and caching layer vs. more hardware. In most cases the hardware is cheap but there are cases where programmer is cheaper. If you think this is a JBoss specific performance problem, please post a bug report and I'll try to fix it. -dain Luttrell, Peter wrote: Georg, I used 2 other non-ejb solutions to get what I needed done. Cache the dataobjects in the webtier. It will only work in certain cases, 2/3 in my case. I know it's duplicating work that the ejb container should do, but if there is noting that can be done to JBoss to get performance acceptable then... Paginate the results. Checkout this taglib, it does it all for you automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it better because IE can render the pages very fast, compared to the super long time it takes with large tables. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid;ti.com] Sent: Tuesday, October 29, 2002 2:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a select * from BeanTable. For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over. I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in jboss-service.xml to uncomment it. Gives you # contentions in table with bean beans. Also gives averages and other stats. I'll be adding this to docs eventually. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net]On Behalf Of Georg Schmid Sent: Monday, October 21, 2002 4:32 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Peter, I have a similar problem and tried to dig into it. You may have a look at the thread http://www.jboss.org/forums/thread.jsp?forum=46thread=20827 in the forums. To summarize: the EB caching works perfectly (I guess it is as fast as you can get with JDBC), but getting the rows
RE: [JBoss-user] Entity Bean Performance Tuning Help
JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. My bet is that it is a problem with your code More comments inlined. I have a method, which does this: 1) begin manual transaction with jta 2) calls findBySomeCriteria() which returns some 750 ejbs -takes 200-300ms (good) Entities not loaded yet... 3) then iterate through each, calling one of the methods i do this to fill the readahead cache for all the beans in an attempt to isolate the performance problem -takes 80-100ms (good) Entites are loaded by this time. This leads me to believe it is your DataObject creation that is slow. More comments follow... 4) then iterate through each, and constructing a dataobject that I use for display purposes -takes 2000-2500ms (this seams way too long) 5) commit the transaction, blablabla.. I used 2 other non-ejb solutions to get what I needed done. Cache the dataobjects in the webtier. It will only work in certain cases, 2/3 in my case. I know it's duplicating work that the ejb container should do, Why should the EJB tier be responsible for caching your DataObjects? Unless you explicitly code this in ejbLoad, only persistent fields are stored. but if there is noting that can be done to JBoss to get performance acceptable then... Try another app server then. I'd be curious to see if it is much faster. Bill Paginate the results. Checkout this taglib, it does it all for you automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it better because IE can render the pages very fast, compared to the super long time it takes with large tables. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid;ti.com] Sent: Tuesday, October 29, 2002 2:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a select * from BeanTable. For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over
RE: [JBoss-user] Entity Bean Performance Tuning Help
Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them. I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss fixed. Until then, I'd recommend a different approach than CMP. Jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 10:28 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. My bet is that it is a problem with your code More comments inlined. I have a method, which does this: 1) begin manual transaction with jta 2) calls findBySomeCriteria() which returns some 750 ejbs -takes 200-300ms (good) Entities not loaded yet... 3) then iterate through each, calling one of the methods i do this to fill the readahead cache for all the beans in an attempt to isolate the performance problem -takes 80-100ms (good) Entites are loaded by this time. This leads me to believe it is your DataObject creation that is slow. More comments follow... 4) then iterate through each, and constructing a dataobject that I use for display purposes -takes 2000-2500ms (this seams way too long) 5) commit the transaction, blablabla.. I used 2 other non-ejb solutions to get what I needed done. Cache the dataobjects in the webtier. It will only work in certain cases, 2/3 in my case. I know it's duplicating work that the ejb container should do, Why should the EJB tier be responsible for caching your DataObjects? Unless you explicitly code this in ejbLoad, only persistent fields are stored. but if there is noting that can be done to JBoss to get performance acceptable then... Try another app server then. I'd be curious to see if it is much faster. Bill Paginate the results. Checkout this taglib, it does it all for you automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it better because IE can render the pages very fast, compared to the super long time it takes with large tables. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid;ti.com] Sent: Tuesday, October 29, 2002 2:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a select * from BeanTable. For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display
Re: [JBoss-user] Entity Bean Performance Tuning Help
Jason Westra wrote: Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them. I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. The JBoss 4.0 design will be able to benefit from hand tuned queries. I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss fixed. Until then, I'd recommend a different approach than CMP. My goal for the 4.0 architecture is to enable the easy use of a hybrid approach to CMP. In this design you can use CMP for the 98% of you app that performs well under the current code and for the 2% that needs hand code you can plug in a custom interceptor to tune queries. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
Dain wrote: I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. This was my point. Sounds like you agree. :) The current CMP design has problems with large, complex reads. You can't effectivly use CMP for everything, nor was the EJB spec's CMP section able solve ALL data query problems. J -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 29, 2002 11:43 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Jason Westra wrote: Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them. I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. The JBoss 4.0 design will be able to benefit from hand tuned queries. I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss fixed. Until then, I'd recommend a different approach than CMP. My goal for the 4.0 architecture is to enable the easy use of a hybrid approach to CMP. In this design you can use CMP for the 98% of you app that performs well under the current code and for the 2% that needs hand code you can plug in a custom interceptor to tune queries. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
i think that maybe using a read-ahead configuration for cmr could turn CMP usable, hence the cause of the slowness (IMHO) is the great number of selects as you navigate through each BEAN. Jason Westra wrote: Dain wrote: I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. This was my point. Sounds like you agree. :) The current CMP design has problems with large, complex reads. You can't effectivly use CMP for everything, nor was the EJB spec's CMP section able solve ALL data query problems. J -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 29, 2002 11:43 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Jason Westra wrote: Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them. I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. The JBoss 4.0 design will be able to benefit from hand tuned queries. I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss fixed. Until then, I'd recommend a different approach than CMP. My goal for the 4.0 architecture is to enable the easy use of a hybrid approach to CMP. In this design you can use CMP for the 98% of you app that performs well under the current code and for the 2% that needs hand code you can plug in a custom interceptor to tune queries. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Emerson, I disagree with you classification that cmp is not usable. There are many people that find the performance completely with in their expectations. It is only when you have a high expectation and a very complex schema that you have problems. May applications happily use CMP today, and these applications will benefit from the work that we put into the cmp engine on a daily basis. The applications that don't use CMP can only get benefits from what they can program by them selves. As I said it comes down to a trade off. Also, I truly believe that the Jboss persistence engine will be able to be on par with any custom code using a simple CMP 2 interface, because we will allow you to plug in your optimized code. The best of both worlds. -dain Emerson Cargnin - SICREDI Serviços wrote: i think that maybe using a read-ahead configuration for cmr could turn CMP usable, hence the cause of the slowness (IMHO) is the great number of selects as you navigate through each BEAN. Jason Westra wrote: Dain wrote: I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. This was my point. Sounds like you agree. :) The current CMP design has problems with large, complex reads. You can't effectivly use CMP for everything, nor was the EJB spec's CMP section able solve ALL data query problems. J -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 29, 2002 11:43 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Jason Westra wrote: Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them. I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. The JBoss 4.0 design will be able to benefit from hand tuned queries. I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss fixed. Until then, I'd recommend a different approach than CMP. My goal for the 4.0 architecture is to enable the easy use of a hybrid approach to CMP. In this design you can use CMP for the 98% of you app that performs well under the current code and for the 2% that needs hand code you can plug in a custom interceptor to tune queries. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
My life became _blissful_ about a month ago when I ditched entity beans and started using Hibernate for persistence. My data model objects are all pure java beans which I can 1) pass out of the EJB system and 2) cache anywhere I want, for however long I want, in a clustered environment. This seriously cut out 1/3 of my code. I will _never_ use entity beans again. And yes, I was using XDoclet and all the cool tools to make entity beans easier - the very fact that this technology requires so many tools to salve the pain is the surest sign that there is something horribly, horribly wrong... JBoss and Session beans are great - but after two years of working with entity beans on three different appservers, I have come to the conclusion that the problem domain for which they are appropriate is very narrow, if it exists at all. There are a lot of other O/R persistence mechanisms available, and they're almost all much easier to learn and use. Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Luttrell, Peter [mailto:PLuttrell;starkinvestments.com] Sent: Tuesday, October 29, 2002 8:39 AM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg, I used 2 other non-ejb solutions to get what I needed done. Cache the dataobjects in the webtier. It will only work in certain cases, 2/3 in my case. I know it's duplicating work that the ejb container should do, but if there is noting that can be done to JBoss to get performance acceptable then... Paginate the results. Checkout this taglib, it does it all for you automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it better because IE can render the pages very fast, compared to the super long time it takes with large tables. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid;ti.com] Sent: Tuesday, October 29, 2002 2:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a select * from BeanTable. For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over. I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in jboss-service.xml to uncomment
Re: [JBoss-user] Entity Bean Performance Tuning Help
Dain Sundstrom wrote: Emerson, I disagree with you classification that cmp is not usable. There are many people that find the performance completely with in their expectations. It is only when you have a high expectation and a very complex schema that you have problems. what I really mean was that cmp would be alot more usable : ) by the way, we are in in a doubt about a point of architecture : as i discussed before somew time ago, in a very big system (like the financial one i'm on) there is the need to separate the modules of it, like one for accounting, other for savings, etc. And each one would need to talk with a couple of others. The problem : to separate and allowing those to be separate deployable, you would have to get rid of cmr's and make the modules talk with each other through session facades. In this case even with cmr read-ahead would do nothing to avoid the n*cmr needed to access each entity. And worse, how could I manage the constraints between 2 related (and module separated) entities? one would need to consult the dependent module (via session facade) to see if it could be deleted... I don't know what going be the solution, throwing entities away, or making up a monolitic system using cmr. any suggestions? is there anyone that modeled a very big system using CMP/CMR?? how to isolate and decouple the sub-systems, isn't it what we've learned from Software Engineering classes? and and we are at a point in the construction and having a defined arquitecture that is almost impossible go back (or at least it would be a lot of waste of time). May applications happily use CMP today, and these applications will benefit from the work that we put into the cmp engine on a daily basis. The applications that don't use CMP can only get benefits from what they can program by them selves. As I said it comes down to a trade off. Also, I truly believe that the Jboss persistence engine will be able to be on par with any custom code using a simple CMP 2 interface, because we will allow you to plug in your optimized code. The best of both worlds. -dain Emerson Cargnin - SICREDI Serviços wrote: i think that maybe using a read-ahead configuration for cmr could turn CMP usable, hence the cause of the slowness (IMHO) is the great number of selects as you navigate through each BEAN. Jason Westra wrote: Dain wrote: I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. This was my point. Sounds like you agree. :) The current CMP design has problems with large, complex reads. You can't effectivly use CMP for everything, nor was the EJB spec's CMP section able solve ALL data query problems. J -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 29, 2002 11:43 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Jason Westra wrote: Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them. I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. The JBoss 4.0 design will be able to benefit from hand tuned queries. I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss fixed. Until then, I'd recommend a different approach than CMP. My goal for the 4.0 architecture is to enable the easy use of a hybrid approach to CMP. In this design you can use CMP for the 98% of you app that performs well under the current code and for the 2% that needs hand code you can plug in a custom interceptor to tune queries. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- | Emerson Cargnin
Re: [JBoss-user] Entity Bean Performance Tuning Help
Emerson Cargnin - SICREDI Serviços wrote: Dain Sundstrom wrote: Emerson, I disagree with you classification that cmp is not usable. There are many people that find the performance completely with in their expectations. It is only when you have a high expectation and a very complex schema that you have problems. what I really mean was that cmp would be alot more usable : ) by the way, we are in in a doubt about a point of architecture : as i discussed before somew time ago, in a very big system (like the financial one i'm on) there is the need to separate the modules of it, like one for accounting, other for savings, etc. And each one would need to talk with a couple of others. The problem : to separate and allowing those to be separate deployable, you would have to get rid of cmr's and make the modules talk with each other through session facades. In this case even with cmr read-ahead would do nothing to avoid the n*cmr needed to access each entity. And worse, how could I manage the constraints between 2 related (and module separated) entities? one would need to consult the dependent module (via session facade) to see if it could be deleted... I don't know what going be the solution, throwing entities away, or making up a monolitic system using cmr. any suggestions? Yes, in 4.0 there will be an abstraction layer between the cmp view of the world and the physical storage. This means that it will be possible to map several cmp beans in different applications to the same store. The real trick is keeping the caches in sync and this is where the new invalidation code comes into play. Another change is will be the introduction of a domain concept above applications. Applications in the same domain will be able to share a common store manager. These big architectural changes are designed to make this type of application possible. (Note: all of these, except the invalidation code, are still in the concept stage of development) -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
That makes sense for the weird timing observations. I tried the value object pattern with a local ejbHome method. Utilizing a finder this reduced my time from ~2200ms to ~1600, then i tried an ejbSelect which took it down to ~1400ms. Then i tried your suggestion (bulk getter) and was able to get the time to about ~1200ms. A lot better then the original 2200, but can this still be acceptable for reading ~10 fields from 750ejbs that are 100% cached? Also, the first time though (uncached), is still very long 11,000 ms for the exact same code and data...course a bit of this is creating db pool connections. .peter -Original Message- From: Dan Christopherson [mailto:danch;nvisia.com] Sent: Monday, October 21, 2002 12:45 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Luttrell, Peter wrote: basically pass in a reference to the ejb and call most of the methods on it. The trace dumps out the total time the constructor took. I noticed a weird pattern. Most of the constructions took 0ms, but every 5th or so it took 15-16ms, which is where all of my time is going. Note that it is not exactly 18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,855 INFO [STDOUT] displayBean construction took 15 ms 18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms Assuming you're using System.currentTimeMillis(), this might just be the granularity that this method uses: in the past, I've noticed it returning only multiples of 10 under windows. One thing that this method is doing is it's calling through the entire container stack for each attribute that needs to be copied to the data object. Can you instead give the entity a factory method (bulk getter)? That might help by reducing overhead. -danch --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576298;k? http://www.sun.com/javavote ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and will use any and all information and reserve the right to publish or disclose any information you share with us. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over. I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in jboss-service.xml to uncomment it. Gives you # contentions in table with bean beans. Also gives averages and other stats. I'll be adding this to docs eventually. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net]On Behalf Of Georg Schmid Sent: Monday, October 21, 2002 4:32 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Peter, I have a similar problem and tried to dig into it. You may have a look at the thread http://www.jboss.org/forums/thread.jsp?forum=46thread=20827 in the forums. To summarize: the EB caching works perfectly (I guess it is as fast as you can get with JDBC), but getting the rows in memory into a data or value object is slow. Creating n value objects for n EB instances involves going through the interceptor stack n times, and this is, where the time is lost. I incrementally stripped down the interceptor stack using a custom configuration in my jboss.xml, but without much success. The only way to really speed up things that I found was removing the synchronization interceptor, which improves performance by a factor of 2, if no or only one attribute is read, but makes it worse, if many attributes have to be read. BTW: I used commit option B, read-ahead on-load, and the Instance Per Transaction setup in my experiments. The pattern you found is interesting. Because there are so many things impacting the performance, it is hard to tell, whom to ask (Dain, Bill, David,...). Bill Burke did some performance tests using ECPerf. Maybe he can report a bit on the results. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin;lists.sourceforge.net] On Behalf Of Luttrell, Peter Sent: Saturday, October 19, 2002 02:17 To: '[EMAIL PROTECTED]' Subject: [JBoss-user] Entity Bean Performance Tuning Help I have something that is taking longer then I would like and am trying to tune jboss to reduce the time it takes. My test scenario is as such: JBoss3.0.3 on jdk1.4.1_01 1 2.0 CMP Enity bean with about 10 fields and 3 relationships. I'm using commit-option A so all beans should be cached (see cache policy below) once loaded. The first time that I run this it obviously takes longer (filling the cache), however subsequent times aren't as fast as i would like; see below: I have a method, which does this: 1) begin manual transaction with jta 2) calls findBySomeCriteria() which returns some 750 ejbs -takes 200-300ms (good) 3) then iterate through each, calling one of the methods i do this to fill the readahead cache for all the beans in an attempt to isolate the performance problem -takes 80-100ms (good) 4) then iterate through each, and constructing a dataobject that I use for display purposes -takes 2000-2500ms (this seams way too long) 5) commit the transaction, blablabla.. The problem is step 4 seams to be taking longer then it should. I then added some trace to the dataobject constructor method, where I basically pass in a reference to the ejb and call most of the methods on it. The trace dumps out the total time the constructor took. I noticed a weird pattern. Most of the constructions took 0ms, but every 5th or so it took 15-16ms, which is where all of my time is going. Note that it is not exactly every 5th and tends to vary a bit. Here's a sample of the output: 18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,855 INFO [STDOUT] displayBean construction took 15 ms 18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,871 INFO [STDOUT] displayBean construction took 16 ms 18:46:06,871 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,871 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,871 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,871 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,886 INFO [STDOUT] displayBean construction took 15 ms 18:46:06,886 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,886 INFO [STDOUT] displayBean construction took 0 ms 18:46:06,886 INFO [STDOUT] displayBean construction took 0 ms 18:46
[JBoss-user] Entity Bean Performance Tuning Help
I have something that is taking longer then I would like and am trying to tune jboss to reduce the time it takes. My test scenario is as such: JBoss3.0.3 on jdk1.4.1_01 1 2.0 CMP Enity bean with about 10 fields and 3 relationships. I'm using commit-option A so all beans should be cached (see cache policy below) once loaded. The first time that I run thisit obviously takes longer (filling the cache), however subsequent times aren't as fast as i would like; see below: I have a method, which does this: 1) begin manual transaction with jta 2) calls findBySomeCriteria() which returns some 750 ejbs -takes 200-300ms (good) 3) then iterate through each, calling one of the methods i do this to fill the readahead cache for all the beans in an attempt to isolate the performance problem -takes 80-100ms (good) 4) then iterate through each, and constructing a dataobject that I use for display purposes -takes 2000-2500ms (this seams way too long) 5) commit the transaction, blablabla.. The problem is step 4 seams to be taking longer then it should. I then added some trace to the dataobject constructor method, where I basically pass in a reference to the ejb and call most of the methods on it. The trace dumps out the total time the constructor took. I noticed a weird pattern. Most of the constructions took 0ms, but every5th or soit took 15-16ms, which is where all of my time is going. Note that it is not exactly every 5th and tends to vary a bit. Here's a sample of the output: 18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms18:46:06,855 INFO [STDOUT] displayBean construction took 15 ms18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms18:46:06,871 INFO [STDOUT] displayBean construction took 16 ms18:46:06,871 INFO [STDOUT] displayBean construction took 0 ms18:46:06,871 INFO [STDOUT] displayBean construction took 0 ms18:46:06,871 INFO [STDOUT] displayBean construction took 0 ms18:46:06,871 INFO [STDOUT] displayBean construction took 0 ms18:46:06,886 INFO [STDOUT] displayBean construction took 15 ms18:46:06,886 INFO [STDOUT] displayBean construction took 0 ms18:46:06,886 INFO [STDOUT] displayBean construction took 0 ms18:46:06,886 INFO [STDOUT] displayBean construction took 0 ms18:46:06,886 INFO [STDOUT] displayBean construction took 0 ms18:46:06,902 INFO [STDOUT] displayBean construction took 16 ms18:46:06,902 INFO [STDOUT] displayBean construction took 0 ms18:46:06,902 INFO [STDOUT] displayBean construction took 0 ms18:46:06,902 INFO [STDOUT] displayBean construction took 0 ms18:46:06,902 INFO [STDOUT] displayBean construction took 0 ms18:46:06,918 INFO [STDOUT] displayBean construction took 16 ms18:46:06,918 INFO [STDOUT] displayBean construction took 0 ms18:46:06,918 INFO [STDOUT] displayBean construction took 0 ms18:46:06,918 INFO [STDOUT] displayBean construction took 0 ms18:46:06,918 INFO [STDOUT] displayBean construction took 0 ms18:46:06,933 INFO [STDOUT] displayBean construction took 15 ms18:46:06,933 INFO [STDOUT] displayBean construction took 0 ms18:46:06,933 INFO [STDOUT] displayBean construction took 0 ms18:46:06,933 INFO [STDOUT] displayBean construction took 0 ms18:46:06,949 INFO [STDOUT] displayBean construction took 0 ms18:46:06,949 INFO [STDOUT] displayBean construction took 0 ms18:46:06,965 INFO [STDOUT] displayBean construction took 0 ms18:46:06,965 INFO [STDOUT] displayBean construction took 0 ms18:46:06,965 INFO [STDOUT] displayBean construction took 0 ms18:46:06,965 INFO [STDOUT] displayBean construction took 0 ms18:46:06,965 INFO [STDOUT] displayBean construction took 0 ms18:46:06,980 INFO [STDOUT] displayBean construction took 0 ms18:46:06,980 INFO [STDOUT] displayBean construction took 0 ms18:46:06,980 INFO [STDOUT] displayBean construction took 0 ms18:46:06,980 INFO [STDOUT] displayBean construction took 0 ms18:46:06,996 INFO [STDOUT] displayBean construction took 16 ms my ejb-jar.xml file: I have not declared any security-constraints for the bean. I have tried it with transactions on and off (Required/Supports), which effected performance a little but did not correct the delays i'm seeing. my jboss.xml I have the bean tied to a custom container config. Here's the custom config, which i basically copied directly from the standardjboss.xml file. Note the changes to the cache capacity and age, etc. This is intended to keep the beans in the cache. container-configurations container-configurationcontainer-nameLongLasting Large CMP 2.x EntityBean
