W22 - WebSphere Performance for Multicore and Virtualised Platforms

© 2010 IBM Corporation
Conference materials may not be reproduced in whole or in part without the prior written permission of IBM.
WebSphere Performance for MulticoreWebSphere Performance for Multicore
and Virtualised Platformsand Virtualised Platforms
Session Number: W22Session Number: W22
Hendrik van RunHendrik van Run –– hvanrun@uk.ibm.comhvanrun@uk.ibm.com

WebSphere Technical Conference and Portal
Excellence Conference
2
Agenda
• Multicore processor technology
Why do we need/have multicore processors?
Examples of Multicore processor architectures
How to get value out of Multicore platforms?
• Known Issues and Best Practices for Multicore
Administration
Programming
• Virtualisation in the Enterprise
Why Virtualisation?
Different forms of Virtualisation
Where to start?
• Known Issues and Best Practices for Virtualisation
Performance Overhead
Resource Over-Commitment
WebSphere Performance Best Practices
Other Best Practices

3
Moore’s law
• Moore's law describes a long-
term trend in the history of
computing hardware
The number of transistors
that can be placed
(inexpensively) on an
integrated circuit has doubled
approximately every two
years
The trend has continued for
more than half a century
This is not expected to stop
until 2015 or later
• For almost two decades, single thread performance has doubled every 2
years in a very predictable fashion

4
CPU clockspeed has hit a wall
• Performance has
been propelled
forward by
continuing
advancements in
Clock speed
Instruction Level
Parallelism (ILP)
L1/L2/L3 cache
size
• Heat dissipation increases linearly with processor frequency
This is the main reason that clock speeds cannot easily exceed 3-5 GHz
• Using mutiple cores on the same integrated circuit continues to allow for
increased performance

5
The multicore future: System on a chip dreams
• Massively complex and interesting problems await chip
designers
• How else can we use all these extra transistors?
More processors on a chip (Multi-core)
More threads on a core (SMT)
Special-purpose processors (eg. crypto, compression)
Integrate system components on the chip (eg. network, I/O)
• Multicore is only the first, most notable impact of the
physical phenomena of ever shrinking die sizes
• The real story is that the measure of success for future processors is changing
It’s no longer about being the Gigahertz champion or having the most clever microarchitecture
It’s about who can use their transistor budget most effectively to speed up real workloads
• One size will not fit all
Greater focus is required on current and emerging workload characteristics
Both general purpose and special purpose processing will play a role
Processor and system effectiveness will be measured more aggressively against multiple criteria
(performance, power, price, reliability)
Greater levels of integration in hardware will drive new requirements into software

6
What are the benefits of multicore platforms?
• Consolidation
Most admins are looking at the sheer number of cores in a single box now as a means
to consolidate older larger systems
Allows for collapsing down of multi-tiered architectures
• Power Savings
Power costs in a system come from more than just the processor.
Ability to consolidate down 4 machines into 1 will save you power.
Eliminating machines from your infrastructure provides consolidation of the sheer
amount of moving parts in your infrastructure saving you money.
• Performance
Moving from old single core hardware to new multicore hardware can result in
significant performance improvements to legacy applications
• All of the above effectively reduce cost

7
Why should I understand multicore platforms?
• Typical hardware replacements cycles mean boxes with these processors are coming into
your IT shop soon if not already there
• These systems present unique challenges for Operating System, WebSphere, and
Application Deployment outside of the past 10 years of knowledge
• Hardware specific features and characteristics can cause major performance swings in
applications
• Requires developers to understand how to write code optimized for deployments on this
type of hardware or/and Administrators that know how to work around multicore code
problems.
• Tighter coupling of operations and development is required
• Through understanding of 3rd party libraries
• Possible reworking of existing applications required to make them run optimally on
micropartitioned or over committed hardware
• Intelligent and insightful planning will ease your pain

8
Examples of Multicore processor architectures
Intel Nehalem
• 1.86 – 3.6 GHz
• 2 – 8 cores per chip
• Up to 2 threads per
core (SMT)
IBM Power7
• 3.0 – 4.25 GHz
core (SMT)
IBM Power6
• 3.5 – 5.0 GHz
• 2 cores per chip
core (SMT)
AMD Phenom II
• 2.5 – 3.5 GHz
core (SMT)
Sun Niagara 2
• 1.2 – 1.6 GHz
core (SMT)

9
Virtualisation
• Large number of cores can be a challenge
How can you make sure that you’re using them all?
• Virtualisation enables you to effectively run more applications on the
same machine
Different types of virtualisation exist
We will discuss those in more detail towards the end of this presentation
• There is no single “best” virtualisation technology out there
Depends very much on your business and application needs
• Start with requirements
Do you want movable OS images?
Do you need OS level partitioning?
Do you need Dynamic resource allocation?
Do you want to simply pay the lowest cost?

10
Understand scaling of WebSphere Application Server
• The evolution of multicore hardware places unique demands
on application server performance
A single instance must perform well at a low number of cores,
but also scale to take advantage of many cores
Multiple instances must be able to run concurrently providing
“vertical scaling” on a single server
• WAS V7 Multicore Performance
WAS V7 achieves close to 1000 requests/second on a single
CPU core running the DayTrader benchmark in this configuration
WAS is able to take advantage of all 12 cores showing significant
performance increases as more cores are enabled
The ability to achieve high scalability depends on application
architecture
• WAS V7 Multicore Scalability
The 2nd graph depicts WAS V7 scalability relative to a linear
scale.
With this benchmark, WAS V7 scales well to 8 cores. Scalability
between 8 and 12 cores is beginning to flatten, but significant
improvement is still being measured at 12 cores
• WAS V7 Vertical Scaling
WAS V7 ND provides the foundation and features for developing
a vertically clustered application (or applications) on a single
platform
Vertical scaling can take advantage of many CPU cores and
dramatically improve single server scalability

11
Known Issues and
Best Practices for Multicore

12
Known Issues and Best Practices for Multicore
Introduction
• Multicore platforms require specific knowledge
Administrators
Developers
Architects
• Single thread application performance is typically lower
Most Multicore processors run at a relative low clockspeed
This fundamental limitation is central to what we will discuss here

13
Administration
• Multicore processor designs focus on building more capacity
No longer an increase in clockspeed with every new processor
• Clock speeds are up against the boundary of what’s possible
Effects anything that is single threaded:
Application Startup Time (i.e. 60 s instead of 15 s)
WSAdmin and scripting runtime startup
Batch compilation of JSPs
Client Response Times (i.e. 1.5 s instead of 500 ms)
• Hence you can no longer expect performance to double every 2 years
Incremental improvements in processor design will be made optimizing
pipelines and instruction cycles
Unlikely to see similar increase from the past in single thread performance

14
Administration
• Memory capacity growth is slower than CPU capacity growth
Most of the new multicore systems are limited in memory
Forced to run 8-16 hardware threads or more against 8GB-16GB of
space
Be very careful not to overcommit your memory resources!
5% CPU utilisation and 100% memory consumption is common
• Very advanced and sensitive BIOS and other hardware
settings required to get the most performance
SMT/CMT/HT effect application performance
Intel/AMD “Turbo Mode” has drastic effects on different applications

15
Administration
• Consolidated environments can lead to issues with High
Availability
Less machines means a single outage results in more applications
effected
Need to plan to ensure data replication occurs off a single machine
• Legacy software can suffer massively
Massive concurrent load on code not designed or tested through
enough to handle it
Clock speed drop effects CPU intensive code paths
• Hardware while becoming much more powerful is becoming
more specialized

16
Administration
• WAS administrative best practices
With previously discussed memory and CPU speed concerns
Ensure your heaps and thread pools are correctly sized
With WSAdmin scripts limit the initialization of the framework
Ensure performance acceptance testing is completed on identical
deployment topology
Business level application planning should take into consideration
hardware variations
Work with developers to institute codepath focused profiling and
improvement in applications
• Garbage Collection Overhead
Due to the increase in processing speed and capability on a single
system the amount of garbage created in a single JVM increases and
you must tune appropriately

17
Programming
• Programming for a multicore world is not THAT much different than
writing good performing code today.
Developers just need to do a little more due diligence before committing code
Develop with the deployment hardware in the back of your head. You cannot
treat the hardware as an unknown
• Maximize single thread (request) performance
Minimizes response time for end user requests
Code for a request that can execute as efficiently as possible on a single
thread leads to better performance and in most cases better scalability as
concurrent requests go up
Developers have to be more aware of what their code is doing as it flows
through 3rd party libraries
What to do:
Focus on requests traversal from the socket down to the backend system
Review your code to remove unnecessary caching or CPU intensive method calls

18
Programming
• Utilize Effective Memory Management
The JVM for all of its advancements still has its performance dictated to it by
garbage collection
Minimize Object creation by avoiding the overly object oriented scenario as well
as minimizing reflection. Keep it primitive where ever possible.
Audit your code for calls to “new” but avoid pooling except for excessively
complex object trees.
If exploiting internal pooling or caching ensure it happens as high up the code
stack as possible.
Keep object structures as “thin” as possible.
• Exploit Advanced Synchronization
To be able to scale up effectively with the move to multicore hardware every
developer needs to be well aware of explicit and implicit synchronization
Define early on what data need to be shared across hardware threads and what
doesn’t and use appropriate data structures.
Ensure synchronization is at the lowest possible level. Decompose locking
schemes.
For shared data structures utilize java.util.conncurrent or advanced libraries
Expose outwardly via java docs the level of synchronization to API level calls to
your component for internal consumption.

19
Programming
• Exploit Effective Use of Debugging, Trace, and Logging Code
Minimizes runtime codepath length and GC overhead
The JIT is excellent at optimizing code out but it is still prudent to create
clean code it is also critical to create performant trace code
What to do:
Create trace code for your method entry and exits but ensure they are properly
gated
Review your trace code to make sure it is putting out information to help with
debugging but nothing more to keep overhead as low as possible
• Remove unused or redundant code
Reduces startup time by cutting the amount of class size being loaded from
disk
Redundant code and unused code contributes to class file size growth
resulting in classload times increases
What to do:
Audit your code to ensure that all the method calls in your classes are actually
accessed from other code, if not remove them.
Ensure that in your methods all code is reachable by running one of the various
Eclipse plugins that detects dead and unreachable code.

20
Virtualisation in the Enterprise

21
Why Virtualisation?
• Most datacenters are heavily underutilized with systems running
between 5-10% CPU on average
This is not intentional but typically due to the unfounded need for all
applications to run on discrete machines OR applications cyclical life
cycles
All modern hardware can easily run at above 50% CPU without
losing performance
• Not running your servers at maximum capacity is costing you
dollars in terms of software licenses, power consumption, floor
space, etc
• There is no single solitary way to virtualize your environment. You
need a strategy based off of your applications and business needs

22
Why Virtualisation?
• Consolidation
Most admins are looking at the sheer number of cores in a single box now as a means
to consolidate older larger systems
Allows for collapsing down of multi-tiered architectures
• Power Savings
Power costs in a system come from more than just the processor.
Ability to consolidate down 4 machines into 1 will save you power.
Eliminating machines from your infrastructure provides consolidation of the sheer
amount of moving parts in your infrastructure saving you money.
• Performance
Moving from old single core hardware to new multicore hardware can result in
significant performance improvements to legacy applications

23
Why Virtualisation?
• Typical hardware replacements cycles mean boxes with
these processors are coming into your IT shop soon if not
already there so take advantage of them!!
• Virtualization can drastically cut down on the energy and
effort to get new WAS environments stood up for testing and
production
• In the world of every tighter budgets and constrained
resources the ability to get the most out of your hardware
makes a difference on the bottom line.

24
Hardware Virtualization
• Advantages
– Pure electronic
isolation
– Hardware based
resource sharing
– Higher Performance
• Disadvantages
– Management and
maintenance of large
topology of systems
Software Virtualization OS Virtualization
Power7 Hardware
• Advantages
– Hardware agnostic
moveable OS images
– OS based isolation
– Software based
resource sharing
– Good Performance
• Disadvantages
– I/O system
performance
– System Tooling not
accurate
• Advantages
– Single OS installation
– OS isolation/security
– Simplistic box based
administration
– Near on metal
performance
• Disadvantages
– System level only
management
– Dependent on base
LPAR/Hardware for
availability

25
Multiple WebSphere
Instances
Single WAS multiple
applications
WAS
App
App
App
App
App
App
App
App
• Advantages
– Process based security
– Fast install, setup and boot
– Best performing setup
– Least memory consumption
• Disadvantages
– Process level security only
• Advantages
– Simplistic Administration
– Good performance
• Disadvantages
– No application isolation
– Rouge Applications
– Minimal availability

26
Where to start with Virtualisation?
• Start small and work big towards a grander plan
• By starting small and slowly rolling applications from “bare metal” into your virtualized
infrastructure you can work through issues and adjust future plans
• By having a grand vision on where the datacenter in your business is heading its
easier to sell the long term value and show short term progress in real numbers
• Begin by working with back office, old non critical, new applications, or development
• New applications
No known baseline to be compared to so no one can say “the old stuff was faster”
Can be build and tested from the beginning with virtualization in mind. Thus all performance
testing, etc can be done on like systems.
• Back office / Old non critical applications
Nice starting point as huge amount of information on access patterns and other factors
affecting performance exist.
Minimal risk of impacting large user sets
• Gain knowledge and roll that knowledge into your long term plan

27
Known Issues and
Best Practices for Virtualisation

28
Known Issues and Best Practices for Virtualisation
Virtualisation Performance Overhead
• Performance overhead differs by platform and virtualization technology
• Completely virtualized environments typically have higher performance penalties
Network and disk IO latencies significantly higher in these environments
• Para-virtualization technologies provide an optimized path to the underlying
hardware for these high latency paths
VMware Tools provide this capability in VMware environments
Optimizations for virtual Ethernet driver, memory sharing and time sync
Enabling VMI kernel support on VMware/Linux-based guests reduces virtualization
overhead further
Check VMware documentation for supported kernels
• Newer hardware technologies provide better virtualization support and
performance
For example: Intel VT and AMD-V

29
Virtualisation Performance Overhead – VMware ESX 3.5
• Example overhead measurements based on DayTrader application
Minimal disk I/O characteristics
Increased I/O activity will increase performance delta
• VMI kernel reduces overhead further (~ 5% overhead)

30
Virtualisation Performance Overhead – PowerVM LPARs
• Traditional “Thick” LPARs provide hard isolation and dedicated resources
“Thin” LPARs use the AIX Network Installation Manager (NIM) to share a single
remote OS boot image
• Minimal disk I/O characteristics are behind the small performance delta

31
Virtualisation Performance Overhead – PowerVM WPARs
• Workload Partitions (WPARs) provide a virtualized operating environment activated within the
global OS
• Virtualization overhead minimal
• Multi-instance scalability impacted by normal process scheduling hurdles
RSET can be used to achieve optimal throughput for multiple instances in both LPAR and WPAR
environments

32
Virtualisation Performance Overhead – Different Levels of Isolation

33
Resource Over-Commitment
• Memory
Never over commit physical memory in the system if you expect predictable performance
When pushing the boundaries of physical RAM in a system smaller JVM heaps allow for more WAS
instances on a single hardware machine
• CPU
CPU over commit results in good performance up to the point of 100% saturation on the hardware
At which point, response time begin to suffer
Limit Memory Over commit Lower CPU Utilization Over commit

34
• Thread pool settings
Must be sized not to the number of virtual CPUs exposed but to the
number of physical CPUs on the system
• Heap Sizes
Set heap sizes to ensure that guest remain in physical memory for
optimal performance.
Right size your heap to ensure you are not wasting memory
• High Availability
You must implement a intelligent placement mechanism to ensure
fault tolerance for your applications

35
• Deployment Scripting
Script your administrative tasks to ensure that installation and
configuration of multiple nodes is repeatable
Allows you to bundle and distribute images quickly and have them up
and running in a “certified” manner
• Minimizing IO
Minimize the application server IO to ensure maximum performance
Cut logging to a bare minimum
Bare minimum writing to disk should be done unless the disk system
is optimized
Ensure “chattiness” of your application is as minimal as possible

36
• Resource utilization monitoring
Virtualization often skews the CPU, IO and other resources metrics
reported by the Guest OS
Need to rely on the Hypervisor for resource utilization statics
Example:
AIX micro-partitioning
• Clock sync / drift
Problem noticed in VMware / WebSphere HA environments
Installation of VMware Tools and use of VMI kernel address this
issue
• VM migration tools (ie. VMotion)
Avoid these technologies in your environment

37
• WebSphere tuning can be directly linked to resources allocated to Guest
VM
• Reduce disk space and memory requirements for Guests by disabling or
removing un-used services and applications
• Leverage VM cloning and templating technologies to provide a uniform
operating environment
For example: “Linked-clone Templates” in VMware
Scripts for changing WAS hostnames
http://www.ibm.com/developerworks/websphere/techjournal/0905_webcon/0
905_webcon.html
• Use SANs or other fast disk technologies for IO intensive workloads
• Can I trust Java profiling tools in virtualized environments?
Successfully used Java Health Center CPU profiling to diagnose
performance issue

38
Deploy Applications in Virtualised Environments
WebSphere CloudBurst 2.0 Appliance
• Ability to rapidly deploy IBM middleware and customer applications into virtual
and cloud environments leveraging best practice deployment patterns
• Support for multiple hypervisor platforms, such as VMware ESX, PowerVM,
and z/VM
38
• Availability of the following product images
WebSphere Application Server Hypervisor Edition
V6.1 and V7
WebSphere Application Server Hypervisor Edition V7
now available on Red Hat Enterprise Linux!
WebSphere Application Server Hypervisor Edition -
Intelligent Management Pack
Available for WebSphere Application Server Hypervisor
Edition V7
WebSphere Process Server Hypervisor Edition V6.2
and V7

39
Summary
• Multicore processor technology and Virtualisation
Technologies are here today
And this trend will continue…
• WebSphere performs well on those platforms
But make sure to address known issues and apply best practices

40
QuestionsQuestions
• Please remember to complete your session evaluation form
Please complete your session evaluation, session number is W22

W22 - WebSphere Performance for Multicore and Virtualised Platforms

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to W22 - WebSphere Performance for Multicore and Virtualised Platforms

Similar to W22 - WebSphere Performance for Multicore and Virtualised Platforms (20)

More from Hendrik van Run

More from Hendrik van Run (19)

Recently uploaded

Recently uploaded (20)

W22 - WebSphere Performance for Multicore and Virtualised Platforms