The test is too simple and lacking in diagnostics.
Where was the bottleneck (90% in the OS network layer?)
Is ~1 minute enough time to make "random" full GCs insignificant,
has the JIT even kicked in, etc.?
Making performance decisions on these kind of simple tests (which are subject
to arbitrary implementation changes across versions) is stupid.
It is also worthless without looking at concurrency.
I know from the JBossMQ tests that UIL2 is significantly faster than RMI, can't remember
the numbers off the top of my head? But that is from running unit tests (real world
jms usage), not simple benchmarks.
OMG, who invided Adrian? ;)
As usual, you are correct. However, I don't want to take the time to write the raw transport counterpart tests for my remoting performance tests until I am sure I can write ones that are correctly represented. So I wrote these simple ones to verify my approach was valid, as would be a lot more wasted time if do the full performance testsuite for raw rmi and socket and they are flawed.
So run for an hour on a loopback interface to make a better first pass on diffs, or was this run over a local loopback.
Will just write the full fledge raw transport tests the duplicate the remoting performance tests (so can capture in nightly testsuite run via cruisecontrol and have jrunit benchmark reporting). Already did the rmi one.
Plan on running different scenarios (number of calls, payload size, etc.) on a reserved qa box to get some real numbers next week.