A
Oracle9iAS 1.0.2.x and WebLogic Server 6.0 Comparison
This appendix provides a comparison of performance and features between Oracle9iAS version 1.0.2.2.x and BEA Systems' WebLogic Server 6.0. (Oracle9iAS 1.0.2.2 is the predecessor Oracle9iAS 9.0.2.)
This chapter is organized as follows:
Introduction
In response to Oracle's delivery of a 100% J2EE 1.2 standards compliant J2EE container in Oracle9iAS 1.0.2.2, which is both feature-rich and highly optimized for Java execution, the primary competitors in the application server market have responded with several claims to both feature and performance differentiation to Oracle9iAS.
To provide Oracle's customers with a fair and accurate representation of the actual facts when comparing Oracle9iAS 1.0.2.2 against the most recent release of WebLogic Server 6.0, this chapter provides the specific details comparing Oracle9iAS' J2EE facilities with this product.
This chapter is structured in two parts:
- Performance Results--This chapter first explains in specific detail: (i) the objective performance comparison's that Oracle conducted against WebLogic Server 6.0; and also (ii) explains the specific reasons for the comparative performance differences between the two products.
- Feature/Function Comparison--This chapter also explains in specific detail the relative capabilities of Oracle9iAS against WebLogic Server.
The objectives of this chapter are to provide Oracle's customers and potential application server customers with a clear and objective analysis of the capabilities of Oracle9iAS' J2EE facilities.
Performance Results and Analysis
In order to compare the relative performance of Oracle9iAS 1.0.2.2's J2EE container vs WebLogic Server 6.0, Oracle ran a formalized benchmark test comparing various aspects of the performance of the Oracle9iAS J2EE container against WebLogic Server 6.0 (the production version available at the time of our benchmarking effort). The goals were to measure the comparative performance of the J2EE containers of the two application servers along the following objective set of guidelines:
- Real World Benchmark--First, the goal of our benchmarking exercise was to run a J2EE application that represented a real-world application and would execute all aspects of the J2EE container rather than one that either did not represent a real-world application or one that only tested aspects of the J2EE container that were favorable to Oracle.
- Identical Hardware Configurations--Second, the benchmarking exercise was conducted on identical hardware configurations, for example, the same operating systems and hardware platforms, to ensure that the results represented an objective comparison of the two products.
- Identical Software Configurations--Third, to ensure fairness, the benchmarking exercise was also conducted on identical software configurations. There were four aspects to such identical software configurations:
- Web Caching--Web caching was not used to enhance the performance of Oracle9iAS results. While the web cache is a specific capability of Oracle9iAS, and when used by customers could provide further performance acceleration compared to BEA, the initial focus of the performance tests were to provide specific comparisons on the J2EE containers in these products alone. As a result, to ensure a fair comparison of the results, no web caching was used with Oracle9iAS.
- JDK, JRE, and Operating System Versions--The same JDK and JRE versions and the same operating system were used in both cases. Since the more recent JDK versions have much faster JIT compilers and other optimizations of the Java runtime, these in turn would impact overall J2EE performance measurements. Again, in the interest of a fair comparison of the results, the same versions were used to measure the performance of both containers.
- Web Server Configurations--Finally, the same web server configuration was used in both cases to ensure that measured performance differences reflected J2EE container performance alone and also reflected real-world customer deployments. Specifically, Oracle9iAS provides, as part of its J2EE container, an extremely fast and optimized web server which has a number of optimizations for extremely efficient HTTP streaming and input/output. Further, this web server can be run in process with the servlet engine and EJB container and, as a result, for benchmarking purposes, could provide a big performance difference when compared to BEA which embeds a much slower web server. Since the performance tests were focused on measuring J2EE container performance, we did not use the Oracle9iAS embedded web server but chose to use Apache, forwarding requests via a proxy architecture to both J2EE containers. This not only isolates the differences in J2EE container performance but also reflects typical customer situations where customers already have existing web servers deployed on a separate tier from their J2EE containers.
- Performance and Scalability Comparisons--Fourth, the benchmarking exercise was also designed to measure both performance and scalability of the vendors' J2EE containers.
- Performance results were measured on the basis of average response time under specific user or transaction loads.
- Scalability was measured on the basis of total CPU utilization to support a specific user or transaction load on identical hardware. The system that uses the smallest amount of CPU to support a specific number of users can support more users on the same hardware configuration and, as a result, scales best.
The results of the performance and scalability comparisons are as documented below.
Performance and Scalability Results
Although the characteristics of the individual tests varied, Oracle9iAS demonstrated superior performance to WebLogic Server in all tests. We stopped the tests at the point where the application server's average response time was increasing exponentially, but all indications suggest that Oracle9iAS can be scaled to much higher user loads and configurations. On average, Oracle9iAS performance (based on response times) was 2-5 times better than WebLogic Server. On average, Oracle9iAS demonstrated much superior scalability (based on CPU utilization) compared to WebLogic Server. CPU utilization was about 2 times less than WebLogic Server. Even at lower user loads, Oracle9iAS used significantly less hardware resources than WebLogic Server.
Feature Comparison
The section above clearly documents the relative performance and scalability differences of Oracle9iAS' J2EE container with WebLogic Server. The results showed that the Oracle9iAS' J2EE container yielded better performance and used less CPU and memory than WebLogic Server on all the tests. In response to these benchmark results, BEA falsely claims that Oracle9iAS' J2EE container lacks several features. To address these concerns, this section specifically examines the J2EE features in Oracle9iAS against WebLogic Server.
Installation and Configuration
BEA has claimed that Oracle9iAS has a very heavyweight disk and memory footprint and is, as a result, difficult to install and configure. In doing so, they falsely compare the relative disk and memory requirements for their J2EE containers with the requirements for all of Oracle9iAS, which includes a directory server, an enterprise portal, a cache, business intelligence, and several other capabilities. Their comparisons are not accurate. Accurate comparisons are shown in Table 6-2.
Table 6-2 Disk and Minimum Memory Configurations for J2EE Containers
To address these claims, we compare the disk and memory requirements for Oracle9iAS J2EE container with those of WebLogic Server - the requirements for WebLogic Server are taken from BEA's product documentation. The facts highlight these important results:
- 1/3 Disk Footprint--Oracle9iAS has the smallest download footprint and requires just 1/3 the disk space of WebLogic Server 6.0.
- 1/12 Minimum Memory Footprint--The memory footprint that was measured was the recommended memory configuration required to start-up the JDK, start-up an instance of the J2EE container, and run the standard Java Pet Store Demo application. Table 6-2 indicates that Oracle9iAS requires less than 1/12 the memory footprint of WebLogic Server 6.0.
- No Oracle Database Requirement--Additionally, BEA claims that it is necessary to install and configure an Oracle database in order to run J2EE applications. This is also false. Specifically, Oracle9iAS' J2EE container can be installed and configured with no Oracle database dependency. All the configuration information is captured in simple XML files and the JNDI namespace is captured in the file system.
- No Oracle Java VM Requirement--Additionally, Oracle9iAS' J2EE container has no dependency on Oracle's Java Virtual Machine. It has been certified on both JDK 1.2 and JDK 1.3, versions available on all six major operating systems including Windows, Linux, Solaris, HP-UX, AIX, and Compaq TRU-64.
- 20 Minutes Installation and Configuration Time--To specifically address these competitive considerations and to make it easy for J2EE application developers, Oracle provides a downloadable version of its web cache, Apache, and J2EE container as a single zip file. The entire product can be downloaded as a single zip file, requires one command to unzip, and a single command to start the J2EE container. The total time to install and configure all three components is 20 minutes. This is substantially faster and easier than WebLogic Server 6.0.
Performance and Scalability
Having considered the relative ease of installation and configuration, let us examine the fundamental reasons for the performance and scalability differences between Oracle9iAS and WebLogic Server. There are a number of reasons that drive the measured performance differences that were documented in the previous section.
- More Efficient Code Path and Optimizations--There are three points to consider:
- 2-3X More Optimized Code Path--First, Oracle9iAS has a highly optimized J2EE container which has a roughly 2-3X more efficient code path with a much smaller instruction count than WebLogic Server 6.0.
- Optimizations for In-Process Deployments--Additionally, Oracle9iAS' J2EE container has even better optimization for the typical deployment configurations when JSPs, servlets, and EJBs are co-located in the same Java Virtual Machine. For instance, unlike WebLogic Server, Oracle9iAS uses very optimized in-process calling mechanisms which avoid doing costly RMI calls when calling between co-located JSPs, servlets, and EJBs.
- Very Efficient Byte Array Operations--Finally, Java developers know that Java String operations are extremely expensive and slow to execute on even the latest versions of the JDK Virtual Machine. To avoid using such costly operations, Oracle9iAS' J2EE container was designed from the ground-up to use byte-array operations without using Java Strings. This is a significant performance advantage which would require significant re-architecture by BEA to duplicate.
- More Efficient Network Protocol--Additionally, Oracle9iAS uses a much more efficient network protocol than WebLogic Server to call between Java applications.
- Very Efficient RMI Dispatch--Oracle9iAS' J2EE container uses a very highly optimized RMI dispatcher that has been optimized for calling between J2EE applications. Oracle9iAS does not use a CORBA infrastructure to route calls between J2EE applications which introduces protocol overhead when tunneling RMI through IIOP for instance. Oracle will continue to offer a highly optimized RMI protocol for performance reasons even when we comply with EJB 2.0/J2EE 1.3 which requires RMI-over-IIOP.
- More Efficient Database Access--Oracle9iAS also uses a very efficient mechanism to schedule transactions between the middle tier application server and the database. For instance, Oracle9iAS can prepare and cache both a single SQL statement and multiple SQL statements across a JDBC connection pool. This ensures that Oracle9iAS is highly optimized when it dispatches transactions to both Oracle and non-Oracle databases and significantly improves database access performance.
- More Efficient Container Managed Persistence--There are two specific facts that reflect the significant performance advantages in using Oracle9iAS' Container Managed Persistence (CMP) implementation compared to WebLogic Server's implementation:
- Auto-Detection of Modified EJBs--When using CMP, Oracle9iAS' J2EE container can automatically detect whether you have modified an EJB and writes the EJB's state to the database, for example, does an
ejbStore only when necessary. WebLogic Server does not provide such auto-detection requiring a user to code is-modified methods which the WebLogic Server container uses to know whether or not to do the ejbStore operation. Note that this problem may be addressed with the coming WebLogic Server EJB 2.0 implementation.
- Simple and Complex DB mapping for CMP--When using CMP, Oracle9iAS' J2EE container supports both simple (1:1, 1:many) and complex (many:many) database field mappings very efficiently. In contrast, WebLogic Server provides very poor support for even some simple CMP database field mapping (1:many) in its CMP EJB 1.1 xml files. For instance, it is difficult to qualify a
where clause string in WebLogic Server and this results in doing unnecessary full table scans.
- Fast and Predictable Steady State Performance--Further, when comparing the performance of J2EE applications, the time to execute the first request/transaction with WebLogic Server when several JSPs, servlets, or EJBs are created, takes several minutes because the container takes a long time to load the first J2EE objects and does so in an as necessary fashion. Oracle9iAS does not have a similar problem. Note that in the interests of fairness in carrying out the performance comparisons, we increased the test ramp-up time to get WebLogic Server's performance to predictable steady-state.
- Simpler to Configure for Scalability--Finally, to configure Oracle9iAS for scalability requires very minimal tuning when compared to WebLogic Server. Oracle9iAS does not require the developer to configure operating system, Java Virtual Machine, network, or thread parameters for scalability. In contrast, WebLogic Server, for instance, has a "number of threads" parameter which is difficult to tune, and can limit scalability. The recommended default is 15 threads for a WebLogic Server. This parameter limits the number of concurrent users. You can tune the parameter to increase it, but it will have different effects on performance at different user loads. For example, for one of our test workloads, increasing this to 30 significantly improved performance for the 1000 user test, but made the 500 user test worse. Since in a real production environment you can't really adjust this thread count as the load changes, it is difficult to use this parameter for tuning. If left at 15, as the BEA documentation generally suggests, it can limit concurrency and scalability to fewer than 100 concurrent users. Note that Apache JServ has a "number of threads" parameter, but setting it higher than the required concurrency didn't cause the same type of degradation we saw in WebLogic Server.
J2EE Container Features
Table 6-2 lists the J2EE features of a J2EE container and the implementation currently supported by Oracle and BEA.
Table 6-3 J2EE Features of J2EE Containers
Clustering Support
Application server clustering (not to be confused with database clustering) essentially means the use of a group of application servers that coordinate their actions in order to provide scalable, highly-available services in a transparent manner. There are three requirements here:
- Heterogeneous Clusters--Unlike the database, where every node of a cluster has an identical configuration, in the middle tier, it is important to allow users to configure a set of boxes which may have heterogeneous operating systems, hardware, and other systems infrastructure to belong to a cluster. Further, application server clusters cannot use a shared disk architecture for clustering due to the large number of middle tier instances and to the fact that web masters typically use local disks attached to application server boxes rather than more expensive shared disk arrays. Oracle9iAS and WebLogic Server support heterogeneous clusters using an IP-multicast based architecture for scalability.
- Stateless Clustering--Clustering different application server instances together to service stateless requests is straightforward. Since the requests are stateless, an external load balancer can simply direct a request to a new Oracle9iAS instance either on the same node or on a different node.
- Stateful Clustering--The far more difficult problem is to address how you cluster systems together when the requests are stateful. For instance, an e-commerce servlet is making use of the
HTTPSession object to save the state of a shopping cart between method requests. When the client adds another item to the shopping cart, the servlet servicing the original request may not be accessible either because the load on that instance is too high or because the instance is not available (for example, the instance has failed). In this case, the request needs to be redirected to a different J2EE container to which the HTTPSession object's state has been replicated from the first container.
From a comparative point of view, Oracle9iAS' J2EE container provides the following facilities:
- Servlet Clustering--Oracle9iAS provides facilities to cluster servlets without requiring any changes to the user's application. The changes are deployment configuration modifications which are transparent to the J2EE application.
- Clustering Architecture and Simplicity: An important differentiator for Oracle9iAS' J2EE container is the ease with which different instances can be clustered and the robustness of the architecture used for clustering.
- Clustering Simplicity--Specifically, Oracle9iAS requires a user to edit a single XML file to configure various Oracle9iAS instances to belong to a single cluster/island whether they are multiple servers with load balancing on a single machine or multiple servers with load balancing on different machines. In contrast, it is much more complex to configure WebLogic Server clusters with load balancing either with multiple instances on one machine or on multiple machines.
- Superior Clustering Architecture--Oracle9iAS' J2EE container uses dynamic IP addresses to register instances as belonging to a cluster. Its built-in load balancer or any standard load balancer, such as Cisco Local Director or BigIP, has the ability to use a variety of load balancing algorithms to route requests to different instances. In contrast, WebLogic Server uses static IP addresses to configure clustering. Static addresses preclude the use of a load balancer to distribute requests across instances. As a result, with WebLogic Server 6.0 you get either clustering or load balancing but not both.
- Stateless Session Bean Clustering--Oracle9iAS supports clustering of stateless session beans.
- Stateful Session Bean and Entity Bean Clustering--Oracle9iAS 1.0.2.2 does not provide clustering of stateful session beans and entity beans. We will be bringing such functionality to market with an upcoming release. There are two important considerations that we are working on:
- Clustered Performance--Existing clustering facilities such as those in WebLogic Server 6.0 impose a severe performance penalty when running the instances in a stateful fashion with clustering. As a result, most users choose to keep their middle tier completely stateless and write their state to a persistent store, for example, a database. In delivering clustered EJBs, Oracle is working on optimizing the EJB clustering implementation to avoid introducing performance penalties.
- Programmatic Simplicity--Additionally, unlike servlets which have a natural session boundary at which to failover their state, EJBs do not have such a clear boundary. As a result, we are working on simple programmatic facilities to allow users to use EJB clustering without any changes to their applications.
- Transparent Application Failover with J2EE Applications--Finally, when Oracle9iAS' J2EE container writes state to the Oracle database, Oracle9iAS provides facilities to fail over JDBC connections to provide transparent application failover (TAF) across nodes of the Oracle database. With EJBs, this allows a user to maintain a stateless middle tier by writing the state to the database and full state recoverability should a database node have a failure. WebLogic Server 6.0 does not provide this capability. Only BEA Tuxedo provides this capability, but it is not certified with Oracle9i.
Sample Migration Case Study
This section describes in detail the steps used to migrate an application from WebLogic Server 6.0 to Oracle9iAS 1.0.2.2.1.
Migration was done on a Windows 2000 system with OC4J connected to an Oracle 8.1.7 database and JDK 1.3.1 as runtime environment for OC4J.
- Classpath and Libraries. As several commonly used classes, including apache SOAP 2.2 had to be accessible we created the following startup script to set the appropriate environment.
>d:
>cd \oracle\oc4jv1\j2ee\home
>set java_home=d:\jdk1.3
>set path=d:\jdk1.3\bin;%path%
>set CLASSPATH=D:\oracle\oc4jv1\j2ee\home\orion.jar;
D:\OrderServerNew\OrderServer.jar;D:\OrderServerNew\DataItemCore.jar;
D:\OrderServerInstall\OrderServerJars\jdom.jar;
D:\OrderServerInstall\OrderServerJars\activation.jar;
D:\OrderServerInstall\OrderServerJars\imap.jar;
D:\OrderServerInstall\OrderServerJars\mail.jar;
D:\OrderServerInstall\OrderServerJars\mailapi.jar;
D:\OrderServerInstall\OrderServerJars\pop3.jar;
D:\OrderServerInstall\OrderServerJars\smtp.jar;
D:\OrderServerInstall\OrderServerJars\soap.jar;
D:\OrderServerNew\Performance.jar
>java -hotspot -Xss128k -ms128m -mx128m -cp %CLASSPATH%
-Dplot.home=D:\OrderServerNew\OC4JRepository
-Dplot.orderserver.url=ormi://localhost:23791
-Dplot.orderserver.factory=com.evermind.server.rmi.RMIInitialContextFactory
-Dplot.orderserver.principal=admin -Dplot.orderserver.credential=admin
-Dplot.orderserver.EJBAppName=OrderServer
com.evermind.server.ApplicationServer -verbosity 10
Doing benchmarks we discovered that there are several problems when including another XML parser (xerces.jar) in the classpath. Development also recommends to start OC4J with java -jar -orion.jar (so the manifest file in the orion.jar is used). It can slow down OC4J to 50% of it's normal performance. So, if the application, e.g. Apache SOAP, needs an XML parser, then include it in the WEB-INF\lib directory and change the entry in the web.xml file for the XML-Parser as follows.
<init-param>
<param-name>XMLParser</param-name>
<param-value>org.apache.crimson.jaxp.DocumentBuilderFactoryImpl
</param-value>
</init-param>
We tried the crimson parser and it worked faster than xerces.
The second thing we discovered doing benchmarks with WebLogic Server 6.0 which uses its internal JDK1.3.0 and OC4J using JDK1.3.1 was that the java -server option gives very bad performance for OC4J.
Using java -hotspot instead, WebLogic Server had 2 times better performance for looping through a large JDBC result set. OC4J had 4 times better performance with the same operation.
- Automatic invocation of a class at server startup, WebLogic Server 6.0 has a parameter
weblogic.system.startupClass.initialise=<class-name> that enables automatic initialization of environment constants and services at startup.
To get similar behaviour in OC4J we created an startup application as java enterprise client, put it in an .ear and set two parameters in the config files.
server.xml:
<application name="Startup" parent="OrderServer"
path="../applications/startup.ear" auto-start="true" />
application.xml for Startup.ear
<application>
<display-name>StartupSettings</display-name>
<module>
<java>Start.jar</java>
</module>
</application>
Example of a startup class:
import my.util.StartupHelper;
public class OracleASStartupClient {
private static void startup() {
StartupHelper.setConstantswithProperties();
StartupHelper.cacheSettings();
StartupHelper.installClientInteface();
StartupHelper.installLogging();
}
public static String startBatch (String name, Hashtable args) throws
Exception {
Object obj = Class.forName(name).getConstructor(
new Class[]{Class.forName("java.util.Hashtable")}).newInstance(
new Object[]{args});
if (obj instanceof Thread) {
((Thread)obj).start();
}
else throw new Exception("Class to start must be of Type Thread");
// Write your startup code here...
return "BatchStarter Successfully completed.";
}
public static void main(String[] args) {
System.out.println("***** STARTUP begin ********************");
startup();
/* try {
startBatch("my.orderserver.batch.MessagePersisterBatch",
new Hashtable());
catch(Exception e) {
e.printStackTrace();*/
System.out.println("******* STARTUP end *********************");
return;
}
}
- Adapt application from WebLogic Server global JNDI context to OC4J specific context. The JNDI tree in WebLogic Server enables each enterprise application to see all other ear's methods. In OC4J, it is standards compliant, and therefore, we had to use the
parent-application parameter in server.xml (see 2 above). The following class was used to establish the JNDI context:
public static Context getInitialContext (boolean security) throws
Exception {
Hashtable env= new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,Constants.OS_FACTORY);
env.put(Context.PROVIDER_URL, Constants.ORDERSERVER_URL);
if(security) {
env.put(Context.SECURITY_PRINCIPAL,
Constants.ORDERSERVER_PRINCIPAL);
env.put(Context.SECURITY_CREDENTIALS,
Constants.ORDERSERVER_CREDENTIAL);
try {
Context ctx = new InitialContext(env);
return ctx;
}
catch (Exception e) {
e.printStackTrace();
}
return new InitialContext();
}
- Enable call-by-reference for EJB methods. As the application was programmed to make use of call-by-reference for EJB method calls, we had to set this behaviour (default is call-by-value) in
orion-ejb-jar.xml.
orion-ejb-jar.xml for OrderServerGroup:
<?xml version="1.0"?>
<!DOCTYPE orion-ejb-jar PUBLIC "-//Evermind//DTD Enterprise JavaBeans 1.1
runtime//EN" "http://xmlns.oracle.com/ias/dtds/orion-ejb-jar.dtd">
<orion-ejb-jar deployment-version="1.0.2.2.1" deployment-time="eadf228126">
<enterprise-beans>
<session-deployment name="AblaufsteuerungBean"
location="AblaufsteuerungBean" wrapper=
"AblaufsteuerungHome_StatelessSessionHomeWrapper1" timeout="0"
persistence-filename="AblaufsteuerungBean" />
<session-deployment name="OrderService" copy-by-value=false
location="OrderService" wrapper=
"OrderServiceHome_StatelessSessionHomeWrapper3" timeout="0"
persistence-filename="OrderService" />
<session-deployment name="TransparentService"
location="TransparentService" wrapper=
"TransparentServiceHome_StatelessSessionHomeWrapper5" timeout="0"
persistence-filename="TransparentService" />
</enterprise-beans>
<assembly-descriptor>
<default-method-access>
<security-role-mapping name="<default-ejb-caller-role>"
impliesAll="true" />
</default-method-access>
</assembly-descriptor>
</orion-ejb-jar>
- Enable connection pooling with OC4J. We used the same Oracle JDBC 2.0 drivers
classes12.jar for WebLogic Server and Oracle9iAS. To enable connection pooling, we had to switch off MTS on Oracle 8.1.7. We used the ejb-location in the following data-sources.xml config file:
<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="OrderServerDS"
location="myOrderServerDS"
pooled-location="pooledOrderServerDS"
xa-location="jdbc/xa/OrderServerXADS"
ejb-location="OrderServerDS"
connection-driver="oracle.jdbc.driver.OracleDriver"
username="plot"
password="plot"
url="jdbc:oracle:thin:@localhost:1529:o8i"
inactivity-timeout="3600"
min-connections="20"
max-connections="100"
/>
- Transaction timeout for EJB's. During benchmarking, we discovered in some tests that the EJB container ran into a time-out and rolled back transactions. To fix that, we set the
timeout parameter in orion-ejb-jar.xml to zero (no time-outs).
<enterprise-beans>
<session-deployment name="TransparentService"
location="TransparentService"
wrapper="TransparentServiceHome_StatelessSessionHomeWrapper5" timeout="0"
persistence-filename="TransparentService"
/>
</enterprise-beans>
