How many CPUs in production: 2
We chose JBoss for several reasons. The primary drivers were performance, feature set, and cost.
When we were setting out to develop our new content management platform for the Web, we knew that we wanted to go to J2EE. As we started looking at containers, we were immediately attracted to JBoss as an Open Source solution. As we learned more about the project and its active developer community, it was obvious that JBoss was going places and fast.
We deployed a test version of our application on JBoss 3.0 alpha last December. After testing, we put the first JBoss 3.0 beta release into production for a project that needed the new features. That application processed 25,000 complex transactions in the first 2 months of operation, easily keeping in step with the demand. And this was the beta version of JBoss!
As JBoss evolved, we've standardized on the 3.x JBoss platform for all of our J2EE work. JBoss provides the features we need for literally $0 cost.
What we've seen as an added value are some of the extensions the JBossGroup developers have added. Things like JBossCMP have quite a few features that enhance the Sun J2EE spec. These additional features have cut our development time significantly.
Our JBoss installation handles about 35 million hits per month. Due to the intelligent cache architecture in JBossCMP, our app spends less time in round-trips to the database.
Our cost savings is hard to quantify. There is the obvious savings in the cost of a J2EE container... But the other parts are what really counts: access to source code, frequent releases and bug fixes, an active developer community, etc...