I picked up this link via a mailing list that I am subscribed to. It points to some research done by "MiddlewareRESEARCH". The research (unfortunately) was done in Redmond, so even though I am sure it was done professionally and impartially it will be shaded as not being so by the J2EE community. What was disappointing was that even though one of the application server vendors seemed to keep up with .NET this time (atleast in throughput) they chose not to publish their name. I for one am keenly interested to know who it was so that when I am asked by customers who cannot for various reasons move away from J2EE technology can atleast pick the one that is going to perform best.
From the results, I'd say that the J2EE vendor would likely have been either Oracle or IBM, but that is pure speculation.
What I do find amusing is that they needed to hold .NET's hands behind its back in order to level out the performance - notably Output Caching which is a HUGE ASP.NET feature.
They did use API caching to reduce the number of hits on the database, however, without Output Caching you still incur a CPU hit when rendering the page because you need to build the control hierarchy. Output Caching basically allows you to store the results of a page (including query string variations) so that the CPU basically only has to copy some data from memory to the network socket. This in-turn would mean that requests would be processed faster for the same amount of CPU effort.
What I really want to see is a performance "study" done on making these applications fly as fast as they can using every hack in the book. Of course, there are those people that say thats not appropriate, but I say they need to take a course in Google economics.