Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective

ballooncadgeInternet and Web Development

Oct 31, 2013 (4 years and 6 months ago)


An Oracle White Paper
September 2009

Oracle WebLogic Suite ActiveCache and
Increasing ROI: A Technical Perspective
Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective

Executive Summary............................................................................1
Get More from Your Oracle WebLogic Investment.............................3
Unique Considerations for Java..........................................................8
Effect of HTTP Session Storage.......................................................10
Splitting the Application Server Tier in Two......................................11
Scale Out..........................................................................................13
Real World Results...........................................................................14
Standard Application Server Clustering and Session Replication.15
Session Replication with ActiveCache..........................................16
ActiveCache Scale Out and Session Replication Combined........16
Calculating the Business Value of Increased Efficiency...................17
Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective
Executive Summary

Over the last few years, most enterprises have come to realize the increasingly
higher costs of acquiring, housing, powering, cooling, managing and maintaining
large-scale and mission critical systems. In keeping pace with technical and
business needs of our customers, Oracle has introduced Oracle WebLogic Suite, our
most powerful, flexible and full-featured application server offering to date. In
addition to Oracle WebLogic Server, Oracle WebLogic Suite includes several best-of-
breed technologies that together increase reliability, availability, scalability,
performance and resource efficiency of enterprise applications far beyond what was
possible even a few years ago using classical three tier deployment architectures
and stand-alone application servers.
Thousands of large enterprises have successfully employed Oracle WebLogic Server
in their most demanding environments for many years and continue to be very
satisfied. There are many Oracle WebLogic Server deployments, however, that
could be optimized to use far fewer resources per supported user. By deploying
Oracle Coherence and employing a set of Oracle WebLogic Server features
collectively known as ActiveCache, Java EE applications can make much better use
of modern, multi-core processors, high speed networking and large memory server.
This increased efficiency in turn reduces the number of physical servers required to
support a given number of users and therefore power, cooling, facilities,
administrative and per-CPU software license costs as well. For customers with
Oracle WebLogic Server clusters deployed, it is possible to employ ActiveCache
without any applications changes, acquiring new hardware or even upgrading to a
new release of Oracle WebLogic Server. In many cases, the cost savings are
greater than the costs of continuing with current deployments even within the first 12
months of the upgrade to Oracle WebLogic Suite.
In one prime example, which is explored later in this document, the use of
ActiveCache increased the supported workload of the application in question by
291% without the addition of any new hardware or substantial modification of the
application code. The effect of this gain is a reduction of the approximate number of
required physical servers from 30 to 10. For a typical North American datacenter,
the costs for server hardware, datacenter facilities, power, cooling and administration
would be reduced from approximately $150,000.00 to $50,000.00 in the first year.
When software license costs are added based on list prices at the time this
document was produced, the savings from Oracle WebLogic Suite in the first year
alone is more than $1.3M.
Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective

The term “performance” is often used by marketers when describing software
products. The most common interpretation of the term “performance” is analogous to
the notion of “speed”. While the benefits of systems may seem intuitively obvious, it
is notably difficult to accurately quantify the business benefit of this abstract
characteristic. Once a basic threshold of responsiveness or throughput has been
achieved, the notion of performance takes on a different emphasis. To put this
discussion in the context of a cost/benefit analysis, it is sometimes more appropriate
think of performance in terms of resource efficiency. With this perspective in mind it
is quite straightforward to then quantify the costs of owning and operating an
enterprise application or system and determine how those costs are affected by
software design and architecture choices. It is reasonable to generalize that best
choice, when selecting a software product, architecture or design approach, is the
one that generates the most value from available resources without incurring
unacceptable levels of risk.
For most enterprise applications there are several well-known elements of any cost
model which produces a view of the Total Cost of Ownership (TCO). These typically
include the costs for datacenter facilities and networking, power and cooling,
administration and physical server purchases or leases. In addition to these
infrastructure costs, software licenses are often tied to specific server hardware
attributes like the number of processor sockets supported (CPUs), the number of
cores per socket and the architecture of the CPU. From a business efficiency
standpoint, any system that does not maximize utilization of these (relatively) fixed
costs produces a sub-optimal Return on Investment (ROI). This basic observation
has driven recent industry-wide focus on technologies and approaches like power-
efficient computing platform architectures, large-scale liquid cooling systems,
virtualization and cloud computing.
This paper focuses on a few key features of Oracle WebLogic Suite that Oracle has
dubbed collectively “ActiveCache”. ActiveCache is an integration of the Java EE
programming model (and Oracle WebLogic Server) with a distributed, shared-
memory architecture supported by Oracle Coherence. ActiveCache uses Oracle
Coherence as a highly efficient, distributed, in-memory infrastructure surfaced in
Oracle WebLogic Server via standard Java EE APIs, specifically the HTTP Servlet
API and the Java Persistence API (EJB 3.0).

Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective
Get More from Your Oracle WebLogic Investment

Every application, either explicitly or implicitly, is able to function properly and deliver
value to the enterprise as long as a few key performance indicators remain within
appropriate operating ranges. For example, most users will accept a slight delay in
the response to some action, whether it is clicking an on-screen button or hitting the
return key. When an application fails to be adequately responsive, from the
perspective of the end user, the user would consider this a performance-related
failure. There is much more to the issue of performance than responsiveness,
however. With the adoption of the right architecture and technology it is possible to
not only improve the responsiveness of applications, but also reduce the physical
server hardware required and other linked costs as well.
In order to discuss how software design and architecture choices can directly affect
ownership costs, we need a few key performance indicators (KPI) and concepts that
can be applied to our evaluation of efficiency: latency, throughput and concurrency.

Latency is the time taken for a system to return a result after input has been
provided. In the case of a Web application, this would be a measure of the time
required for an application to send a response to a request: “response time”.
Latency is a measure that can often be directly experienced by a user as
responsiveness to user interaction, whether it’s snappy or sluggish. This is what
many people think of when discussing performance. In other cases, as in real-time
applications, latency often determines whether transactions complete (within strict
time limits) or fail. For any given application there is an acceptable latency value,
whether it is a number of microseconds, seconds or minutes. When determining
what workload a given system can support we need to determine what percentage of
requests may exceed this latency value (fail) before we consider the system to be in
a fault condition.

Throughput is a reflection of the rate at which a system receives new requests and
returns responses. Peak throughput is the maximum rate at which new requests
may be both received by the system and responses returned. As the rate of
requests increases, the ratio of requests to responses will eventually diverge from
1:1. At this point of divergence, the system has become overloaded and cannot
sustain this throughput indefinitely. In most computing systems there is a
Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective
relationship between latency and throughput: latency usually increases as the rate
with which requests are received also increases, although this is rarely a linear
relationship. If the application imposes latency limits on the processing of any given
request (either by strict time limits on certain operations or by an estimation of an end
user’s ability to tolerate slow responses) the system may have a capacity for work
that is significantly lower than the peak throughput. If we create a graph of the
number of latency-related failures the system experiences as throughput increases,
we will have a view the “latency distribution” for the system.

Implicit in the notions of latency and throughput is “concurrency”. Concurrency refers
to the number of separate tasks that may be handled by the system at one time.
Simply put, it is possible to write software, which breaks complex tasks down into
sub-tasks that can then be distributed across a number of workers within the system
where they are executed simultaneously, in execution environments that are
optimized for the particular type of work required. By using the techniques and
applying the patterns of parallelism, developers are able create software which can
simultaneously exhibit a high degree of fault tolerance, determinism and efficiently
use computing resources. Parallelism is fundamentally important, as it is the basis
for maximally benefiting from the ready availability of low cost, 64-bit, multi-core CPU
architectures and extremely powerful, off-the-shelf networking technology. When
software systems are well designed, it is possible to use techniques of parallel
computing to increase the throughput of a system while maintaining the latency of
the system within acceptable levels.
Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective
Quantifying Resource Efficiency

When trying to determine the ability of a computing system to perform any particular
amount of work, we need to consider the percentage of requests that must be
successfully executed within the required time limit for the application in question.
For example, it may be determined that 95% of all requests for a Web page must be
answered with a correct (properly created) response within one second. “One
second at the 95
percentile” would then be considered the maximum acceptable
latency for the system.
In the case of
Figure 1
Figure 2
Figure 3
(below), the solid line being graphed
represents a set of test results for a system that shows its latency distribution. In this
set of example graphs, the solid line represents the number of requests received per
second. The line is interpolated from a series of tests in which the rate at which
requests were received by the System Under Test (SUT) has been increased
incrementally. At each increment, the latency of 95% of the requests processed has
been plotted. The resulting graph then illustrates the trend for 95
percentile latency
for the system as throughput increases. The system’s throughput at or below the
threshold for acceptable latency is its “supported workload”. In the case of
Figure 2

Figure 3
, the further to the right the supported workload value is, the greater the
efficiency of the system being tested.

Figure 1 - 95
Percentile Latency Distribution (No supported workload)

Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective
Figure 1
illustrates a system that is not capable of supporting any workload at all. In
this case, the system cannot meet the minimum requirements for usability because
even at the lowest throughput, the latency for responses to requests is above the
threshold for maximum acceptable latency. If this were a Web application, for
example, this might reflect “lag” that is so severe that users of the system consider it
non-responsive. Bottlenecks of this sort are often the result of contention for
resources, such as I/O performance (network, database or external resources) and
the lack of available heap and/or threads for processing requests.

Figure 2 - 95
Percentile Latency Distribution (Not very good)

Figure 2
illustrates a system that is capable of supporting a small workload. In this
case, it is possible that the users of the system may not experience any
“performance” issues at all. The cost of the work being done by the system,
however, is much higher than necessary. This is a very common circumstance and
is typical of many enterprise applications currently in production deployments..

Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective

Figure 3 – 95
Percentile Latency Distribution (Much Better)

Figure 3
, the system is demonstrating a higher average latency than the one
represented in
Figure 2
, but the impact of increased throughput on latency is much
less, reflecting a system that is much more capable of parallelizing work. As a result,
the system depicted in
Figure 3
offers several times more capacity for work than the
system being depicted by
Figure 2
While it is possible, in many systems, to increase the supported workload by simply
adding more hardware resources to the system, this is a costly solution to the
problem. It is possible, through relatively simple changes to the design of
applications and the deployment model for the system, however, to achieve
substantial improvements in resource efficiency without changes to hardware (or
even to application code, in many cases). This is obviously the preferred approach
wherever possible.

Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective
Unique Considerations for Java

The Java language has been a remarkable success for developing enterprise
software. While Java is no longer considered a new technology, it has continued to
evolve and improve. Where Java was initially known for limitations in performing
basic computation, I/O, and other common functions, the majority of these issues
have been overcome. Java is now regarded as a true peer to C, C++, and other
technologies that have longstanding reputations as the choice for highly reliable,
high-performance software systems.
There are, however, a number of limitations that have persisted until very recently
and which, even today, are reflected in current generation software and large-scale
deployments. Much of the utility and usability of Java is a reflection of the abstraction
of physical computing resources provided by the Java Virtual Machine (JVM).
Modern JVM implementations like Oracle JRockit offer highly efficient Java SE run-
time environments and extensive diagnostic and profiling facilities.
Figure 4

illustrates the results of the standard industry benchmark, SPECjbb2005, for
measuring the performance of server side Java virtual machines.

Figure 4 – Oracle JRockit performance benchmark test results

Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective

Application servers such as Oracle WebLogic Server also employ many techniques
and optimizations at the Java layer and achieve outstanding benefits in sheer
computational power.
Figure 5
illustrates the results for a recent
SPECjAppServer2004 industry benchmark which measures the performance of Java
EE application server containers and relational databases.

Figure 5 – Oracle WebLogic Server 10.3 performance benchmark test results

Due to the fundamental nature of the language (memory managed and a byte code
interpreted) Java requires some special attention where it comes to raw resource
efficiency. JVMs, for example, provide a memory management facility that off-loads
complex and error-prone memory management tasks from developers. The JVM is
responsible for detecting that objects are no longer in use and for re-claiming
memory used by these objects; garbage collection. . To facilitate this, the JVM
allows applications to use a predetermined amount of dynamically allocated memory,
known as “heap”, in which to work. Because the cost of managing this memory
workspace tends to increase non-linearly as the size of the heap grows, it is common
for individual JVMs to address only a fraction of the physical memory available from
a given physical server. Additionally, as the size of the heap grows, the cost of
garbage collection may increase dramatically.
It is important to note that even before an application can be started, and with no
workload on the system at all, a significant amount of available heap will be
Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective
consumed. The Java classes which constitute the software, typically an application
server and one or more deployed applications, must be loaded in to heap before the
system can do work. A substantial amount of heap in each JVM is used storing
these classes. This system memory, therefore, is effectively “overhead” and should
be minimized to the extent possible.

Effect of HTTP Session Storage
From the above discussion, it is clear that heap usage is a significant determinant of
the performance of an individual Oracle WebLogic Server node. HTTP Sessions can
grow large in memory (often several megabytes), and the requirement to store them
on the heap is often the dominant factor limiting the number of concurrent sessions a
node can handle. Additionally as the size of the heap grows, the cost of garbage
collection can become a significant factor in latency.
For a JVM with one gigabyte of heap hosting a typical application server and
deployed applications, as much as one third may be dedicated to class loading. In
deployments which involve session replication, as much as a third (approximately
341 Megabytes) of heap is typically used for sessions before garbage collection
starts to meaningfully affect latency. When this occurs even though CPU utilization is
low (often only 10 to 20 percent) the systems condition is referred to as “memory
bound”. This is extremely common, particularly in mission critical application
deployments where session replication and in-memory state management is used
Before discussing a way to alleviate this problem, a short description of the lifecycle
of a Session is helpful. A session is created when a Servlet is first accessed from a
browser. A unique id for a session is generated, by the server, which is then used by
the client to identify the session in subsequent accesses. The session remains live
until it is either programmatically invalidated or it is invalidated by the server because
it has expired.
In the past, it was common for application servers to keep the session on the local
heap (in process) from its creation until it is invalidated even though it may only be
accessed during execution of the Servlet. This is, in fact, a very sub-optimal
approach in the majority of cases. It may optimize responsiveness (given that the
required session state is instantaneously available to the application) but at the
expense of any concern for resource efficiency. In some situations responsiveness
may in fact be diminished (versus the ActiveCache approach) if the added storage
Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective
requirements lead to increased garbage collection or the starvation of worker threads
used to process requests.

Splitting the Application Server Tier in Two

In the case of many classes of enterprise applications, important data (session state)
must be stored for relatively long periods between user accesses. For example, a
typical Web application may involve multiple interactions with a user during a
particular session. Session state is typically used to keep track of a user’s progress
through a workflow or store the results of an ad-hoc query, along with basic session
identifiers, authentication information and other descriptive protocol-level metadata.
This session state must be accessible by the application with very low latency,
although lower is not necessarily better. As discussed earlier in this document, it is
often acceptable to increase the average latency of responses so long as the latency
distribution results in an overall increase in supported workload.
Figure 6
shows standard Oracle WebLogic Server clustering, where application
sessions are and distributed between all of the Oracle WebLogic Server instances
within a cluster. This architecture can be contrasted with the Coherence-based
architecture shown in
Figure 7

Figure 6 – Standard WebLogic Clustering

Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective

It is possible (and generally advisable) to consider the value of serializing these long-
lived objects and transmitting them to an out-of-process data grid for storage until
they are needed, thus freeing application server JVM heap for use processing
requests and executing business logic. In cases where the effect of the loss of this
data is not material to the business, this is a very efficient approach that balances the
computational cost of deserialization against the more serious problems of a lack of
available memory for application execution. At this point, however, it is worthwhile
noting that the incremental cost of adding a fault tolerance to the system through
session replication is very often easily justified, given that this may be done
declaratively through configuration and results in a significant decrease in planned
and un-planned downtime.
In order to ensure that this session state (or any long-lived data object which could
be managed via ActiveCache) is not lost if any particular JVM instance fails or
becomes non-responsive, replication strategies are used. This replication involves
creating a transmittable “serialized” copy of the session state to another process
executing within a separate JVM. While this provides a solution to the critical
challenge of high reliability, the heap must be also be used for storage of these
serialized sessions.
A solution to this efficiency problem, however, is to create JVM instances which
execute software dedicated to management of this serialized state. Oracle
WebLogic Server, for example, can make use of Oracle Coherence for this purpose
through a feature called Coherence*Web, freeing Oracle WebLogic Server JVM heap
for request processing and execution of business logic. This results in an increase in
the supported workload of the system, not only because of the larger amount of heap
available for working space, but also because of the associated decreased cost of
garbage collection.
The JVMs in the system which host Oracle Coherence nodes (the “data grid”), by
way of comparison, are also able to optimally utilize resources in a number of ways.
Oracle Coherence*Web provides advanced features for segmenting large sessions
to enable more efficient access to individual attributes of sessions. Oracle Coherence
also provides additional optimized serialization formats which can greatly reduce the
amount of heap required for an object and the speed (CPU cost) of
serialization/deserialization. These include Portable Object Format (POF), and
‘extrernalizable lite’.
In a storage-only Coherence node, the Oracle WebLogic Server and application
classes (byte code and initialized objects) are not required, allowing for a larger
amount of heap being available for session storage. Additionally, since objects are
stored in binary form, there are improvements in garbage collection and the JVM can
Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective
be optimized for a “storage” rather than “processing” workload. A typical Coherence
node, for example, may allow as much as 800 Megabytes of a 1 GB JVM heap to be
used for data object storage while maintaining very low (<5-10ms) latency
By deploying a grid of Oracle Coherence nodes to provide a logical “State Tier”
which supports one or more stateless Oracle WebLogic Server instances, it is
possible to use available physical memory and processing resources more efficiently.
The State Tier is accessible to “Engine Tier nodes” via a high-performance, reliable
UDP-based protocol known as TCMP. State Tier nodes may be deployed on the
same physical servers as Engine Tier nodes or may be deployed elsewhere – the
only requirements regarding deployment topology are that the physical servers that
host State tier nodes have available RAM and CPU and are accessible to Engine
Tier nodes via standard Gigabit Ethernet (or better) networking. When Oracle
WebLogic Suite is deployed in this fashion, the resulting increase in the supported
workload of a given cluster of physical servers can be dramatic.

Figure 7 – Oracle WebLogic Suite Application Grid

Scale Out

Not all data needed by applications in the course of executing business logic is
transient or is associated with a particular user session. In many cases, applications
may create or access data which is transient but which reflects a lifecycle dictated by
Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective
an external system. Examples of this include everything from telemetry from remote
sensors to equities trading floors and multi-phase transactional exchanges with
mainframes or other systems. In other cases, the data being created or accessed by
the applications is logically persistent and is stored in relational databases. In both of
these cases, the latency incurred each time an application accesses the data
contributes to a decrease in the supported workload of the system. This is due in
large part to the limited number of tasks the system can execute concurrently.
Reducing this latency through the use of an Oracle Coherence grid as an in-memory
data store and/or as a cache for database queries and responses can greatly
increase the supported workload of the system by reducing this latency.
In the case of database access, for example, the majority of queries are often read
operations. Because of the nature of relational databases, scaling up (using more
powerful individual servers) as a means of lowering latency for queries can be
complex and costly. While it may seem counter-intuitive, dedicating under-utilized
system resources to managing this latency-sensitive data within a data grid allows us
to increase the overall supported workload of the system substantially.

Real World Results

To illustrate the cumulative benefits of applying application grid patterns for session
replication and scale out, it is helpful to look at actual results from tests performed in
a production-grade environment.
Figure 8 – Example Oracle WebLogic Suite
Performance Test Results
illustrates the different workloads supported by the
System Under Test (SUT) in each of three different configurations. In all cases the
server hardware, JVM, database and application are unchanged. Aside from the
license costs for Oracle WebLogic Suite, the cost of datacenter facilities, power
consumption, server hardware costs and database software license, support and
administration costs are unchanged.
Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective

Figure 8 – Example Oracle WebLogic Suite Performance Test Results

The servers are interconnected using common gigabit Ethernet. Gigabit Ethernet is
also used to connect the Oracle WebLogic nodes with a third physical server
dedicated to hosting an Oracle database and a standard load balancing appliance.
The “supported workload” is the maximum sustained number of requests per second
that the system is able to handle, within an acceptable latency range, without
becoming overloaded.

Standard Application Server Clustering and Session Replication
In the first scenario, the application is deployed to a standard Oracle WebLogic
Server cluster comprised of four Oracle WebLogic Server instances (JVMs) evenly
distributed between two physical servers. The set of technologies used corresponds
with the Oracle WebLogic Server Enterprise Edition license offered by Oracle. In this
case, no caching of database queries is performed and standard HTTP session
replication is used. In this scenario, the supported workload of the system is
approximately 240 requests per second. This system configuration is very common
and while it may not obviously suffer from any particular “performance” issues, it is
not particularly resource efficient.
Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective

Session Replication with ActiveCache
In the second scenario, a dedicated State Tier is introduced to store the replicated
session state. Oracle Coherence is installed on each Oracle WebLogic Server
instance to provide the client software needed to allow Oracle WebLogic Server to
communicate with the Coherence nodes that comprise this added State Tier. The
Oracle Coherence software executing within each Oracle WebLogic Server JVM also
provides an optimization called “near caching”, which allows the system to
transparently keep a small amount of data immediately available to the Oracle
WebLogic Server application to further reduce latency. The application continues to
use the standard HTTP session API provided by the Oracle WebLogic Server
container and no application code changes are required. In this scenario, the
supported workload of the system increases by approximately 50%, to 360 requests
per second. The test application, in these scenarios, does not create large or
complex session objects and no optimizations for splitting sessions or optimized
serialization are used. Applications that make extensive use of container-managed
sessions would experience an even more extensive benefit, in some cases doubling
or tripling the supported workload of the system, as has been the experience of many
customers of this technology that have deployed large scale systems.

ActiveCache Scale Out and Session Replication Combined
In the third scenario, minor changes (the addition of a few annotations) to the
application code are made which allow it to use the State Tier of the system to also
cache copies of database queries and result sets. In this scenario, standard EJB 3.0
is used via Oracle’s object-relational mapping and modeling technology called
TopLink Grid. With this feature, database access occurs only when no cached copy
of the needed data is already available in the State Tier data grid or when the
application performs an update, create or delete operation that must be persisted to
the database. This additional optimization results in a further increase in the
supported workload of the system, to approximately 700 requests per second. It is
likely that increasing the resources available to the database would have allowed the
system to support more requests per second, given that average CPU utilization
remained well below 100% and unused physical memory remained available.
In these example test results, a few minor changes to the configuration of the
deployed software and the addition of a dedicated State Tier using Oracle
Coherence have resulted in an increase in the supported workload of the system
from approximately 240 requests per second to approximately 700 requests per
second, an increase of 291%.
Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective
Because ActiveCache features are implemented using Oracle Coherence, a broad
range of supported application server products from different vendors can share a
common State Tier. This form of consolidation can yield even greater overall
efficiency by allowing applications with non-overlapping periods of peak use to share

Calculating the Business Value of Increased Efficiency
In the case of the example application test results discussed previously, the critical
question remains “how would these improvements in efficiency benefit my
To answer that, we’ll need to consider a basic cost analysis model. To keep the
model simple, we will only look at basic costs for datacenter facilities, power and
cooling and ongoing maintenance of each physical server. In a typical North
American datacenter using standard 2U rack-mount servers (dual socket, quad-core)
like those available from Sun, HP, Dell or IBM, the annualized cost per server is in
the range of $5000. There are many cases where these costs will be much higher.
For a deployment using standard Oracle WebLogic Server EE clustering distributed
across 30 physical servers, the annual cost for the aggregate workload supported
would therefore be approximately $150,000. Given the three-fold increase in
capacity observed in our example application, the same workload could be supported
by 10 physical servers at an annual cost of only $50,000, resulting in a $100,000
annual savings. Perhaps most significantly, however, the reduction in the number of
CPUs required has an effect on the software license and support costs as well. In
this case, if we were considering a new deployment at this scale and were comparing
these two options, the cost for the Oracle WebLogic EE deployment (at full list price
as of the time this paper was produced) would be $3.15M for the first year. The cost
for the Oracle WebLogic Suite deployment, however, would be $1.85M: a savings of
This estimated savings does not include the value of the numerous other benefits of
Oracle WebLogic Suite with ActiveCache, such as improved infrastructure agility,
reduced application down-time or improved application responsiveness (and
ultimately end-user satisfaction and productivity). In many cases, these difficult-to-
quantify benefits provide a return on investment that equals or exceeds the benefits
from increased application capacity articulated in this document.

Oracle White Paper— Oracle WebLogic Suite ActiveCache and Increasing ROI: A Technical Perspective


Performance is relevant to enterprises in terms of application usability
(responsiveness) but also, and perhaps most importantly, in terms of the efficiency
with which physical and financial resources are utilized to perform work. Even in
cases where existing Oracle WebLogic Server applications are considered to be
performing well, there is a strong likelihood that the addition of ActiveCache and the
many other related features of Oracle WebLogic Suite can bring significant cost
benefits with minimal disruption to existing applications. In many cases, ActiveCache
can be deployed with custom and pre-packaged 3
party Java EE applications
without requiring any application coding changes, making the rollout of more efficient
deployment architectures straightforward, minimizing risk. Oracle WebLogic Suite
and ActiveCache represent a great leap forward in enterprise application server
technology and should be among the first technologies considered when evaluating
the overall resource efficiency of any application deployment or datacenter
modernization project.

Oracle WebLogic Suite, ActiveCache and
Increasing ROI: A Technical Perspective
September 2009

Authors: Erik Bergenholtz, Michael Palmeter,
Mark Prichard, James Kirsch, Ioannis

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200

Copyright © 2009, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and
the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective