Many customers are beginning to WEB enable their legacy user - IBM

flashyfarctateInternet και Εφαρμογές Web

30 Ιουλ 2012 (πριν από 5 χρόνια και 1 μήνα)

214 εμφανίσεις

© 2005 IBM Corporation Advanced Technical Support
, Washington Systems Center

Version 03/
21
/05



http://
www.ibm.com/support/techdocs



Page
1

of
12

WP100558
-

Optimizing WebSphere Performance on z/OS


Optimizing WebSphere Performance on z/OS


Many customers are beginning to WEB enable legacy user applications that require
access to
their
enterprise data residing on z/OS Sysplex

(d
atasharing
)

environments.
Enabling these applications using JAVA/J2EE comp
onents provides unparalleled
portability and flexibility with regard to development
of
platform decisions.

These
choices often include implementation architecture decisions such as two
-
tier versus three
-
tier as well as various vend
o
r hardware/software pla
tforms.


Recent benchmark activity at IBM
’s

Washington Systems Center (WSC)
and customer
facilities provides compelling performance evidence to consider a
z
/OS, WebSphere,
DB2 for z/OS based solution as a very optimum implementation choice.


Specifi
cally,
the
solution

utilize
s

EJB Java container
s

supporting client business application logic
processes
executing co
-
resident
(or Local)
on the same z/OS server as the database server
function.


S
ome background information
is useful
for

understand
ing

the

primary

performance
consideration
s

potentially at work in today’s Web application implementations
.

Figure 1
is an illustration of the component flows
(
and protocol
s
1
)

that can exist in a typical Web
application.


Servlet
EJB
EJB
Browser
IIOP
IIOP
HTTP
(
S
)
Resource
Manager
(
DB
2
)
TCPIP
TCPIP
TCPIP
TCPIP

Figure 1
-

Component Flows of a Typical Web Ap
plication


The key is that all of these components can reside in separate tiers and/or containers.
When the components are all on separate tiers
,

several things occur which impact the
responsiveness and
TCO of the application
:


1.

An increase in latency, or e
nd
-
to
-
end response time, which occurs because there is
a remote flow involving TCPIP and a separate dispatch of the request on the
downstream tier.

2.

There is also the CPU cost associated with the serialization/de
-
serialization of
objects into wire format in

order to pass the request to the next tier.

3.

And there are network bandwidth imp
lications
associated
with
the amount of
data
which must be passed from tier to tier.


While the J2EE programming model and connectors support the logical and physical
separat
ion of these components, there are significant performance gains to be made in
keeping the logical separation while minimizing or eliminating the physical separation.





1

Protocols between Web components are

Hyper text transfer protocol (HTTP)
-

secure and non
-
secure, or
internet inter
-
orb protocol (IIOP)

© 2005 IBM Corporation Advanced Technical Support
, Washington Systems Center

Version 03/
21
/05



http://
www.ibm.com/support/techdocs



Page
2

of
12

WP100558
-

Optimizing WebSphere Performance on z/OS


Let’s

first look at the J2EE component

elements

and then look at the interaction between

th
e J2EE components and the resource managers.


J2EE components largely interact through IIOP flows. A method call from a servlet/EJB
t
o another EJB

will likely involve the
marshalling

of the objects into wire format
, or
a
byte array
, passing this array
to the remote container, where the objects will be de
-
marsha
l
l
ed
and made available to the method. The result set will then be
marshal
l
ed

into
wire format and returned to the container of the caller where de
-
marshalling

will occur
and the result set is ma
de available to caller of the remote method.
In other words, the
objects are passed by value between the components
. Figure 2 illustrates J2EE
components in separate servers.


ServerB
EJB
2
ServerA
EJB
1
IIOP
TCPIP
EJB Container
EJB Container

Figure 2


J2EE Components in
s
eparate
s
ervers


If the two J2EE components ar
e in separate servers, this will
also
require TCPIP flows to
pass
the
marshalled

data between the two runtimes. This adds both CPU time and latency
to the transaction.



ServerB
EJB
1
EJB
2
EJB Container
F
igure
3



J2EE Components in
same

server


© 2005 IBM Corporation Advanced Technical Support
, Washington Systems Center

Version 03/
21
/05



http://
www.ibm.com/support/techdocs



Page
3

of
12

WP100558
-

Optimizing WebSphere Performance on z/OS


If the J2EE components are co
-
located
in the same server

as shown in Figure 3
, the
TCPIP flow is eliminated. The runtime ‘knows’ how to invoke the downstream EJB
without a TCPIP flow and without a re
-
dispatch.

This reduces CPU consumption and
latency. However, the
marshalling and de
-
marshal
ling

cost remain
s
.


T
he J2EE specification provides the capability of
defining and
using local interfaces for
co
-
located components. Use of
local interfaces eliminates the
marshalling and de
-
marshalling

operations as the
method arguments and result set

ar
e passed by reference
and not by value. It has been a “best practice” to design and use local interfaces when the
components are known to be co
-
located.


Addi
tionally, WebSphere supports an

optimization among J2EE components which
allows pass by reference

when only remote interfaces are defined AND the components
reside in the same server. Use of this optimization eliminates the
marshalling and de
-
marshalling

costs, the TCPIP flows and the

task

re
-
dispatch, which reduces
CPU
consumption and latency.





ServerB
EJB
1
EJB
2
Web App
Web
/
EJB Container

Figure
4



Web App and
J2EE Components in
same

server


Figure 4

is the optimal configuration with respect to the minimization of the
marshalling
and de
-
marshalling

CPU
costs, elimination of TCPIP flows and t
ask dispatches and
associated latency.
In other

words, this configuration has the least amount of “overhead”
,

as the physical separation of the components has been eliminated.


However, it is understood that there may be good reasons for the physical separation of
the web tier from the EJB tier.


© 2005 IBM Corporation Advanced Technical Support
, Washington Systems Center

Version 03/
21
/05



http://
www.ibm.com/support/techdocs



Page
4

of
12

WP100558
-

Optimizing WebSphere Performance on z/OS


ServerB
EJB
1
EJB
2
ServerA
Web App
IIOP
TCPIP
EJB Container
Web Container

F
igure
5



Web App and
J2EE Components in
separate

servers


When this is the case

as in Figure 5
, it is important to:


1.

Minimize the number of interactions between web tier and the EJB tier, and

2.

Minimize the amount of data moved back and forth between these
tiers.


In order to
minimize

CPU costs, latency and network load

in this configuration, the
application logic needs to be designed, or

re
-
f
actored after the initial load tests,

so that
“answers to questions” are passed between the

physical

tiers rather tha
n just data which
will then be digested to form “answers”. Additionally, the objects, particularly the size
and number
of the

serialized objects
,

must
be carefully examined. It may be
necessary

to
provide t
he passed objects with serializable and/or exter
nalizable interface
implementations to reduce the amount

of data passed across the wire and eliminate CPU
costs associated with the default marshalling/de
-
marshalling process in the runtime.



The second area to be addressed is the interaction between the
J2EE components and the
resource manager
, f
or example DB2. The J2EE components and DB2 can be
l
ogically
and physically separated.



© 2005 IBM Corporation Advanced Technical Support
, Washington Systems Center

Version 03/
21
/05



http://
www.ibm.com/support/techdocs



Page
5

of
12

WP100558
-

Optimizing WebSphere Performance on z/OS


ServerB
Database
ServerC
Resource
Manager
DB
2
DRDA
TCPIP
Data Flow
EJB
1
EJB Container


Figure
6



J2EE Components
and Resource Manager
in
separate

servers



In Figure 6, r
emote interactions between J2EE comp
onents and DB2 exhibit much the
same behavior as remote IIOP flows. Data must
be
marshalled and de
-
ma
r
shall
ed, there
are TCPIP flows and associated latencies, and there is the need to re
-
dispatch the work
request. In the case of DB2 for z/OS, there is in

addition to the type
-
4 JDBC driver
,

a
type
-
2 JDBC driver which can be used when the J2EE components and DB2 subsystem
reside on the same operating system image.


Database
ServerC
Resource
Manager
DB
2
EJB
2
EJB Container

Figure
7



J2EE Component
and Resource Manager
in
same

server


When the
type
-
2 JDBC driver
is used,
the CPU cost of marshalling/de
-
marshalling data
into wire format and the associated TCPIP flows are eliminated.
Using the type
-
2 JDBC
driver
with the

Figure 7 implementation, t
here is no

task re
-
dispatch, the DB2 activity
© 2005 IBM Corporation Advanced Technical Support
, Washington Systems Center

Version 03/
21
/05



http://
www.ibm.com/support/techdocs



Page
6

of
12

WP100558
-

Optimizing WebSphere Performance on z/OS


continues on the current

thread of execution. The priority/importance of the current
request being processed is maintained. Additionally,
the type
-
2 JDBC driver uses RRS
for managing transaction state which is a superior performer than the type
-
4 (XA) JDBC
provider.


Database
ServerC
Resource
Manager
DB
2
EJB
1
EJB
2
Web App
Web
/
EJB Container

Figure
8



All
J2EE Components
and Resource Manager
in
s
ame

server


The
configuration
in Figure 8
marries the concept of co
-
locating the J2EE components in
the same server and having those components which interact with DB2 do so locally.



© 2005 IBM Corporation Advanced Technical Support
, Washington Systems Center

Version 03/
21
/05



http://
www.ibm.com/support/techdocs



Page
7

of
12

WP100558
-

Optimizing WebSphere Performance on z/OS


Database
Server D
Resource
Manager
DB
2
EJB
1
EJB
2
Web App
WebSphere
Web
/
EJB Container
Server C
Resource
Manager
DB
2
EJB
1
EJB
2
Web App
WebSphere
Web
/
EJB Container

Figure
9



Clustered

WebSphere servers accessing data in DB2 datasharing group


This configuration can
be
expanded to clustered WebSphere servers accessing data in a
DB2 data sharing group with complete integrity and access control

as
illustrated in Figure
9
.

Furthermore, th
is configuration provides amazing levels of scale
-
up and scale
-
out
capability without the need to partition data and route requests to servers with access to
specific data.

Recent Benchmark Experiences at Washington System
s

Center


The following informa
tion was
the result of
a
customer
application
benchmark study
conducted at the Washington Systems Center
.

It illustrates the benefits
achieved
for a
specific customer application implemented
with solution application logic executing in an
EJB Container
co
-
located with the
database server
on
the same z/OS

system environment

versus
using
a
distributed business logic implementation executing in a remote EJB
Container.


The function of this application is immaterial to th
is

discussion;

however, it is important

for the reader to understand that
each
application

business
process function

that was
executed consisted of
multiple business logic steps
.


In other words, a business process
function invoked by an end user client resulted in multiple business logic steps

being
invoked in order to obtain a
n answer

response
to the user
. E
ach business logic step
required access to Enterprise data information in order to
perform

the
next step in the
business logic until the last step in the process was executed.

Each busine
ss logic step
© 2005 IBM Corporation Advanced Technical Support
, Washington Systems Center

Version 03/
21
/05



http://
www.ibm.com/support/techdocs



Page
8

of
12

WP100558
-

Optimizing WebSphere Performance on z/OS


resulted in an EJB invocation on the zSeries platform


the number of invocations and
average response times were measured via WebSphere interval transaction reporting
using System Management Facility (SMF) type 120 information.


The number o
f bytes
transferred per business logic step was derived using the number of transactions reported
via the SMF type 120 record and Resource Measurement Facility type 7
3

Channel Path
Activity information.


Figure
10

provides an overview of
processing that o
ccurred for the customer’s original
business application implementation using
a
remote (
distributed
)

EJB container

for
executing business logic.



Figure
10



Remote (Distributed)
Business

Processing
Logic
Environment


Figure
11

provides an overview of
pr
ocessing that occurred for the
re
-
factored customer
application implementation where the business logic steps were executed completely in
a
n

EJB container co
-
located, Local on the same z/OS system with the database server
function.


The re
-
factorization ba
sically implemented a fa
c
ade EJB function that
managed
the execution of required
business logic steps
to develop the
answer
returned
to the
distributed Web container.


© 2005 IBM Corporation Advanced Technical Support
, Washington Systems Center

Version 03/
21
/05



http://
www.ibm.com/support/techdocs



Page
9

of
12

WP100558
-

Optimizing WebSphere Performance on z/OS



Figure

11
-

Local z/OS
Business

Processing

Logic
Environment


T
he
primary measures for

comparing the two environments were:

1.

A
verage CPU time per EJB invocation (transaction)
,

and
,

2.

A
mount of data transferred per EJB invocation (transaction)
.


The performance characteristic

data was extracted from
the
z/OS operating system
platform for each
application configuration benchmark.


Table 1 provides the summary
result information.


Table
1

Performance Measurement Data for Benchmark Environments

Benchmark Configuration

Average CPU time per
EJB transaction (ms)

Amount of data

transferred per EJB
transaction (KB)

Remote

(Distributed)

Business Logic Environment


11.73


54.4

Local z/OS

Business
Logic Environment


2.64


0
.
5


The benefits for running the business process logic on z/OS WebSphere for
this customer application we
re overwhelming.

© 2005 IBM Corporation Advanced Technical Support
, Washington Systems Center

Version 03/
21
/05



http://
www.ibm.com/support/techdocs



Page
10

of
12

WP100558
-

Optimizing WebSphere Performance on z/OS




Average CPU time per EJB transaction was reduced by over 77%



Number of bytes of data transferred per EJB transaction was reduced
by 99%


Other Experiences: Two
-
tier versus Three
-
tier Web Applications

accessing Enterprise Data

Other

experim
ents conducted at customer facilities have
also
resulted in similar
observations.

A
large financial customer
benchmarked
the following
configurations for a
Web
business
application
which
access
ed

Enterprise data
.



Figure
12



Financial Customer with
Rem
ote (d
istributed
)

Enterprise Data
base



Figure
12

was the starting point for the customer test.

The Enterprise database was
housed on a system (z/OS #2) remote from the J2EE EJB components that accessed the
database information.


SQL requests from the J2E
E EJB components in z
/
OS #1 system
resulted in a distributed data request (DDF) to the
DB2
server on z/OS #2 system.


© 2005 IBM Corporation Advanced Technical Support
, Washington Systems Center

Version 03/
21
/05



http://
www.ibm.com/support/techdocs



Page
11

of
12

WP100558
-

Optimizing WebSphere Performance on z/OS




Figure
13



Financial Customer with
Local
Enterprise Data
base


Figure
13

was the updated configuration using a Local Enterprise databas
e
implementation co
-
located in the same server with the J2EE EJB application components


all on z/OS #1.


SQL requests from the J2EE EJB components in z
/
OS #1 system
resulted in a local connection to the database server on z/OS #1 system.

The
configurati
on change eliminated the TCPIP DDF processing flows between the two z/OS
systems in Figure 7 for SQL requests.


Significant improvements in performance were observed as a result of this configuration
implementation change for the Enterprise data access.

A

50% reduction in average e
nd
(Web) user response times
were
reported by the test driver
tools.


In addition, the overall
CPU required by the z/OS system environment was 50% less than the Remote (2 z/OS)
system implementation.


Summary:

While these results

were obtained from real customer application situations,
the reader should remember that the results may not be generally available
for all customer application situations.

Determination of results for a specific
customer application situation may requir
e detail profiling of the workload
using generally available tooling and methods.

© 2005 IBM Corporation Advanced Technical Support
, Washington Systems Center

Version 03/
21
/05



http://
www.ibm.com/support/techdocs



Page
12

of
12

WP100558
-

Optimizing WebSphere Performance on z/OS



Contact Mike Cox
(
coxm@us.ibm.com
)
or Paul Glass (
glassp@us.ibm.com
)
at the IBM Washington

Systems Center to learn more about this specific
benchmark.


Contact your nearest z/Series Field Technical Support Specialist
to learn more about opportunities to use the z/OS to Web enable customer
application.