Hi,
Apologies for my silence in the last couple of days. I have been busy...
On Sat, 24 Nov 2001, marc fleury wrote:
> Ok so if I read your stuff correctly what you mean by "RMI/IIOP" semantics
> is enforcing that we work from IOR all the time, ie. serialized
> representations of invocations. It is as if we were using "MO.get()" in the
> optimized stack, WHICH WE DO if for example the cl test we were talking
> about the other day fails.
Yes.
> You are saying removing the network give a speed of 2. I want to see MO vs
> the same serialization both without the stack.
Ok, now I got some new numbers. But they are so counter-intuitive I feel
uneasy about posting them. (Did I screwed something up bigtime?)
Well, even at the risk of looking ridiculous, I am attaching to this
message a text file with my new numbers. (To view it you need a text
window with at least 97 columns.) I am about to commit to contrib/iiop the
code I used to get these numbers, so anyone can look if there is something
wrong in it. This will also allow me to tell you precisely (by referring
to the code) what changed in each measurement.
Anyway, these numbers show that:
- My IIOP stuff does not like the multithreaded testcases of the bank
suite. This might be a problem in JacORB, I do not know yet. I played
with the jacorb.poa.thread_pool_max parameter in an attempt to make
things better, but had very small success here. On the other hand, the
IIOP stuff outperforms the JRMP code in RH on _all_ other bank testcases.
- A local call path buys me nothing. This is very counter-intuitive!
A possible reason could be that my local call path is superfluous
because JacORB provides one such path anyway, but I still have to
check if this is true or not.
- MarshalledObjects are bad. Maybe not as bad as the numbers I posted
last week might have suggested, but they're bad anyway.
- Having getHandle()/getHomeHandle() implementations in the IIOP stubs
makes a great difference. I could reproduce last week's bad numbers
only by disabling the stub implementations of these methods. This was a
big surprise for me, as the bank testsuite does not explicitly call
getHandle(). It appears that the object pooling code makes a lot of
getHandle() calls.
- The performace penalty of param/result copying (to get proper RMI/IIOP
semantics on the local call path) is very small in the bank testcases.
Cheers,
Francisco
Times in seconds, on a PII 400MHz w/ 256M RAM
running Linux kernel 2.2.19
and Sun JDK 1.3.1 build 1.3.1-b24
RH main IIOP IIOP IIOP IIOP IIOP IIOP
IIOP IIOP
(JRMP LP LP LP LP LP no LP no
LP no LP
LP no CP no CP CP no CP CP
no CP) no MO no MO no MO MO MO no MO
MO MO
(1) (2)
(3)
testTeller 19.983 20.452 20.590 19.562 23.422 23.879 20.374
22.401 31.356
testBank 1.001 0.395 0.507 0.527 1.421 1.517 0.497
1.340 1.340
testMultiThread 178.551 888.022 874.585 888.838 905.898 942.769 891.106
909.519 1868.587
testMultiThread2 173.741 885.955 880.567 896.045 926.035 952.402 899.614
947.406 1856.483
testTransaction 10.041 5.837 6.975 5.593 8.796 9.054 6.009
8.993 11.095
testTransfer 14.304 13.343 13.354 14.570 18.557 18.878 12.555
16.646 84.310
testReadOnly 85.222 8.781 8.593 8.227 58.318 59.394 9.671
58.349 62.116
testPassivation 5.454 7.282 6.402 7.136 6.760 6.762 6.399
7.092 7.434
testFinder 43.323 13.537 11.713 12.349 59.452 59.249 12.534
58.291 62.631
testServerFound 38.240 6.459 5.754 6.295 53.620 53.398 6.304
52.409 56.642
- LP x no LP: Local call path enabled (LP) or disabled (no LP)
- CP x no CP (just for the LP case): copy parameters and return value
to get proper RMI/IIOP semantics (CP) or just pass references
around (no CP)
- MO X no MO: IORs of entity beans contain a MarshalledObject wrapping the
entity bean's PK (MO) or contain a custom serialization of the
PK (no MO)
- except for column (3), the methods getHandle()/getHomeHandle() are
implemented directly in the IIOP stubs and hence never reach the container
(1) - jacorb.poa.thread_pool_max=100
(2) - jacorb.poa.thread_pool_max=200 at this column and at the following ones
(3) - disabled implementation of getHandle/getHomeHandle in the stubs
