RMI Performance Comp. with Forte

Question

Hi All,
I know that this topic has been discussed on the list
already, but I would like to find out whether the
current state of Sun's RMI implementation is like
I imagine it, and I want to compare with our Forte
Service objects too. Basically, these seem to be
issues that negatively affect performance,
1. A thread is created on the server per request, and
there is no way to change this easily (i.e. reuse
threads from a pool)
2. Each call opens a new socket.
In particular, does it make sense to replace RMI with
CORBA for increased performance and scalability? Can a
PC-based server handle loads of about 1000 remote
calls per second (considering the overhead imposed by
RMI/other communication methods only)? or Shall we
compare Forte against RMI.
Thankx,
Babu

Answer 1

Okay,
A method invocation (or function call or procedure call or whatever) is
always a synchronous call. This means, you ask the service to do something
and wait for the function to complete, optionally with return values. It is
possible, that within the method, a separate thread is started, that
continues after the method is completed, but that doesn't change the
mechanism that a method invocation is a synchronous call.
In Forte, it is possible to start a method as an asynchronous call, with the
"start task" command. In that case, the caller does not wait for the method
to complete and return values are not handled. If this method invocation
happens across a network (making it a Remote Method Invocation) then a
socket will be opened when the call is made and closed immediately after. It
does solve the one-socket-per-caller problem, but not the
one-thread-per-caller problem. Also, it does remove the possibility of
receiving return values.
If you want to keep using method invocations as synchronous calls with
return values, but you also want to share resources like sockets and
threads, then you have to use TP-monitoring concepts. You must have a two
way, asynchronous call with an additional parameter. This means, the client
does a single, brief call that re-uses an existing thread and immediately
frees the socket it used. The client passes all required parameters and one
additional parameter to identify itself. In Forte, this would be a reference
to an anchored object on the client-partition. Then the client waits
(possibly blocks). The server completes the request and locates the client
that sent the request. The server invokes a method on the client, informing
that the request was handled. The server now also passes all return values.
The client exits its wait-state and continues.
In Forte (even if you use other mechanisms to hook into Forte), every call
still is a separete thread. If you wish to re-use existing threads, this
must be done using events. So, a client invokes a method asynchronously
(using "start task") and waits. The server start a new thread and posts an
event. Each existing thread is either idle in an event loop or busy handling
a previous event. The new event is added to the queue of all event loops and
the original thread is terminated (the socket was already freed). One event
loop of the thread-pool will be the first one to respond to the event, mark
this somewhere (maybe using mutex) and start handling it. All the others
will eventually respond to the event as well, but will be able to see that
the event is already being handled and ignore it.
This does introduce overhead and it makes your application more complex, but
it also prevents you running out of resources.
Now, the real issue is not the amount of calls per second, but a combination
of calls per second and seconds to complete the call. Using these two
numbers, you can calculate the amount of tasks the server has to be handling
simultaneously at any given time (average). Using the above described
technique you can handle intermittent, large loads, because if there are
more requests than available resources (threads) at any given time, the
requests will simply be put in a queue and handled later. However, if the
over-load continues for a prolonged period of time, the queue will simply
grow and grow and grow until the partition crashes and all queued items will
be lost.
Then it is time for load-balancing. You install several additional servers
and run a serverprocess on each of these machines. And you use a router that
distributes calls across the different serverprocesses. Forte has built-in
mechanisms for that, that work reasonably well. However, if the amount of
calls per second is so high, that even the short time it takes the router to
relay the request still is too long, so that the router runs out of
resources, then you have to use more complex models, for which Forte doesn't
have any ready-to-use solutions. But neither does CORBA or Java I believe.
One more thing. If you combine the above described mechanism to free sockets
as quickly as possible and use Forte loadbalancing, you might solve all your
problems. Just install 6 overloaded server processes. This results in 6
processes times 256 threads per process equals 1536 simultaneous tasks. If
each task is an asynchronous method invocation that immediately frees its
socket, then you never block you're whole server by using all sockets and
you're still able to do handle 1536 requests simultaneously.
Remember, if you have such a large load of calls per second, that all pass
through the same machine (router) then you'll run into hardware limitations
and no software solution can fix that. You have to find a mechanism to
distribute calls across different nodes without using a single router. For
example, cluster clients and have a single server node per cluster.
Pascal.
-----Original Message-----
From: Babu Raj [SMTP:ibcsmartboyyahoo.com]
Sent: Friday, March 24, 2000 3:42 PM
To: Rottier, Pascal
Cc: kamranaminyahoo.com
Subject: RE: (forte-users) RMI Performance Comp. with Forte
Hi,
I believe in CORBA, ORB maintains the same
connection ( Same Socket) for multiple calls, on the
same Servant object, unless otherwise its ONEWAY call.
But RMI uses the same strategy as Forte, I'm not sure
either on this. Thats the reason, i asked the previous
question.
Thankx,
Babu
--- "Rottier, Pascal" <Rottier.Pascalpmintl.ch>
wrote:
How are CORBA and RMI different then Forte (one
socket and one thread per
call)?
-----Original Message-----
From: Babu Raj [SMTP:ibcsmartboyyahoo.com]
Sent: Friday, March 24, 2000 3:18 PM
To: kamranaminyahoo.com
Subject: (forte-users) RMI Performance Comp. withForte
Hi All,
I know that this topic has been discussed on thelist
already, but I would like to find out whether the
current state of Sun's RMI implementation is like
I imagine it, and I want to compare with our Forte
Service objects too. Basically, these seem to be
issues that negatively affect performance,
1. A thread is created on the server per request,and
there is no way to change this easily (i.e. reuse
threads from a pool)
2. Each call opens a new socket.
In particular, does it make sense to replace RMIwith
CORBA for increased performance and scalability?Can a
PC-based server handle loads of about 1000 remote
calls per second (considering the overhead imposedby
RMI/other communication methods only)? or Shall we
compare Forte against RMI.
Thankx,
Babu
For the archives, go to:
http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. Tounsubscribe, send in a new
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
For the archives, go to:
http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To
unsubscribe, send in a new
email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com