Performance Evaluation of Java And C++ Distributed Applications In A CORBA Environment

Transcription

1 Performance Evaluation of Java And C++ Distributed Applications In A CORBA Environment Sanjay P. Ahuja Roger Eggen Cheryl Daucher Department of Computer and Information Sciences University of North Florida Jacksonville, FL sahuja@unf.edu Abstract Distributed applications are very common many of which work on heterogeneous platforms. The CORBA paradigm is a middleware that allows for the development of distributed applications in these heterogeneous environments. Since CORBA is language and platform neutral, we can use several languages to develop distributed applications using the CORBA paradigm. This paper evaluates the performance differences of a C++ distributed application and a Java distributed application using CORBA as middleware. The advantages and disadvantages of developing distributed applications in C++ and Java are also discussed as are the services offered by the two CORBA ORBs. The C++ and Java distributed applications were developed using the Visibroker C++ and Java ORBs respectively. Keywords: Java, C++, CORBA, performance evaluation. 1. Introduction The decrease in cost and the increase in performance of computer hardware are creating a rapid rise in the number of distributed environments in business and industry. These new distributed environments are often heterogeneous in nature. The Common Object Request Broker Architecture (CORBA) platform is a form of middleware being used to develop e-commerce applications and distributed applications in heterogeneous environments. CORBA is a distributed object system. The goal of distributed object systems is to let an application interact with a remote object exactly the same way as it would with a local object. In addition, distributed object systems provide the ability to construct an object on one host and transmit it to another host [1]. Designers of distributed applications should to be aware of the performance and architectural characteristics of CORBA as they make their design decisions. This paper addresses this need and empirically evaluates the performance differences between C++ and Java in a distributed environment using CORBA as the middleware. A distributed application was designed and built using C++ and compared against an identical distributed application designed and built using Java. The distributed application consisted of a three-tier client/server database application using the CORBA paradigm for communication. Both applications connect to the same Oracle database running on a Linux system. The C++ implementation connects using ODBC and the Java implementation connects using JDBC. Performance measurements on the read and write speeds of client requests on the database were used to compare the two

2 language implementations of the distributed application. In addition qualitative comparisons were made in the areas of ease of development, ease of maintenance, and portability across platforms. The rest of the paper is organized as follows. Section 2 discusses CORBA architecture. Section 3 discusses the ODBC architecture and how it compares to the JDBC architecture. Section 4 describes the distributed application built using both C++ and Java. Results obtained by taking performance measurements are described in Section 4. Conclusions are listed in Section CORBA Architecture The Common Object Request Broker Architecture (CORBA) is a standard developed by the Object Management Group (OMG). The purpose of the CORBA paradigm is to provide developers a way to develop systems that are not reliant on a single operating system or programming language. With CORBA you invoke method calls on objects residing on another machine without having to move those objects to the machine making the method call. CORBA allows you to get a reference to an object that lives on a remote host and invoke methods on that object. Each remote object implements an interface that specifies which methods clients can invoke [2,3,5]. The CORBA paradigm consists of the following elements: i) An Object Request Broker (ORB), which provides the primary communication between the client and the server. ii) Common Object Services (COS), which assist the ORB in establishing and maintaining the communication bus between the client and the server. iii) An Interface Definition Language (IDL), which provides the developer with a way to define object interfaces and compile them into the programming language being used. To create a CORBA application an interface for the functionality of the application must be designed. This interface is then written using IDL. The IDL file(s) are compiled to the chosen development language using an IDL compiler. The IDL compiler generates stub and skeleton code for implementation. The client application will use the stubs as interfaces with the ORB and the server application will use the skeletons as interfaces with the ORB. The client and server then need to be implemented in the chosen language. [3,5] To use a CORBA application there must be COS services running and an ORB on both the machine running the client and on the machine running the server. When the server starts it registers any remote objects with the COS services. The client can then request the registered remote object. A reference to the object will be returned to the client. The client then invokes methods on the object by communicating through the ORBs. [3,5] 3. ODBC and JDBC Architecture Open Database Connectivity (ODBC) and Java Database Connectivity (JDBC) were both designed to provide developers with a uniform and database independent interface to develop database front-end applications. The ODBC API consists of a specific database driver and an ODBC Driver

3 Manager. There is a specific database driver for each data source supported using ODBC. The Driver Manager loads the driver dynamically when it is needed and implements the function in the ODBC API. When the database application is executed the Driver Manager routes the ODBC API calls to the appropriate ODBC driver. The ODBC API interfaces provide a standard interface for the database developer to use in connecting, querying, and obtaining results from a database [4]. Like ODBC the JDBC API has two distinct layers. The application developer uses the driver implementation to connect to the database and then uses the application layer to access the database. The application interfaces Connection, Statement, and ResultSet provide the ability to connect to, execute SQL queries on, and retrieve result sets from the database [5]. 4. Results and Performance Evaluation In order to compare a C++ distributed application and a Java distributed application the same application was developed using each language. The ORBs used were the Visibroker ORBs for C++ and Java thus ensuring that both these ORBs were from the same vendor. It was ensured that both the C++ application and the Java application were developed and executed on the same Windows workstations. The Oracle database, to which both applications connected, was on a Linux machine. This ensured a heterogeneous platform for the distributed application. The LAN environment for all the machines used was a 1 Mbps Fast Ethernet connection. The Visibroker Smart Agent utility was used for the Common Object Services (COS) for CORBA communication. The distributed application was a three-tier database application, which simulated order requests on a corporate ordering system. The user could enter an order (light write), update an order (heavy write), request the total of a given order (light read), or request the order history for a customer (heavy read). Each read and write response was timed. Averages of the read and write times were used to compare light read, heavy read, light write, and heavy write requests on the distributed applications. Variances of the response times were calculated to verify the consistency in response times of the servers. The servers for the distributed application were designed to accept multiple clients so that performance under various load conditions could be measured. The Visibroker ORBs handled accepting multiple clients, but thread synchronization in the C++ server application used mutexes while the Java synchronized keyword was used to synchronize threads in the Java server. Both distributed applications were tested using increasing client loads of 1, 5, 1, 15, 2, 25, 5, 75, 1, and 125. The C++ distributed application gave the best performance for light read requests. This can be observed in Figure 1 as the number of concurrent clients increase the C++ application performs better than the Java version. The performance of the C++ application was better than the Java application for light writes, heavy writes, and heavy read requests until the number of concurrent clients reached between 1 and 2 (Figures 2, 3 and 4). Then the performance of the C++ application decreased at a faster rate than the performance of the Java application, which remained nearly stable. The variances of the timings for all requests remained small indicating that the server applications were consistent.

4 The performance difference in favor of the Java distributed application with increased numbers of concurrent clients was not expected. With non-distributed applications C++ has proven to have better performance. The Java distributed application used a Java ORB, JDBC to connect to Oracle, and the Java thread synchronization method. The C++ distributed application used a C++ ORB, ODBC to connect to Oracle, and mutexes to control thread synchronization. In order to isolate whether the difference in the performance of the applications was due to the different CORBA ORBs, the different database connectivity methods, or the different synchronization methods, two additional timing experiments were run. Both experiments were alterations to how the heavy read requests were handled by the server applications. Heavy read requests were chosen because they showed the greatest difference in performance levels and reads on a database could be nonsynchronized without corrupting the database. The first experiment was aimed at isolating the performance of the Java ORB and the C++ ORB without any database access. In this experiment the C++ and Java server applications were hard coded to return a specific heavy read result without performing the read request on the database. The results showed that the performance of the C++ ORB was better than the Java ORB for up to 75 concurrent clients. At 75 concurrent clients the performance of the C++ ORB had decreased to the same performance level as the Java ORB, and it continued to decrease as the number of concurrent clients increased. The performance of the Java ORB was remained steady as the number of concurrent clients increased (Figure 5). This indicates that the immediate difference seen in performance at low client numbers is not due to the performance of the ORBs themselves. The second experiment was aimed at isolating whether using mutexes in C++ to synchronize threading was less efficient than using Java s thread synchronization. In this experiment the thread synchronization was removed from the heavy reads of both server applications. The performance of both distributed applications was almost identical to the results of the synchronized applications. The divergence of the C++ application performance from the performance level of the Java application still occurred at 1 to 2 concurrent clients (see Figures 4 and 6). This indicates the differing thread controlling mechanisms were not playing a part in the performance difference between the applications. The results of the two experiments indicate that the C++ distributed application with the C++ ORB performed consistently better than the corresponding Java application by a small margin with up to 15 to 2 concurrent clients. After that as the level of concurrency increased with up to 75 concurrent clients, the C++ distributed application performed better by a small margin than the corresponding Java application in the absence of a database access. This would suggest that the difference in performance observed between 2 and 75 clients is more a function of performance differences between ODBC and JDBC accesses to the database than the performance of the ORBs themselves. At very high levels of concurrency (> 75 concurrent clients), the C++ distributed application no longer offers any performance gains over the corresponding Java application. Along with the quantitative performance of the distributed applications, efforts were made to evaluate qualitative factors such as

5 ease of development, ease of maintenance, and portability across platforms. Overall the time needed to learn, develop, and debug and test the C++ distributed application was significantly longer than the time required for the Java distributed application. The same issues that increased time required for developing the C++ distributed application compared to a Java distributed application will affect the time required to maintain a C++ distributed application compared to a Java distributed application. This will make maintaining a Java distributed application more cost effective than maintaining a C++ distributed application. 5. Conclusions The performance advantage that C++ has over Java in non-distributed applications extends only partially to distributed applications in a CORBA context. This is because in addition to the role played by the ORBs for the two languages, the database access also has a role to play. At light to modest concurrent client concurrent accesses, the C++ ORB and application do perform better than the corresponding Java ORB and application by a small margin. In cases that required significant interaction with the database and at high levels of concurrent client accesses, the performance of the Java distributed application compared favorably with the C++ application. This would indicate that the JDBC API performs well in comparison with the ODBC. Thus the overall performance advantage that a C++ distributed application has over a corresponding Java application in a CORBA context is not significant. developer to concentrate on the application logic and not worry about the low-level database connection and record set locking details. This significantly decreases development time. Likewise, even though CORBA is a language neutral paradigm, development of a CORBA application in Java is quicker and easier than in C++. The implementation of the required CORBA client and server are more straightforward and less complex in Java than in C++. References [1] Ahuja, S. P., and R. Quintao, Performance Evaluation of Java RMI: A Distributed Object Architecture for Internet Based Applications, Proceedings of the Eighth International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems (MASCOTS 2), San Francisco, CA, August 2. [2] Flanagan, D. and Farley. J., Java Enterprise In a Nutshell, O Reilly Publishing, September [3] Henning, M. and S. Vinoski, Advanced CORBA Programming with C++, Addison Wesley Longman, Inc., [4] Sanders, R., ODBC 3.5 Developer s Guide, McGraw-Hill, [5] Zukowski, J., Mastering Java 1.2, Sybex Inc., In addition, development in Java is quicker and easier than development in C++. Database connectivity using Java and JDBC is less complex to develop than using C++ and ODBC. JDBC allows the application

6 5 Figure 1. Light Read Requests 25 Figure 5. Heavy Read Requests (No Database Access) Figure 2. Light Write Requests Figure 6. Heavy Reads (No Synchronization) Write Time (ms) Figure 3. Heavy Write Requests 3 25 Write Time (ms) Figure 4. Heavy Read Requests