Re: Performance: Reflection/proxies/JMX

[Alex Blewitt <Al...@bandlem.com>]

> AFAIK currently there are three approaches to the EJB problem domain
>
> 	1. Managing the EJB's using reflection
> 	2. Managing the EJB's through dynamic proxies
> 	3. Managing the EJB's using JMX
>
> Of these, the last one is newest and thus has the least references.  
> There is a good
> academic study on the first two approaches  
> (http://www.cs.rice.edu/CS/Systems/DynaServer/> perf_scalability_ejb.pdf)
> which states that there is no major performance  differences between  
> the two.

I'm not sure that JMX will necessarily give any better performance than  
other approaches; the main purpose of JMX (IMHO) is to provide a  
configuration mechanism to allow external agents to  
monitor/change/invoke methods.

That said, I don't believe building on top of JMX and having the whole  
architecture dependent on JMX messages makes sense particularly, though  
it would of course be beneficial to have a JMX interface on top (rather  
than underneath).

My money would be on reflection rather than dynamic proxies; a lot of  
the more recent JVMs have spent time specifically optimising  
Method.invoke for just these sort of applications. And since we're  
going to have to go from some kind of String method name (from a  
network request) -> lookup Method -> invoke, we might as well use  
reflection for the direct process, rather than storing a dynamic proxy  
and then indirecting through that.

I've had a quick perusal of the document above, but I'm not convinced  
of the results being indicative of one being faster than the other. The  
document talks a lot about 'JBoss using dynamic proxies rather than  
JoNaS using pre-compiled classes', which just dictates when the RMI  
layer gets generated/compiled -- not how fast it is when executed.  
Plus, the measurements are based on results testing the whole system,  
and thus it's not necessarily the case that just because Operation A on  
Server A takes longer than Operation B on Server B that one low-level  
choice that Server A has made is the right one. It could be that a  
bunch of the other code is more optimised, for example.

Perhaps tests (on multiple architectures) would be desirable to find  
out how fast one approach is over another. For my money, dynamic  
proxies are a bit of a kludge that are useful to developers who wish to  
write minimal code than necessarily generating the fastest code.

But then, which is more desirable -- maintenance or speed? :-)

Alex.

Re: Performance: Reflection/proxies/JMX

[Dain Sundstrom <da...@coredevelopers.net>]

From: Dain Sundstrom <da...@coredevelopers.net>
Date: Thu Aug 7, 2003  10:50:51 AM US/Central
To: Alex Blewitt <Al...@bandlem.com>
Subject: Re: Performance: Reflection/proxies/JMX

On Thursday, August 7, 2003, at 07:04 AM, Alex Blewitt wrote:

>> AFAIK currently there are three approaches to the EJB problem domain
>>
>> 	1. Managing the EJB's using reflection
>> 	2. Managing the EJB's through dynamic proxies
>> 	3. Managing the EJB's using JMX
>>
>> Of these, the last one is newest and thus has the least references. 
>> There is a good
>> academic study on the first two approaches 
>> (http://www.cs.rice.edu/CS/Systems/DynaServer/> 
>> perf_scalability_ejb.pdf)
>> which states that there is no major performance  differences between 
>> the two.
>
> I'm not sure that JMX will necessarily give any better performance 
> than other approaches; the main purpose of JMX (IMHO) is to provide a 
> configuration mechanism to allow external agents to 
> monitor/change/invoke methods.

What JMX is designed to do and what make it really useful are 
completely different.  JMX provides lifecycle management, naming, 
decoupled typeless invocations and notification.  The speed of JMX is 
not really imporant as the study points out, because it is such a small 
part of an invocation.

> That said, I don't believe building on top of JMX and having the whole 
> architecture dependent on JMX messages makes sense particularly, 
> though it would of course be beneficial to have a JMX interface on top 
> (rather than underneath).

And JMX is required by the J2EE specification.

> My money would be on reflection rather than dynamic proxies; a lot of 
> the more recent JVMs have spent time specifically optimising 
> Method.invoke for just these sort of applications. And since we're 
> going to have to go from some kind of String method name (from a 
> network request) -> lookup Method -> invoke, we might as well use 
> reflection for the direct process, rather than storing a dynamic proxy 
> and then indirecting through that.

I think you are confused here.  Dynamic proxies is a way to create an 
implementation of an interface at runtime and reflection is how you 
invoke a method by name (effectively) at runtime.  They are 
complementary things.  For EJB you get the following:

User invoke methodBlah -->
     MyDynamicProxy(implemnts MyEJBRemoteInterface) -->
     InvocationHandler(methodBlah) -->
     some interposed functionality (i.e. start a transaction) -->
     methodBlah.invoke(myEJBImplementationClass)

See you must have a dynamic proxy, to multiplex the invocations through 
a single code path, and a reflective invocation at the other end to 
demultiplex the invocation back into the actual implementation method 
in you EJBClass.

> I've had a quick perusal of the document above, but I'm not convinced 
> of the results being indicative of one being faster than the other. 
> The document talks a lot about 'JBoss using dynamic proxies rather 
> than JoNaS using pre-compiled classes', which just dictates when the 
> RMI layer gets generated/compiled -- not how fast it is when executed. 
> Plus, the measurements are based on results testing the whole system, 
> and thus it's not necessarily the case that just because Operation A 
> on Server A takes longer than Operation B on Server B that one 
> low-level choice that Server A has made is the right one. It could be 
> that a bunch of the other code is more optimised, for example.

I have had a lot of experience with this paper.  The paper attempts to 
look at how the architecture effects performance, but is looks at the 
entire structure instead of comparing individual design decisions.  For 
example, Jonas has a very fast network layer (custom vs RMI) and JBoss 
has a very fast client side code (smart proxies that can handle 
requests without going over the network vs dumb proxies).

> Perhaps tests (on multiple architectures) would be desirable to find 
> out how fast one approach is over another. For my money, dynamic 
> proxies are a bit of a kludge that are useful to developers who wish 
> to write minimal code than necessarily generating the fastest code.
>
> But then, which is more desirable -- maintenance or speed? :-)

In my mind speed is not that important.  We need to be in the same ball 
park as everyone else, but maintenance, ease of use, and understandable 
code are most important.

-dain

/*************************
  * Dain Sundstrom
  * Partner
  * Core Developers Network
  *************************/