Well Sven, you could download the kits there in therserverside and at Sun's (ECPerf is a spec and comes with its own toolkit) and implement the tests. I think the community would appreciate it ;). If Luis wants to help you, all the better ;). The ECPerf benchmarks there depict common hardware themes, such as Sun Fire Cluster, or Dell PowerEdge 4600(in the top ten Price/Performance chart, both Sybase and BEA post results using the DELL hardware). To give the exact statistic you're looking for, a huge amount of money would be needed, as choosing a single hardware platform won't yield truthful results. A given app-server may perform better as the number of uPs in a box increases, whereas other may respond inversely. And people may challenge the applications that are run on those as well. It's a debate that will never conclude and therefore it is a useless debate, IMO.
Now, an explanation regarding the URLs. I've been involved in several large projects with J2EE. But I can't just give all details of those projects and reveal the customer. I either do one or the other. If I go around doing both, then my customers will challenge my work ethics and also my ability to provide them a service in acceptable terms for them. You work for a bank Sven, so I guess you know what I'm talking about here. I didn't comment on the hardware platform in which the biggie I worked in runs, so I update it here: CMP 1.1 Large, clustered web site. Failover, load balancing, the works. A Cluster of CheckPoint Firewall-1 up front. A ServerIron load balancer to balance the firewall cluster and the web/app server cluster. 2 common type-3 switches to split the web/app cluster into 2 islands. 4 Web/App servers. Single P III 850 MHz, 1 GB RAM, 20 GB IDE drives. OS: W2K. Web/App Server: Orion. 1 BackEnd server, same spec. 2 Compaq DS-20 Machines to run a Clustered Sybase RDBMS. Heavy on the DB (all pages shoot at least one "virtual" transaction, most are optimized because they're read-only). 50,000 users per hour. 500,000 page views per hour. 5,500,000 transactions per hour. (1,527 transactions per second). All pages are served in less than 12 seconds(timeouts otherwise). Statistically the chance of getting an error-page due to timeouts is 1 in 100,000. This is empiric data. This is all I can contribute to metrics discussion. Now, as I typed this I noticed the following statement by Vinicius: > Answers like that, make me think that the lack of arguments justifying the use of Entity Beans instead of O/R mapping > tools or Session Beans + SQL, etc, is still a barrier for a wide adoption of Entity Beans by the market... You're way off track if you think performance is an issue to choose among EBs, O/R mapping tools and straight JDBC. As long as they perform within the same order of magnitude, the choice should belong to a "non-technical" category. That's why I proposed many times using Assembler(to see if anybody came back, but nobody did). The evolution of programming languages is the history of code reuse, not decrease of computing time to solve tasks. Assembler allows the machine code programmer to build libraries and reuse code as well as handling other hairy aspects of machine code(like automatic reference relocation, Xref, etc.). C added platform independence of code as well as stadarizing many basic libraries. C++ added OOP and inheritance to the mix. Lately, white-box reuse is being replaced with black-box reuse. Finally, one could just turn the statement around: the lack of arguments justifying the use of JDBC over Entity Beans, all other things being equal, is the barrier that prevents me from spending a lot of time writing a lot of code that EBs generate anyway for free or a lot of money on O/R tools that only do the same as EBs. Why would I code straight JDBC? 1) Because it's a solution-domain requirement, either directly or indirectly(e.g.: a bank only offers a SP, service-based access to their systems). 2) Because I percieve EB adoption is riskier(low IQ?, coming from a non OOP background?, resistance from old techies who don't want to learn anything new?, management isn't convinced?, management already has a consultor?, and yes, these happen in real life). If my customer wants to minimize risk disregarding value(defined as cost/benefit) then no EBs. 3) Because I want to spend more time coding, so the bill grows larger. Why would I adopt O/R mapping tools? 1) Management bought it. Of course, every O/R vendor will swear that EBs do not work and their product is a must. 2) I know for a fact that the server I'm using has poor EB support(like Websphere 3.x). And of course there are many times when JDBC makes sense, but O/R, I think it's not worth the cash. My final 2c(won't bother anybody else any further), Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 11, 2002 3:34 PM > To: Juan Pablo Lorandi > Cc: [EMAIL PROTECTED] > Subject: Re: the truth about entity beans > > > > http://ecperf.theserverside.com > > That would be a good benchmark, if it included hardware > specifications, > which it currently does not. I´m sure OAS/BAS/WLS/Websphere > et al. perform > well on a cluster of their choice. The question is however, > how do they > preform with the same application (ECPerf) on a standardized set (or > different sets to measure performance in diffrent types of clustered > hardware etc) of boxes and operating systems. > > > sven > > > > Juan Pablo Lorandi > > Chief Software Architect > > Code Foundry Ltd. > > [EMAIL PROTECTED] > > > > Barberstown, Straffan, Co. Kildare, Ireland. > > Tel: +353-1-6012050 Fax: +353-1-6012051 > > Mobile: +353-86-2157900 > > www.codefoundry.com > > > > > > > -----Original Message----- > > > From: A mailing list for Enterprise JavaBeans development > > > [mailto:[EMAIL PROTECTED]] On Behalf Of Luis A > > > Sent: Friday, October 11, 2002 2:56 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: the truth about entity beans > > > > > > > > > There are a lot of jokes about cars, but I am eager to see > > > the real questions answered. > > > > > > > I hear a lot of system architects say that entity beans > are slow. > > > > What's the true about this issue? Entity Beans are slow? > > > > If not, which great J2EE systems(in production) are > based on entity > > > beans? > > > > Are there benchmarks which proof that entity beans can provide > > > > good > > > > performance? > > > > > > Someone can point out any URLs? > > > > > > > > > ----- Original Message ----- > > > From: "Sven E. van ´t Veer" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Friday, October 11, 2002 7:24 AM > > > Subject: Re: the truth about entity beans > > > > > > > > > I´ve heard it depends a lot on year and model. I´ve heard the > > > 316 wasn´t really fast. > > > > > > A mailing list for Enterprise JavaBeans development > > > <[EMAIL PROTECTED]> wrote on 10/10/2002 18:40:31: > > > > > > > I am sure that it is not slow! Aren't you? > > > > > > > > Vinícius > > > > ----- Original Message ----- > > > > From: Dimitar Stavrakov > > > > To: 'Vinícius de Faria Silva' ; '[EMAIL PROTECTED]' > > > > Sent: Thursday, October 10, 2002 6:27 PM > > > > Subject: RE: the truth about entity beans > > > > > > > > Hi Vinicius, > > > > > > > > Is BMW a slow car? A lot of people say that > > > it's a pretty > > > > fast car others that it's not. > > > > Any thoughts? > > > > > > > > Regards, > > > > > > > > Dimitar > > > > > > > > -----Original Message----- > > > > From: Vinícius de Faria Silva [mailto:[EMAIL PROTECTED]] > > > > Sent: Wednesday, October 09, 2002 12:13 PM > > > > To: > > > > Subject: the truth about entity beans > > > > > > > > I've been following discussions about the pos and cons of > > > entity beans > > > > for 2 years. I'm not sure yet if this approach is good or > > > not, mainly > > > > in terms of performance. > > > > I hear a lot of system architects say that entity beans > are slow. > > > > What's the true about this issue? Entity Beans are slow? > > > > If not, which great J2EE systems(in production) are > based on entity > > > beans? > > > > Are there benchmarks which proof that entity beans can provide > > > > good > > > > performance? > > > > > > > > regards, > > > > > > > > Vinícius > > > > > > ========================= > > > 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". > > > > > > ============================================================== > > > ============= > > > 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". > > > > > > > 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". > ==========================================================================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".
