× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



David,

My point about EJBs was that they provide a means of distributing workload
across additional threads, or even across multiple servers, whether they're
used to manage data persistence or not.  Of course there's overhead
associated with that, but it may be necessary with 100% J2EE interfaces, as
the scope of applications grow.

On an n-way server, the Java application server itself IS a bottleneck!  For
example:

http://www.redbooks.ibm.com/redpapers/pdfs/redp0429.pdf

This IBM Redpiece covers a Java benchmark where a 24-way model 840 with 90
Gb RAM, running 5 instances of Websphere hit a knee at 50,000 transactions
per hour.  A "knee" is a point where completed requests begin to go down.

By distributing the workload between 40 instances of Websphere rather than
5, transactions per hour climbed to about 1,000,000.  Same box.  Just
utilizing the processors differently.

While there's overhead associated with EJBs, there's overhead associated
with running 40 instances of Websphere.  Consider the 90 GB of RAM on the
server.  Consider deploying applications across multiple App server
instances.  The point is that J2EE is a distributed architecture for a
reason.

Every J2EE benchmark I read about involves only a small handful of Servlets.
They don't show much more than the average CPU time to complete simple
requests.  So what will happen in a real world environment involving
thousands of concurrently running Servlets, JSPs, and other components
performing business logic?

Java objects have comparatively larger instruction sets and memory
requirements.  My prediction is that we'll see major performance degradation
as cache reloading occurs, swapping components in and out of cache.  The
only answer I can think of for this would be to distribute workload across
CPUs.

So long as your application will always run on a single CPU system, by all
means, use a more efficient interface, like Hybernate.  Joe Pluta offers an
even better solution, in my opinion.

Nathan.


------------------------------

message: 6
date: Tue, 09 Mar 2004 10:52:51 -0700
from: "David Morris" <David.Morris@xxxxxxxxxxxxx>
subject: RE: Does jBoss work on iSeries?

Nathan,

EJBs have certainly improved and aggregation is one area that improvements
were made but your example is where a lighter weight API like Hibernate or
iBatis will perform much better. In general, you don't persist summarized
data back to the original data model so EJBs are not helpful in this case
although they will seriously impact performance. You can run into this
situation with Hibernate but you don't have to leave the API to fix the
performance problem.

David Morris




As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.