| Brian Lesser 2005-04-07, 5:56 pm |
| Hi Everyone,
I thought I'd share some performance test results I just collected using=20
different RMI routing methods.
In Peldi's last coding caf=E9, Peldi demonstrated an optimized method to=20
route client-to-server method calls. Instead of the client calling a=20
method this way:
nc.call("FCChat.chat1_mc.connect", null);
or this way:
nc.call("pfcs.SharedText.main.edit", null);
Peldi showed how a client could call a method on the Client.prototype=20
this way:
nc.call("c2s", p_resObj, p_cID, p_method, arguments.slice(3,=20
arguments.length));
The c2s method in turn looks up and calls a component method. The=20
primary advantage of calling c2s, and letting it look up and call a=20
server-side component method, is that object chains do not have to be=20
added to every client to receive component calls such as this connect()=20
call on the chat1_mc object:
client.FCChat.chat1_mc.connect()
Both the FCChat and chat1_mc objects take up memory but are only=20
attached to the client so that the connect() method will be called.
When I watched Peldi's presentation I wondered if there was a=20
performance penalty to be paid for the work the c2s method has to do to=20
figure out what public component method to call. So I thought I would do=20
a simple test to find out. I setup a test of four method calls:
1. calling a method on the Client.prototype that directly calls a=20
component method,
2. calling a method on the client object that directly calls a component=20
method,
3. calling a method on a client chain=20
(pfcs.SampleComponent.instance.scMethod()) that directly calls a=20
component method,
4. calling c2s which looks up the method in a white list before calling i=
t.
I ran 18 tests on each method call type and got the following averaged=20
times in milliseconds:
1. Client.prototype: 75.50 ms.
2. client object: 75.50 ms.
3. client chain: 78.94 ms.
4. c2s: 79.83 ms.
Average round trip ping time was 62 ms just after the test.
From the results you can see that a method on the Client.prototype or=20
on the client object that just calls a component's method, and returns=20
the results, takes 75.5 ms. Using the client object chain approach takes=20
3.44 ms longer and the c2s method 4.33 ms longer in my test.
That the c2s method took longer was no surprise. I expect that if I had=20
uncommented the full role-based security code it would have taken a=20
little longer still. Doing extra work in the c2s method saves memory (no=20
object chains) at the expense of performance. Depending on your=20
application (and a bunch of other factors) reducing memory use and=20
taking a small performance hit could be a really good choice to make. In=20
other cases (where method call queuing is a problem) it might not be.
What I did not expect to see was a similar performance drop when calling=20
a component method via an object chain. I now assume that FlashCom must=20
have to do a significant amount of work to convert a method call in the=20
format "FCChat.chat1_mc.connect" into a connect() method call on the=20
client.FCChat.chat1_mc object.
Without knowing the internals it seems to me that, if possible,=20
improving performance of calling a method on an object chain would be a=20
good candidate for the next release.
So what to conclude from this? The difference between the object chain=20
call and the c2s call is very small or insignificant. When it comes to=20
performance with the current fcs 1.5.2 release you can use either. But=20
Peldi's c2s method saves you memory and that's good!
If I have time later I'll look at the security model in Peldi's c2s=20
demonstration code and see if it can be improved by removing the hard=20
coded role names and introducing access control lists.
If I make progress there, I'll likely add something like c2s call=20
routing as an option in the pfcs framework.
So score another one for Peldi! :-)
Yours truly,
-Brian
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
|