|
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 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.