java rpc project: final presentation
Post on 05-Jan-2016
18 Views
Preview:
DESCRIPTION
TRANSCRIPT
Java RPC project:Final presentation
By:
Anat Hashavit
Sigal Ishay
Vladimir Lazebny
Agenda
Project Objectives Abstract Misc aspects of implementation
Multithreading, dynamic registration, version control, exception management, server stability
UML Class Diagram Testing and test results
Project Objectives
A design pattern describing possible implementation of RPC mechanism
First stated in “RPC-Based methodology for Client/Server application development in C++”, 1997
Implement the above paradigm in Java Compare performance versus Java built-in
RMI mechanism in some specific application
Project Objectives (cont.)
Main differences from the example presented in the original article: Multithreading Multiple requests per connection Multiple services Dynamic service registration and dispatching Exception handling Version control Server stability Java instead of C++
Abstract
A client-server Remote Procedure Call (RPC) model
No explicit IDL file – client and server share the same generic code
We provide a strong and flexible server application, number of clients is only limited by HW
Special emphasis on the ability to develop and add new services easily
Server Parts
Server core – responsible for establishing and maintaining connections, administration console, thread pool, service management
Dispatching mechanism – the steps taken by the server to handle incoming requests
Specific services – implementation of different “classes of functions” available to clients
Communication – generic Input/Output primitives used to encapsulate actual media access
Multithreading
Main thread listens on a socket waiting for incoming connections
Once new connection is established client is authenticated. Notably, version control is also done here
New thread is assigned for every connection (class DispatcherThread)
Thread pool is used to allocate / manage threads.
* multi-threading demo
Dynamic registration
Developer adds specific “classes of functions” (services) by writing certain Java classes and registering them in the server
Every service must obey certain rules: Provide Agent, Client, Server, and
ServiceFactory classes Implement two interfaces (below)
Services can be loaded/unloaded dynamically without server restart
Server is configured by an .xml file that specifies services loaded on server start
Dynamic registration (cont.)
All services are registered in a ServiceRegistry according to their “service ID’s”
ServiceRegistry is shared between multiple threadsProtected by “multiple readers/single
writer” lock in order to reduce synchronization to minimum
* Dynamic reg. demo
Server stability
Extensive use of exceptions in any place anything can go wrong, especially around I/O
Number of clients is limited (configurable) Special way to quickly reject a connection if
server resources are nearing depletion (currently used only for thread limit)
Notably, while doing our tests, we have never observed a single server crash!
Even offers significant protection against errors in service code (exception forwarding)
Version control
Version is only checked once – on new incoming connection
Developer must advance server version number manually
No need to introduce per-service version system – better to add under a new service ID, allowing services of different versions to run simultaneously
Exception Management
Main objectives while designing:Flexible to the maximumAs little overhead as possibleNot obligatory to use – often
developer does not care about exceptions
* Exception demo
Exceptions (cont.)
May forward any exception – not only some pre-defined one like RMI, but any exception at all – the Exception object itself is serialized and sent to the client
Developer may chose in what places the program is likely to have exceptions - or not at all
Protocol is very efficient (see protocol diagram)
Performance
Server is quite complex: dynamic dispatching, thread management etc.
Runs in Java VM – another drawback Server overhead is O(1) regarding input All the server complexity practically does
not influence performance – tests with very small arguments make it to about 1 ms/call
Tests have shown that disabling exceptions gives no measurable increase in performance
Protocol diagram
Functionrequest(Service IDand func ID)
Can/can’tserve
Inputparameters
Outputparameters
Exc
eptio
n st
atus
Exc
eptio
n st
atus
. . .
Client
ServerDispatching Calculation
UML Class Diagram - Server
UML Class Diagram - Service
UML Class Diagram - Communication
Testing
Services used for testing RMI application Test results Results analysis and conclusions
Service Packages
Service implementation is standard and uniform for all services A side developer should be able to understand
it at a glance Consists of 4 standard classes: AgentFactory
Implements the interface: ServiceFactory Specific Agent
Base class of specific server and client classes Defines the common code for client and server
agents
Service Packages (cont.)
Specific Agent ServerExtends Specific AgentStatic dispatcher for the agent’s
servicesImplements the interface functions
which perform actual computations Specific Agent Client
Extends Specific AgentSimple wrappers for remote calls
Agents Implementation
We implemented three RPC agents General Agent: performs general purpose
operations such as reloading from registry and connection shutdown
List Agent: an example agent that handles various list operations
Tree Agent : an example agent that handles various tree operations
Tree Package
Works with binary trees containing integers as keys (no data)
Includes the following functions: unionRPC – calculate union of two received
trees (result bigger than input) intersectionRPC – calculate intersection of
two received trees (result smaller than input) sumToLevel – receives binary tree and a
number (level) and computes the sum of all nodes to this level (no need to transfer entire tree)
Tree Package (cont.) Example for common code:
protected ReturnCode unionRPC(TreesWrap tw) throws Throwable {
ReturnCode result = new ReturnCode(ReturnCode.SUCCESS);
comAgent.input(tw.getParam1());comAgent.input(tw.getParam2());comAgent.endOfInput();tw.getRes().clear();// empty in client, in server does the actual calculationresult = doUnion(tw);
// does nothing in server, in client may throw exceptioncomAgent.checkException();comAgent.output(tw.getRes());comAgent.endOfOutput();return result;
}
List Package
Includes the following functions: FirstNavg – receives a list of integers (l) and
a number (N) and calculates the average of the nodes L(0) to L(N)
IsPrefix - receives two lists and determines whether one is a prefix of another
ReverseList – The function receives a list and reverses it
RMI Application
Client-Server application written in the most straightforward way – no hand optimizations
Server - side function implementations are copy-pasted from RPC services
Clients of RPC and RMI differ only in a actual remote function call and opening/closing connection – rest of the code is the same
RMI Application (cont.)
However, we do expect some differences Entire input parameters are serialized in RMI
version, while in RPC we customize input depending on function
In RMI we have two separate applications – for Tree and List functions – no dynamic dispatching overhead
Also exception handling and version control mechanisms are different
Test ResultsList RMI Vs List RPC
We compared RMI to RPC for the list agent and the tree agent.
List First N avg: we calculated the average of 5000
first nodes of a 50,000 nodes list – expecting RPC to outperform RMI
Is prefix : we sent a list of 50000 nodes and a list of 5000 nodes expecting RPC to outperform RMI
Reverse List : we sent a list with 1000 nodes: expecting RMI to outperform RPC
Test ResultsTree RMI Vs Tree RPC Tree
Union: unite two trees of 15,000 nodes
Intersection: intersection between two trees of 15,000 nodes each, expected RPC to outperform RMI
Sum to level: up to level 10 of 25,000 node tree, expected RPC to outperform RMI
Results- List: first N avg
RPC RMI
Total time 13551.0 101228.0
Min time 600.0 668.0
Max time 980.0 3481.0
Average time 677.55 1012.28
Variance 81.217 401.247
Results- List: Is Prefix
RPC RMI
Total time 17841.0 110841.0
Min time 780.0 832.0
Max time 1310.0 2933.0
Average time 892.05 1108.41
Variance 122.46 315.23
Results- List: Reverse List
RPC RMI
Total time 30636.0 3277.0
Min time 251.0 15.0
Max time 959.0 159.0
Average time 306.36 32.77
Variance 123.78 20.7811
0
200
400
600
800
1000
1200
avg execution time
RPC Vs RMI: List Agent
RPC
RMI
RPC 677.55 892.05 306.36
RMI 1012.28 1108.41 32.77
List:FirstNAvg List:IsPrefix List:ReverseList
Test Conclusions
• RMI easily serializes more information then needed, control on the serializing process can improve performance
• The ratio between the amount of information sent by RPC and the amount of information sent by RMI needs to be quite large in order too see significant difference in performance
Results –Tree: Union
RPC RMI
Total time 246129.0 80488.0
Min time 1369.0 377.0
Max time 5055.0 2303.0
Average time 2461.29 804.88
Variance 857.062 365.303
Results –Tree: Intersection
RPC RMI
Total time 127081 65261.0
Min time 901.0 316.0
Max time 2843.0 1762.0
Average time 1270.81 652.61
Variance 319.209 234.632
Results –Tree: Sum to level
RPC RMI
Total time 4431.0 8248.0
Min time 210.0 166.0
Max time 356.0 1227.0
Average time 221.55 412.4
Variance 31.74 236.75840
RPC vs. RMI: Tree agent
0
500
1000
1500
2000
2500
RPC 2461.29 1270.81 221.55
RMI 804.88 652.61 412.4
Tree:Union Tree:Intersection Tree:SumToLevel
avg execution
time (ms)
Test Conclusions
• RPC is definitely worse in performance – meaning network transfer time
• Sending same object by using serialize and write to socket takes many times more time than RMI function call
Final Conclusion
• The initial assumption is correct : Controlling the amount of data transferred can result in better performance
• However: Although RMI sends too much information it does so in a very efficient way
• Optimizations on the serialization process used in RPC can bring to much better results
top related