[chrisplough]

Nice - thanks for the great information and benchmarks!

Please don't get me wrong, I'm not attacking the hardware choice (always a good way to start out an email - ha!); and I actually enjoy the back and forth!

There may be a flaw in one of the primary assumptions, "I have been told that OTM doesn't really have large sequential jobs, instead, it is multi-threaded which should especially suit the CoolThreads servers". I say may, because it depends on your usage of OTM. It is true that it is highly multi-threaded (very highly - it starts out with 150+ threads on the app tier). The problem is that most of the processes that businesses rely upon are actually very intensive single-threaded processes -- such as the planning logic (especially bulk plans), saved queries, many Agent actions, reports, etc. So OTM actually presents the hardware with a tough mix of both many, many threads and very intensive single-threaded algorithmic calculations. In fact, this per-transaction latency (i.e. how fast a single-threaded process completes) is the biggest cause for OTM performance issues and complaints. A higher number of cores simply provides scalability, which is also very important, but fundamentally different.

Also all current OTM versions utilize the 1.4.2 JDK - which doesn't scale well on multi cpu/core hardware; with the exception of JRockit on the Intel platforms. OTM v6.0 will support the 1.5.x JDK, but that won't be generally available for another year.

I'm currently working with 3 of the OTM clients who have been using the application for years and who now have (or will soon have - depending on the client) the app's highest volumes. On one of these projects, we worked with Sun and were able to test against the servers you've mentioned, as well as a M9000 server with the new soon-to-be-released Jupiter-class CPUs. I'm not at liberty to give actual results, but I can say the they were disappointing. I have higher hopes for the Jupiter+ CPUs on the far horizon (as they scale further into the GHz range); but I believe the root cause is the Sun JDK -- which isn't nearly as efficient as JRockit. F

Finally, as part of this analysis, we found that the per-core performance on all tiers was severely lacking. Financially, this doesn't matter on the OTM Web and App tiers (no per-core licensing), but was a killer on the DB server, with a final Oracle license cost several times the comparative Intel/Linux combination.

Now - this may not be an issue, depending on your projected volumes and usage. That's one part of your solution that I don't have any insight into.

The reason I sharing this information is just so you're better prepared. I highly recommend the VolanoMark benchmark mentioned earlier, as it compares well to general OTM performance (highly multi-threaded) and the DaCapo benchmark, as it compares well to bulk plans and other high-calculation, low thread processes, and finally the Hammerora benchmark, which replicates TPC-C and gives a great indication of DB performance.

Run the tests for yourself and then compare to the results we've posted. As a note, we'll have a new server coming in about 1-2 weeks in preparation for a Hosting client that has a total of 16 Intel cores. I'll post the results when I have them, but from years of experience, I'm expecting VolanoMark results between 394232 and 417889, DaCapo results around 12632.00 and Hammerora results around 205.00.

Please let me know your thoughts and your results if you run the benchmarks!

BTW - looking at your volume numbers, I would consider you a high-volume client. Again, get the hardware (you can't beat a 60-day trial) and benchmark away. Please share your results, as I'm always interested in other experiences -- it helps me stay up-to-date.

--Chris