Local and remote EJB performance comparison – PART I

Technical infrastructure development

It is an obvious fact that local EJB calls are more efficient than remote. The aim here is to observe the difference between these calls in terms of time and resources consumption and finally provide observation results. In this post is given an overview and an explanation of a technical infrastructure with a goal to measure both local and remote EJB calls. The infrastructure consists of Java EE application suites and two managed servers running on Oracle WebLogic application server.

Introduction

There is prepared and used Java EE solution to perform EJB calls. The solution is built upon JEE components creating together application suites. A suite will be called as Java EE application or just application within this article. The application is deployed on WebLogic managed servers. Development environment requirements are provided in the post: Oracle WebLogic Managed Servers Configuration [1]. However, the application can be deployed on other equivalent application server configuration since it follows Java EE 6 standard.

1. Infrastructure composition

The infrastructure is built based on WebLogic application server with the deployed application suites. There are two WebLogic managed servers running on dedicated logical machines (separate JVMs). On a one machine is deployed JEE application which provides business service to be called. On the same machine is deployed local monitoring module which performs local calls to the business service. On the second machine is deployed another monitoring module which performs remote calls to the business service placed on the first machine. Both local and remote calls are initiated by requests sent from JConsole to respectively local and remote monitoring modules. The monitoring modules implementation is based on JMX. The infrastructure composition is presented in Figure 1.

deploy-env

Figure 1: Infrastructure composition

In Figure 1 is presented one WebLogic domain named base_domain. Within this domain exist two machines – Machine-0 and Machine-1. Each machine has one running managed server – Server-0 and Server-1 respectively. Machine-0 has deployed JEE com.softexploration.lab.ejb.performance.monitoring.local.suite application which assembles the business service implementation and the local monitoring module. On the other hand, Machine-1 has deployed com.softexploration.lab.ejb.performance.monitoring.remote.suite JEE solution which assembles only the remote monitoring module performing remote calls to business service placed in com.softexploration.lab.ejb.performance.monitoring.local.suite. Assembling local monitoring module in the same EAR where is placed business service implementation is a correct approach following JEE standard. More detailed information regarding modules and suites structure is provided in next part Application artifacts and suites. Finally, JConsole clients connect to manageable local and remote modules deployed on WebLogic managed servers. In this scenario, performance tests are executed by manual requests initiated on JConsole.

2. Application artifacts and suites

There are developed Maven artifacts which in proper combination create application suites. In general, artifacts are divided into three categories: core, suite and auxiliary.

Note

Module is here considered as a package (archive) containing implementation or configuration files.

Artifact follows Maven grouping approach. An artifact does not have to contain any application’s file, therefore an artifact is not always a module whereas a module is always an artifact (at least in this article).

Suite is here a certain collection of modules creating one deployable unit. In technical terms a suite is an EAR.

2.1. Core artifacts

com.softexploration.lab.ejb.performance.service – this artifact includes business interface definition – BusinessPerformanceService and data types definition handling requests/responses. In addition to the mentioned business interface there are two other interfaces extending it – BusinessPerformanceServiceLocal, BusinessPerformanceServiceRemote for local and remote calls purposes.

com.softexploration.lab.ejb.performance.service.impl – this is the default BusinessPerformanceService implementation. There is defined SLSB implementing BusinessPerformanceServiceLocal, BusinessPerformanceServiceRemote interfaces.

com.softexploration.lab.ejb.performance.client – this one is the base client artifact with a definition of ClientPerformanceService interface. The ClientPerformanceService with an appropriate implementation is then used by manageable beans in the monitoring layer. The artifact provides common client logic implementation of ClientPerformanceService performing calls to BusinessPerformanceService. Each business method in ClientPerformanceService corresponds to exactly one method in BusinessPerformanceService. Client methods collect time result of business service invocations.

com.softexploration.lab.ejb.performance.client.local – this artifact provides SLSB using base implementation from com.softexploration.lab.ejb.performance.client and enables local EJB calls.

com.softexploration.lab.ejb.performance.client.remote – this artifact provides SLSB using base implementation from com.softexploration.lab.ejb.performance.client and enables remote EJB calls.

com.softexploration.lab.ejb.performance.monitoring – the module provides PerformanceServiceExecutor interface definition. This is a super-interface of end-user interfaces PerformanceServiceExecutorLocalMXBean and PerformanceServiceExecutorRemoteMXBean. The interface has methods which address to appropriate methods in ClientPerformanceService. The artifact has also PerformanceServiceExecutorBean class implementation which provides logic responsible for registration manageable beans.

com.softexploration.lab.ejb.performance.monitoring.local – provides PerformanceServiceExecutorLocal i.e. the end-user manageable bean implementation for testing local EJB.

com.softexploration.lab.ejb.performance.monitoring.remote– provides PerformanceServiceExecutorRemote i.e. the end-user manageable bean implementation for testing remote EJB.

2.2. Suite artifacts

com.softexploration.lab.ejb.performance.monitoring.local.suite – artifact assembles final EAR including modules with business service implementation and also those related to the local monitoring module. The structure is shown in Figure 2.

com.softexploration.lab.ejb.performance.monitoring.remote.suite – artifact assembles final EAR including remote monitoring module. This module refers at runtime to business service in remote EJB calls. The structure is shown in Figure 3.

2.3. Auxiliary artifacts

com.softexploration.lab.ejb.performance.monitoring.local.suite.build – helps to build com.softexploration.lab.ejb.performance.monitoring.local.suite.

com.softexploration.lab.ejb.performance.monitoring.remote.suite.build – helps to build com.softexploration.lab.ejb.performance.monitoring.remote.suite.

local-suite

Figure 2: com.softexploration.lab.ejb.performance.monitoring.local.suite EAR

remote-suite

Figure 3: com.softexploration.lab.ejb.performance.monitoring.remote.suite EAR

3. Application structure

The solution as a whole includes certain modules which are assembled into suites. There are two JEE applications reflecting to the following suites: com.softexploration.lab.ejb.performance.monitoring.local.suite and com.softexploration.lab.ejb.performance.monitoring.remote.suite. All application components are laid out in three layers: JMX, client and service. The JMX layer takes requests coming from JMX client e.g. JConsole. The requests are then delegated to PerformanceServiceExecutor component in the same layer. The PerformanceServiceExecutor performs calls in a loop to client layer. In the next stage client performs local or remote call to service layer providing business service implementation. After business method execution client receives service’s response and collects information about time consumed by service layer. An appropriate response is then passed to JMX layer. This invocation sequence is illustrated in Figure 4.

invocation-sequence

Figure 4: Components call sequence

This post takes into account high level consideration of a technical infrastructure. The complete source code is available in [1] resource. The Figure 5 gives an overview of components structure.

In order to compile sources invoke following command:

mvn clean install

on command line from com.softexploration.lab.ejb.performance.monitoring.local.suite.build and com.softexploration.lab.ejb.performance.monitoring.remote.suite.build locations.

After that, the compiled applications are placed in locations:

com.softexploration.lab.ejb.performance.monitoring.local.suite/target /com.softexploration.lab.ejb.performance.monitoring.local.suite-0.0.1-SNAPSHOT.ear

and

com.softexploration.lab.ejb.performance.monitoring.remote.suite/target /com.softexploration.lab.ejb.performance.monitoring.remote.suite-0.0.1-SNAPSHOT.ear

architecture

Figure 5: Application components structure

4. Connecting to application suites

The assumption at the moment is to have a properly configured WebLogic environment with a deployed Java EE application suites. WebLogic configuration meeting these requirements is described in the separate article Oracle WebLogic Managed Servers Configuration [1].

Connecting to Java EE suites using JConsole

In order to start JConsole do the following:

On a command line execute:

jconsole -J-Djava.class.path=%JAVA_HOME%/lib/jconsole.jar;%JAVA_HOME%/lib/tools.jar;%WL_HOME%/server/lib/wljmxclient.jar -J-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote –debug

This example works on Microsoft Windows OS. Use proper $JAVA_HOME and $WL_HOME variables on Unix systems.

In order to make connection to monitoring module do the following:

1. Open on JConsole new connection wizard

2. Select Remote Process and enter URL (Figure 6):

service:jmx:rmi:///jndi/iiop://<host>:<port>/weblogic.management.mbeanservers.runtime
where
<host> refers to hostname on which is running monitoring module
<post> is a managed server’s listening port

We need to make two connections to the two monitoring modules – com.softexploration.lab.ejb.performance.monitoring.local.suite and com.softexploration.lab.ejb.performance.monitoring.remote.suite.

For example:
service:jmx:rmi:///jndi/iiop://localhost:7015/weblogic.management.mbeanservers.runtime
and
service:jmx:rmi:///jndi/iiop://localhost:7016/weblogic.management.mbeanservers.runtime

newconn-wizard

Figure 6: New JMX remote connection

3. Provide WebLogic credentials and connect

mbeans

Figure 7: MBeans monitoring

After establishing connection to a suite navigate to MBeans tab on JConsole and then locate manageable bean in the com.softexploration.lab.ejb.performance.monitoring node (see Figure 7). There are available executeNopServiceLoadTest, executeSimpleServiceLoadTest and executeComplexServiceLoadTest methods taking one parameter which expresses a number of business service invocations.

Summary

This post provides a quick guide through a technical infrastructure for EJB performance tests. I encourage to download application sources [1], elaborate them, compile and deploy on WebLogic or other JEE 6 compliant server. The tests execution is provided in the next part - Local and remote EJB performance comparison – PART II [2].

References

[1] Oracle WebLogic Managed Servers Configuration

[2] Local and remote EJB performance comparison – PART II

Resources

[1] Java EE application sources

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>