Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 53935 invoked by uid 500); 7 Aug 2003 12:05:31 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Delivered-To: mailing list geronimo-dev@incubator.apache.org Delivered-To: moderator for geronimo-dev@incubator.apache.org Received: (qmail 52870 invoked from network); 7 Aug 2003 12:03:58 -0000 Date: Thu, 7 Aug 2003 13:04:34 +0100 Subject: Re: Performance: Reflection/proxies/JMX Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Lyytinen Joonas" From: Alex Blewitt In-Reply-To: Message-Id: <4F4888A8-C8CF-11D7-B192-0003934D3EA4@bandlem.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > 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.