Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon-Phoenix Developers List"
 <avalon-phoenix-dev@jakarta.apache.org>
Message-ID: <3D94E8D3.9030601@yahoo.com>
Date: Sat, 28 Sep 2002 00:25:07 +0100
From: Paul Hammant <Paul_Hammant@yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: Avalon-Phoenix Developers List <avalon-phoenix-dev@jakarta.apache.org>
Subject: Re: Jo! integration questions
References: <397317FA-D23F-11D6-8430-000393B61B56@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter, Ulrich

To round up a series of messages here (late to the conv)....

1. The speeds are relative.... and out of date.  Run the unit tests for 
AltRMI after changing the speedtest.iterations property in 
Ant.properties to something like 10000 from 1.  The figures are not 
perfect as Junit and Threads really distort the tests, but at least it 
allows you to collate some sort of benchmarking information.  The test 
results show the time taken for the TestSpeed method ofr each trasport 
(that is the point).

2.  Same VM optimisations.  Well if a WAR file app wanted to open a 
AltRMI socket transport to some server in the same VM, then it would 
still open a socket connection.  Vinay and I have talked about the 
perfect way to shortcut that to a pipe instead (irrespective of the 
client's chosen transport) and we know we can do it, but the perfect 
multi-classloader solution is still being thought over.  There are some 
complexities that we need to smooth out, or else we will do something 
that will work in 70% of the situations perfectly, and the remainder 
not.  The remainder being for the advanced user.

Regards,

- Paul

> On Friday, September 27, 2002, at 11:27  AM, Ulrich Mayring wrote:
>
>> If Java RMI does 4329 calls per 10 seconds, that equals 432.9 per 
>> second, which means a single request takes a little more than 2 ms to 
>> complete. How could you possibly have saved a couple hundred ms that 
>> way? :)
>
>
> Because I changed a bunch of things at once, and didn't do any 
> super-formal benchmarking :) There are also multiple rmi invocations 
> per request (sometimes), so I may have saved up to 10ms in the calls I 
> removed.
>
>> I'd be willing to invest 0.48 ms per request :)
>>
>> Anyway, it's probably got to do with the null method invocation, if 
>> we start to push some real data, we will see much different numbers. 
>> Your application would be a good example, you probably push some 
>> XML-file sized data around, have you made any measurements?
>
>
> I'm pushing mainly hashmaps (aside from Strings and primitives), but 
> its a nested structure (a container object with a hashmap and then an 
> array of hashmaps, think parent object and collection of children, but 
> just a data-extract).
>
> I did some simple, informal speed tests of the system as a whole a few 
> months back, but the recent push has been on completing functionality, 
> as it is "fast enough". The average request is still over 1sec tho 
> (not good enough for me yet), but the main bottleneck is the xslt 
> transforms.
>
> I have on my list to push everything into the same JVM and do proper 
> benchmarks on that, as we have a customer that will be coming online 
> in the next few months that has speed requirements in their contract. 
> I'll be sure to update the list with some numbers once that happens.
> -pete
>


--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>