I have recently created a report(html based) on this subject for my current
employer if you wish for a copy I can send it to you zipped up. It has not
been proof so aplogies for any inaccuracies. I have pasted into my email
editor so things might not be correctly layed out and tables and charts not
included. The result that comes out is that if your where to use cmp with
IAS you would only suffer 10% overhead. If you chose web logic you would
suffer a 1868% peformance overhead. IAS 4.0 is roughly 16 times faster than
WL ...that is if your where to not right any plumbing for them i..e
isModified. Also with isModified we have issues with clustering as stated
into the WL documentation.
enjoy,
Session Bean + SQL versus Session Bean + CMP Entity Bean
William Louth
21 February 2000
1. Introduction
The purpose of this document is to determine how best to solve a common
requirement of displaying a large (200+) collection domain objects and their
properties to a user with satisfactory performance. Currently the proposed
solution for such a requirement is to use a session bean accessing the
database directly through SQL. The reason for not using entity beans comes
down to the view felt that accessing the required display data through
entity beans would not achieve the performance criteria. The overhead
assumed is that of transaction management for this read only operation. One
of the problems with the session bean method is that lack of configurability
due to the embedding of database knowledge in the session bean. This along
with the fact that we are now accesing the database outside normal
transactions leads to inaccuracy in the data.
2. Tests
The following test where done using 2 application servers for the purpose of
ensuring that a method chosen is ideal across different EJB containers. The
2 application servers used are Inprise Application Server 4.0 and Web Logic
4.51.
Two types of methods where tested. The first involved a Java client calling
on a session bean to return a list of client objects (200+) based on a
specified country code. The session bean would inturn access the database
using a JDBC connections obtained from the containers connection pool to
create the object representtaion of the records. With the second method the
session bean obtained the objects using container managed persistent entity
beans. Each method was run 11 times continously.
2.1 Inprise Application Server 4.0 Test Results
Session Bean + SQL (ms)
.... some table.....
* The naming service was run out of process along with the ejb container.
** This figure includes the cost of creation of the initial database
connection which is incurred by Web Logic at server startup.
Session Bean + Container Managed Persistence Entity Bean (ms)
...........some table..........
* The naming service was run out of process along with the ejb container.
** This figure includes the cost of creation of the initial database
connection which is incurred by Web Logic at server startup.
>From the figures above we can see that with the entity bean method in a
single user enviroment we suffer a 10% peformance overhead. This seems quite
acceptable considering that we obtain database independence (i.e persistence
mapping) and a considerably reduction in code related to JDBC. Also with the
entity method we only have one code base for both read only and read write
access.
2.2 Web Logic 4.51 Test Results
Session Bean + SQL (ms)
....some table.....
>From the figures above we can see that with the entity bean method in a
single user enviroment we suffer a 1868% peformance overhead. This is quite
unacceptable. With these figures we see that the Inprise Application Server
4.0 is roughly 16 times faster than Web Logic 4.51.
The overhead can be attributed to the fact that at the end of the
transaction Web Logic will call ejbStore on all entity beans accessed. This
will result in n (size of collection) update sql calls to the database. The
Inprise EJB Container does perform the ejbStore after which its checks to
see has the state of the bean changed since the ejbLoad call. If nothing has
changed, which is the case, then no update sql calls will be made.
After further investigation a properitary solution was found to reduce this
overhead. This involved implementing an isModified method in the entity
bean. Web Logic can then use this to determine if a bean has changed. It is
the reponsibility of the bean developer to ensure that the value returned
from this function is correct. This means that code must be placed in each
set method for the bean and also in the standard ejb methods to set the flag
appropriately. There are many issues including vendor lock in of our beans,
production of more code and we know what that means the more chance of
errors creeping in.
Session Bean + Container Managed Persistence Entity Bean + isModified (ms)
.....some table....
>From the figures above we can see that with the entity bean method + the
isModified properitary extension in a single user enviroment we suffer a 50%
((1895-1278)/1278) peformance overhead in retrieving the list. This is more
acceptable. With these figures we see that the Inprise Application Server
4.0 is roughly 25% times faster than Web Logic 4.51.
The 25% is calculated on just the retrieving list results. The Inprise
Application server value of 1.434 secs excludes the initial connection cost
that web logic incurrs at startup and one large value that was caused by
myself (working on something). The weblogic value used was 1.895 secs. 25% =
(1.895 - 1.434) / 1.895
2.3 Vendor Independent Test Results (Bean Managed Persistence)
Session Bean + Bean Managed Persistence Entity Bean
..............some table.........
>From the figures above we can see that with the bean managed persistence
entity bean method in a single user enviroment we suffer a 3380%
((44482-1278)/1278) peformance overhead in retrieving the list. This is
totally unacceptable and one of the reasons I am totally against bean
managed persistence without the aid of some persistent cache framework i.e.
TopLink.
In fact the above figures are not totally accurate since I have included 2
optimizations one when the findByPrimaryKey is called we do not do a lookup
in the database and the other at the end of a transaction we do not do an
update. The assumption with the first optimization being that the key does
exist. To be EJB compliant a bean would have to perform 3 sql calls. First
to check that the key exists in the database (ejbFindByPrimaryKey) and the
second to load the state (ejbLoad) and the third to store the state
(ejbStore). So we can expect a great deal more overhead. Scarry. So given
that we have eliminated 2 sql calls why are we seeing such high figures?
Well it all to do with the beans contract with the container. The contract
states that the ejbFindXXXX methods in the bmp entity bean must return a
collection or eumeration of primary keys. Thus in the method we do select
key from sometable where someclause is true we would then iterate through
the result set creating a list of keys. Now when we return this list, the
container bean interceptor will create entity bean proxy like objects which
store this key. When the client (session bean in our case) accesses the
beans methods (through the proxy object) the first time the ejbLoad method
will be called which will result in a sql statement like select key,
somefields.... from sometable where key is pk. So if a find method returns
200 objects (actually keys) we will have generated 200 + 1 sql calls. This
is the bottleneck. How the Inprise Container solves this overhead with CMP
is that the state is loaded with the first sql which will look like
something like this select select key, somefields.... from sometable where
someclause is true. Why can't bean managed persistence do the same, well
because in the find method we must return the key we are not allowed to
create entity bean objects and set there state. The container is responsible
for resource allocation including memory (bean creation). Maybe this is one
of the reasons that people have not moved to entity beans and advocate
session beans with sql code.
3. Conclusion
With the above results we see that things are not so clear cut in the EJB
world. We can see that the advice given on newgroups regarding read only
access of data using session beans calling JDBC code is based on vendors
failings in their implementations. We can also see that it is very hard to
write non specific vendor Enterprise Java Beans without suffering enormous
performance headaches.Since the Inprise Application Server is the only
vendor to give the EJB Bean developer the ability to code beans in a
non-vendor specific way the bean developer is in fact locked in, but maybe
this is not so bad.
4. Notes
i. The tests above were done using a single client. I would expect the
performance difference between IAS 4.0 and WL 4.51 to be considerably more
since IAS is based on Visibroker 4.0 and 2.3 CORBA compliant ORB which
avails of the new POA.
ii. The cost of activation as session is 75% slower with Web Logic 4.51.
This attributed to their reliance on RMI technology.
Next Report the benefits of tuned writes.
> -----Original Message-----
> From: Frank D. Greco [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, February 24, 2000 3:26 PM
> To: [EMAIL PROTECTED]
> Subject: When to Use EJB? (was: Session EJBs vs. Java Objects)
>
> >Ahi Satapathy wrote:
> >> So when EJB should be used ? what should be the factor one should
> consider
> >> before going to implement something with EJB ? If the site is not
> >> transactional, has no authorization security needs, and is read only,
> should
> >> one go for simple Java Objects and use Servlets with direct JDBC
> access ??
>
> At 05:13 PM 2/20/00 -0600, Richard Monson-Haefel wrote:
> >In a word, "maybe". You need an experienced architect (consult your
> >physician) to review your system and make a recommendation. Most
> >high volume sites (Amazon, eToys, et.) that have a lot of read only
>
> High volume as in number of concurrent visitors or number of
> transactions? Or high volume as in page throughput or http (or
> socket) throughput?
>
> >navigation and no transaction needs for the reads, should be implemented
> >with something other then EJB - I like servlets. BUT, the purchasing
>
> Theoretically EJB can be used for high-volume sites like an
> electronic
> trading system. Architecturally, as part of an App Server
> product, EJB
> should not be fundamentally slower than Servlet/JDBC/JavaClasses.
> The
> vendor app server product should be able to scale much better than
> a
> home-grown solution. If the home-grown solution is superior...
> then I
> want to get in on the IPO... ;)
>
> >of goods and services on these sites should be implemented with EJB via
> Servlets.
>
> Actually, are there 'rules of the road' for this stuff? What are
> the
> heuristics for choosing a AppServer/EJB(et al) over a
> WebServer/Servlets?
>
> Frank G.
> +======================================================================+
> | Crossroads Technologies Inc, 55 Broad Street, 28th Fl, NYC, NY 10004 |
> | Dot-com Engineering |
> | Email: [EMAIL PROTECTED] Web: www.CrossroadsTech.com |
> | Voice: 212-482-5280 x229 Fax: 212-482-5281 |
> +======================================================================+
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
