OK,
the performance is really in two parts AFAIK
jboss 2.0 uses the same invocation mechanism as jboss 1.0 (both were
Rickard's dynamic proxy). We had jboss 1.0 cruising at a healthy 3ms
invocation and 10 times less with inVM optimization. So we know it is not
the dynamic invocation stuff...
There is a "glitch" somewhere that gives us this crappy numbers.
Once we get past this I know there will lots of optimizations we can do.
The invocation layer being a biggy (Norbert got great numbers on benchmarks
of spyderMQ once he rewrote that) and the invocation with the "message" like
structure is close to that. ALso there are a lot of little things we can do
to speed it up, but that is in a second phase.
We have assigned a team in project Game Over just on the performance it is a
cross-discipline team that is supposed to get it right.
first things first
marc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Stephan Gruschke
> Sent: Saturday, July 08, 2000 2:00 PM
> To: [EMAIL PROTECTED]
> Subject: [jBoss-Dev] Any news on perfomance issues?
>
>
> Hi everyone,
>
> I'm currently working on the bmp entity beans implementation and I'm
> nearly finished now. I hope I can integrate the modifications tomorrow
> so that tomorrow evening jboss 2.0 is bmp entity beans capable again.
>
> The problem I'm currently running in is the performance issue. I'm
> running an WinNT 4.0 with 400Mhz, 192MB and fetching 25 BMP entity
> beans from an session bean. Each entity bean has four properties
> (simply returning the internal variable).
>
> Each methods needs between 200 and 320 milliseconds regardless whether
> running the test for the first or the second time. Running the test
> first time includes the creation of the entity beans. Second time
> the entity beans are already created and are simply accessed by
> reference. So i can extract the database performance from the time
> needed to fetch the properties of the beans.
>
> Well, i realized that i need nearly one second to fetch the data from
> one entity bean and then 15 seconds to fetch the data from 18 entity
> beans. By using an session bean there were no costs for client
> communication etc. Looking at the stack trace the session bean still
> establishs connection via the RMI. After the remote method invocation
> the fetching time is less than a millisecond (measured inside the jrmp
> invocation handler).
>
> It's obvious that rmi communication must be done for client
> communication (even the session bean is an client to the entity
> beans). Is there any way to optimize the connection and bypassing rmi
> if both beans are in the same process environment?
>
> After exhaustive testing i think that's one of the main performance
> problems. Anyone did the same experiences?
>
> Stephan.
>
>
>
>
