SPECjAppServer2001 has been kicked off with the first results posted by IBM. The single node test running on WebSphere AppServer 4.0.3 on IBM's eServer iSeries i890 resulted in scores of 804.09 BOPS (business operations/second) and $4847.59/BOP.
Note that SPECjAppServer2001 is a modified version of ECperf 1.1, and these results should not be compared with previous results on the original ECperf site
View IBM's SPECjAppServer2001 Results
Read WebSphere Application Server certifies SPECjAppServer2001 benchmark results
View TheServerSide's recent ECperf cartoon
A single node costs $4 million?!? Just wait until the multi-node results are posted :)
SPECjAppServer2001 tests J2EE 1.2 (EJB 1.1, etc.) implementations. Now that we are about a year into a J2EE 1.3 era, these results seem somewhat irrelevant.
Also, these results should be treated as an all-IBM-stack benchmark, not a WAS benchmark as the test name implies, since they used everything IBM: hardware, OS, JVM, database, etc...
all these socalled 'benchmarks' aren´t *really* benchmarks IMHO. As long as ECPerf maybe ran on verry dissimilar hardware there is no real relevance to the test, it´s more like looky here, I spent 4 million on hardware and I can run somany BOPS on that hardware, then the other one comes spents 50K on hardware and does just about 1 tenth of the BOPS.
ECPerf & SPECjAppServer2001 is like comparing apples to pears. It´s more like a comparisson of hardware than anything else.
$3.8M was paid for more than hardware. WAS licensing alone would have cost $384K (32 CPUs x $12K/CPU). I guess the DB2 and OS licensing must have cost something too.
Besides, there is a way to compare $50K stack to $3.8M stack: it's $ per BOPS. In your example the $50K stack would provide 7.6 times better value than the $3.8M stack. Of course, $/BOPS is a rather one-sided metric.
It sounds like a lot of money but if you consider the following....99.99% uptime, no server farm consisting of 8 $50,000 servers, fewer staff to maintain. FYI the operating system comes(considered hardware)with the hardware price and unlike everyone else including IBM, DB2 is part of the OS and so is the JVM unlike every other system. This system won't go belly up when you add real business workload to it. This is a mainframe class system, people without a budget need not apply.
Just a quick comment: on an iSeries, DB2 is an integral part of the operating system. So in terms of the stack, there's no distinction between DB and OS.
My guess is that part of IBM's purpose in running/posting this result is to establish the suitability of the platform for heavy transaction volumes.
Interesting quote: "IBM is currently the only vendor running the benchmark using critical data consistency. The requirement states that all transactions must take the database from one consistent state to another, meaning data must not be corrupted. These additional requirements changed the performance characteristics of the benchmark from ECperf such that comparisons between the two are inappropriate."
I thought that was what Pramati was saying six months ago, that they (Pramati) were the only ones protecting the data? ;-)
(If you read William Louth's article, you'll see they mean I guess.)
Anyway, congrats to IBM for posting the highest number so far!
: Easily share live data across a cluster!
Interesting that they're not issuing WAS 5 results either - it's due for release soon, but they're obviously not far enough down the line to do reliable testing on it ;-)
Interesting that they're not issuing WAS 5 results either - it's due for release soon
Gee, isnt it really a feature that someone posts benchmarks on something you can actually use in production?
"IBM submitted this recent benchmark result in the Single Node System category."
The entire point of the J2EE complexity that has given rise to the app server is distributed web and mid tier. Local interfaces admit that the mid-tier and db are co-hosted which wipes out a significant part of the reason for app servers. But with only a single node there is NO reason to use app servers if you are not distributing.
Just use a webserver,JVM and JDBC. Maybe thats what a modern app server is in their mind.
Message Driven Beans. Is it worth buying into an app server just for MDB's if on a single node?
"Local interfaces admit that the mid-tier and db are co-hosted..."
Can you elaborate on this statement? Local interfaces recognizes that objects that play together should stay together - thats it. I don't understand how their usage means that the DB is co-hosted - which I assume means server collocation.
Architect of JDBInsight - "Tune with Insight"
"Local interfaces admit that the mid-tier and db are co-hosted"
Use of local interfaces requires the EJB to be in the same JVM as the EJB client. It doesn't say anything about the database. I think SPECjAppServer2001 is still EJB 1.1 so it doesn't have local interfaces anyway.
The value of writing J2EE is that the application CAN be distributed, not that it HAS to be. Just because it is deployed on a single node, doesn't mean you don't need an application server, it just means that for a particular deployment, a single node gave you the appropriate reliability and scalability etc. But you still maintain the flexibility to rehost onto a different configuration if needed.
"Just use a webserver,JVM and JDBC"
Why roll your own when you can use a J2EE application server (whether purchased or open source) that supplies naming, persistence, transaction management, messaging, connection pooling, workload management and other features? It saves a lot of time and money even if you don't use all the features.
Just and FYI - local interfaces do not refer to the location of the database(s) - the database(s) can be anywhere. And I agree with another poster in that there is no need to roll your own solution when using the existing components of an app server will work at least as well, if not better, than the home-rolled version.
Jonathan: "Message Driven Beans. Is it worth buying into an app server just for MDB's if on a single node?"
No. Is it worth buying a car just for a steering wheel?
OTOH, it's d***ed handy to have a steering wheel when you're trying to drive. And MDBs are a handy way of using an EJB to handle a queued message, which is handy for doing async processing even on a single node.
: Easily share live data across a cluster!
Thanks guys, I'd never imagined having the EJB's on a different host to the DB. Why is that? Fine grained EJB's (and CMP) are closely coupled to the schema, and the entire remote interface idea was to seperate the tiers. Then the value object comes along as a mechanism to make the remote calls more efficient, and then local interfaces come along to clear out value objects with a pass by reference symantic.
So, you are all saying, basically, that the entire EJB principle is founded on JDBC and so we can decouple the EJB's from the database box.... gaaaarrrrghgghfhhhf
So what was the point of the EJB spec in the first place? Simply an O/R mapping technology with a bit of caching (which is massively flawed IMHO). Is that it?
As for the comment about 'are MDB's worth it?'. I'm pretty neutral here. From the point of view of teams with an app server then fine, use it, you have it. From the point of view of teams which have never used an app server and are scared of them - eg manitenance, skills, changing specs, deployment, more tools to manage, more tools to simplify, changing specs etc etc. Then I believe its a valid question. RMI does the job. Sockets do the job. And wrapping a socket up into an asynch listener is easy. BUT assured deliverence is not (sorry, delivery, deliverence is different :).
So I guess the real question is 'If your app needs assured message delivery then an app server is certainly a good solution'.
And using a JVM, webserver and JDBC is not rolling my own. Made me chuckle did that. This architecture is solid as a rock and has been here almost as long as java. It may not be sexy, but it scales, is easy to understand, develop, maintain and involves no license fees. KISS truly does pay.
I use JMS without any MDB in sight - JMS as a spec is quite nice IMHO, and implementations don't always depend on an app. server.
(JMS for MQ-Series, for instance)
Works like a charm, both synch. and asynch.