1. 2018 Designing a Scalable and High Performing
Portal Infrastructure
Hide Details
James Krueger – WXS Development
Nitin Gaur – Application Infrastructure and Mobility
With Thanks to
Benjamin Parees – WXS Development
Paul Chen – WXS Development
© 2013 IBM Corporation

2. Please note:
IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal
without notice at IBM’s sole discretion.
Information regarding potential future products is intended to outline our general product direction
and it should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a commitment, promise, or
legal obligation to deliver any material, code or functionality. Information about potential future
products may not be incorporated into any contract. The development, release, and timing of any
future features or functionality described for our products remains at our sole discretion.
Performance is based on measurements and projections using standard IBM benchmarks in a
controlled environment. The actual throughput or performance that any user will experience will
vary depending upon many factors, including considerations such as the amount of
multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the
workload processed. Therefore, no assurance can be given that an individual user will achieve
results similar to those stated here.
2 © 2013 IBM Corporation

3. Primary Market Drivers
• The competition is only a click away in today's
web-facing world.
• Response times are critical to giving customers
a good experience and generating revenue.
• Customer sessions are becoming more critical.
• The cost of attracting new customers to your
web site for enrollment is significant.
• Losing the data that they have entered will likely
create a negative impression and result much
higher abandonment rates

4. Agenda
Motivation
Portal Topologies – Conventional and Farm
Overview of DynaCache and the Portal Advanced Cache
Review Performance Results
Configuration Overview
eXtreme Scale and XC10 Background
4 © 2013 IBM Corporation

5. Portal Topology : Conventional or Farm?
Conventional Topology Portal Farm Topology
© 2013 IBM Corporation

6. What is a Portal Farm?
■ A series of identically configured, stand-alone portal instances
■ No managed cell, no clustering, no Deployment Manager – Just Stand-Alone
Application Servers runtimes!
■ Workload management handled using any load balancer
– HTTP Server plug-in can be used with manual configuration
■ Server instances treated as commodities
– Rip-n-replace
– Can more easily mix/match maintenance levels
■ Extremely simple to grow/shrink capacity based on demand
■ Particularly well suited for cloud-based deployments
WP
WP WP
WP WP
WP WP
WP WP
WP WP
WP WP
WP WP
WP WP
WP
6

7. Typical Customers who is using Portal Farms
• Banks
• HR services providers
• Companies that need continuous availability
• Companies that are using LPARs or virtual images and SANs to run their
Portal and want to simplify maintenance.
• Companies that do not wish to set up and maintain multiple Portal
clusters.
 WAS Extended Deployment
• Keep it simple and make it work.
7

8. Portal Farming – What is Missing?
• Ultimate simplicity at the loss of some functionality
 DB or grid-based session persistence and failover only*
 No distributed cache management*
 No distributed EJB usage
 No synchronized configuration (without the aid of file system utilities)
 No coordinated task scheduling
 No cluster-scoped administrative actions
− Start/stop applications
− Can be replaced by “flexible administration” or scripting
• Customers need to understand these limitations before considering a
farm-based deployment
8

9. Why Choose Farming?
•Farming is a simple architecture with just a series
of identical stand-alone portal instances with load
Unique install Portal Farm
balanced by a HTTP plug-in or any load balancer Requests
•Server farms are effective way to build and maintain LB
a highly scalable, highly available server
environment
•Farms allows Dynamic Server Expansion and Node Node Node
contraction of size without complex cluster Portal1 Portal Portal1
configurations which are usually time consuming
•Sourcing additional servers using cloning or REL JCR REL JCR REL JCR
virtualization is very rapid. With WP7 Shared
configuration it is much more rapid and simple
•Client had a very tight maintenance window. CUS COM
Deployments on clusters, Synchronizing clusters is
stretching maintenance window
•Though administrative actions need to be
repeated on each server independently, this can be
achieved automation scripts or tools
• Customer understood the limitations of Farming –
like Distributed caching, EJB, cluster administration
etc.

10. Multi-Tenant Design Features
• Hosting Multiple clients on shared infrastructure
• All the customers are hosted on a huge infrastructure cloud
• Dynamic launching of clients enabled
• Clients are allowed to choose services from list of available services
• Provide complete client isolation so each client operate in its own SILO
•Resource sharing is enabled at various levels but not transparent to clients –
Shared resources are
• Hardware
• Server and JVM resource – CPU, Memory, Disk Space
• Portal instances
• Client identity (Branding) is handled by providing custom personalization at
application design
10

11. Client isolation and insulation – Conceptual model
• Every customer needs to be in his own virtual environment and completely isolated
• Insulated from information spill and Load fluctuations
• Is physical isolation a reasonable solution?
A Client A Client A Client A Client A Client A Client
SILO SILO SILO SILO SILO SILO
Gateway Gateway Gateway Gateway Gateway Gateway
Security Security Security Security Security Security
Web Tier Web Tier Web Tier Web Tier Web Tier Web Tier
Portal Portal Portal Portal Portal 57K Clients Portal
App Tier App Tier App Tier App Tier App Tier App Tier
DB Tier DB Tier DB Tier DB Tier DB Tier DB Tier
11

12. Need for a Common Tier : Conventional OR Farm
Topology
•Need for a common tier
•Keep State Information
•Tier for HTTP session caching
• Efficient WCM cache
•Other common redundant cache
•Off-load Dyncache
•Lighter Portal JVMs
•Reduce CPU utilization due to
GC
•Efficient CPU Utilization –
reduced complex cache activity.
•Efficient middleware Growth
© 2013 IBM Corporation

13. Elastic Caching minimizes the impact of
Transaction Overload
Web Server Tier App Server Tier Elastic Cache Back-end Systems
Database Tier
Improve Performance,
Scalability & Availability
Highly Scalable Web
Applications
Data-intensive
Applications
Extreme Performance
WebSphere
IBM HTTP Server DB2 UDB
Application Server

14. Innovative Elastic Caching Solutions
“Data Oriented”
Session management
Elastic DynaCache
DataPower XC10 Appliance Web side cache
• Drop-in cache solution
Worldwide cache
optimized and hardened
for data oriented scenarios Data buffer
• High density, low footprint eXtreme Scale
improves datacenter Event Processing
efficiency Petabyte analytics • Ultimate flexibility across a
broad range of caching
In-memory OLTP scenarios
• In-memory capabilities for
In-memory SOA
application oriented
“Application Oriented” scenarios
Elastic caching for linear scalability
High availability data replication
Simplified management, monitoring and administration
14

15. Session Caching for WebSphere Portal

16. Applications using DynaCache
Each JVM has a private disk
based cache to support caches
much larger than possible with a
memory only conventional cache
2 tier cache: JVM has a small
local cache, then the disk file.
Cached content is redundant
across JVMs
16

17. News Portlet Deployment - Failure
!#*! DynaCache
W e lc o m e ,
WPS disk-offload
U ser!
DynaCache
WPS disk-offload
… too slow!
DynaCache
During a recent ‘News’ application promotion, the WPS disk-offload
customer response to the new portlet overwhelmed
the web-site. The web-site became painfully slow
under the significant load. The result, not a happy
customer… DynaCache
WPS disk-offload

18. Scalability: Off-loading Dynamic cache to WXS/XC10
Much larger cache capacity
 WebSphere Portal JVMs run
more efficiently
– Lower local memory
requirements
– Faster start-up time
Improved consistency of
performance
– Improved cache and
environment stability
– High availability of cached
data
18

19. News Portlet Deployment - Success
Elastic cache
W e lc o m e ,
U ser!
WPS
W XS
WPS
During a recent ‘News’ application promotion, the
WPS
customer response to the new portlet was very high. With WXS DynaCache Grid
However, with addition of an elastic cache the web-site configured, disk-offload is no
was able to handle the significant increase in load. The longer required
customers did not perceive any slow down of the web-
site. The result, happy customers and a successful
content promotion… WPS

20. Fast start-up when adding more capacity – on the fly
Elastic cache
WPS
W e lc o m e ,
U ser!
WPS
W XS
WPS
New WebSphere Portal servers can be
brought on-line quickly to meet increased
WPS
capacity needs. When start-up is
complete, the new server has immediate
access to a warm cache provided by
eXtreme Scale.
WPS
New Server

21. Maintain consistent user experience during site maintenance
Elastic cache
WPS
W e lc o m e ,
U ser!
WPS
W XS
WPS
If a WebSphere Portal server needs to be
restarted after applying an iFix, eXtreme
WPS
Scale can provide up to 54%
improvement in time to reach steady-state
WPS Down for maintenance

22. Scenario Details
Two Portal Servers with Web Content Manager  300 concurrent users simulating Wiki/Blog accesses
Single WCM DB Server  Web Content Manager DB content: 50 gigs
Two XC10 Caching Appliances
Advanced Cache maximum entries
Using App Server heap: 5000 per server
Offloading to XC10: 1,000,000 shared available (Observed ~9 gigs)
WPS+
WCM 2 XC10 Collective
Proxy
WPS+
WCM
WCM DB

23. Portal Customer Experience – Steady State Comparison
Enabling WebSphere Content Manager Cache Offload Performance
Advanced Cache using an offloaded
eXtreme Scale/XC10 grid cache
With WXS/XC10 average throughput in our 100
steady state/concurrent user scenario was
90
consistently faster than with Default No WCM Advanced
80 Cache
Advanced Cache WCM Advanced
42% improvement over no Advanced 70
Cache Offloaded to
Cache in our scenario 60 XC10
50
24% throughput improvement over Throughput(requests/second)
default cache implementation
using Application Server JVM heap
in our scenario
100
Using the Default Advanced Cache
implementation requires available 90
Default WCM
Application Server heap, offloading the 80 Advanced Cache
cache to WXS/XC10 does not require 70
WCM Advanced
Cache Offloaded to
heap 60 XC10
50
Throughput(requests/second)
Performance is based on measurements and projections
using standard IBM benchmarks in a controlled
environment. Actual performance in a user's
environment may vary.

24. Portal Customer Experience – Steady State Comparison
With WXS/XC10 average steady state Cache Offload Performance
response-times are consistently faster than
with Default WebSphere Content Manager 16
Advanced Cache 14
5.5 second improvement over no 12 No WCM Advanced
Cache
Advanced Cache in our scenario 10
WCM Advanced
8 Cache Offloaded to
3.4 second improvement over default XC10
6
cache implementation using
4
Application Server JVM heap in our Response Time(seconds)
scenario
16
Performance is based on measurements and 14
projections using standard IBM 12 Default WCM
benchmarks in a controlled environment. Advanced Cache
10
Actual performance in a user's WCM Advanced
8 Cache Offloaded
environment may vary. to XC10
6
4
Response Time(seconds)

25. Reducing Portal warm-up time – Cold Start Results
With WXS/XC10 average throughput of a Cache Offload Performance
newly started server is consistently
faster than with Default WebSphere
Content Manager Advanced Cache 90
54% throughput improvement in 80 Default
our scenario 70 Advanced
Cache
60
Advanced
50 Cache
With WXS/XC10 average response-times 40 Offloaded to
are consistently faster than with XC10
30
Default Advanced Cache Throughput(requests/second)
4 second improvement observed
in our scenario
16
With WXS/XC10 response times 14
improve faster due to quicker cache 12 Default
Advanced Cache
hydration 10
Advanced Cache
8 Offloaded to
XC10
6
Performance is based on measurements
and projections using standard IBM 4
Response Time(seconds)
benchmarks in a controlled
environment. Actual performance in a
user's environment may vary.

26. Summary of Primary Benefits
WCM Advanced Cache implemented through the DynaCache, stores fully rendered
pages that do not have to be pulled out of WCM DB. Today customers can enable
Advanced Cache in the app server’s heap space. Technical goal is to avoid trips
back to the WCM database to avoid building these pages. WXS plugin allows you
to store the DynaCache content in a remote grid, so that the data being inserted
into DynaCache does not consume app server heap space.
1. Caching is of highest importance with WCM. Complex WCM components
can be very CPU intensive
2. WXS grid can store more data, have a larger hit percentage than
DynaCache and reduce trips to WCM DB which is more expensive. (More
consistent Response times)
3. Benefits customers who are heaped constrained (no DynaCache) can
leverage the Advanced Cache by not committing memory on their Portal
server. The WXS scenario does not consume memory on the Portal
server.
4. Shared cache, each portal JVM does not have to warm its cache on server
restarts
5. Eliminates invalidation chatter.. critical in the farm topology

27. Legal disclaimer
© IBM Corporation 2013. All Rights Reserved.
The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided
AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be
responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any
warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software.
References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this
presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing
contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results.
If the text contains performance statistics or references to benchmarks, insert the following language; otherwise delete: Performance is based on measurements and projections using standard IBM benchmarks in a
controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user's job
stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.
If the text includes any customer examples, please confirm we have prior written approval from such customer and insert the following language; otherwise delete: All customer examples described are presented as
illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer.
Please review text for proper trademark attribution of IBM products. At first use, each product name must be the full name and include appropriate trademark symbols (e.g., IBM Lotus® Sametime® Unyte™).
Subsequent references can drop “IBM” but should include the proper branding (e.g., Lotus Sametime Gateway, or WebSphere Application Server). Please refer to http://www.ibm.com/legal/copytrade.shtml for
guidance on which trademarks require the ® or ™ symbol. Do not use abbreviations for IBM product names in your presentation. All product names must be used as adjectives rather than nouns. Please list all of the
trademarks that you use in your presentation as follows; delete any not included in your presentation.Please review text for proper trademark attribution of IBM products. At first use, each product name must be the full
name and include appropriate trademark symbols (e.g., IBM Lotus® Sametime® Unyte™). Subsequent references can drop “IBM” but should include the proper branding (e.g., Lotus Sametime Gateway, or
WebSphere Application Server). Please refer to http://www.ibm.com/legal/copytrade.shtml for guidance on which trademarks require the ® or ™ symbol. Do not use abbreviations for IBM product names in your
presentation. All product names must be used as adjectives rather than nouns. Please list all of the trademarks that you use in your presentation as follows; delete any not included in your presentation.
If you reference Adobe® in the text, please mark the first use and include the following; otherwise delete: Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of
Adobe Systems Incorporated in the United States, and/or other countries.
If you reference Java™ in the text, please mark the first use and include the following; otherwise delete: Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
If you reference Microsoft® and/or Windows® in the text, please mark the first use and include the following, as applicable; otherwise delete: Microsoft and Windows are trademarks of Microsoft Corporation in the
United States, other countries, or both.
If you reference Intel® and/or any of the following Intel products in the text, please mark the first use and include those that you use as follows; otherwise delete: Intel, Intel Centrino, Celeron, Intel Xeon, Intel
SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
If you reference UNIX® in the text, please mark the first use and include the following; otherwise delete: UNIX is a registered trademark of The Open Group in the United States and other countries.
If you reference Linux® in your presentation, please mark the first use and include the following; otherwise delete: Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Other
company, product, or service names may be trademarks or service marks of others.
If the text/graphics include screenshots, no actual IBM employee names may be used (even your own), if your screenshots include fictitious company names (e.g., Renovations, Zeta Bank, Acme) please update and
insert the following; otherwise delete: All references to [insert fictitious company name] refer to a fictitious company and are used for illustration purposes only.
27 © 2013 IBM Corporation

28. Back-Up Slides
© 2013 IBM Corporation

29. Related Key Features in Recent WXS Release (8.6)
• eXtremeIO (XIO)
• Replaces Object Request Broker (ORB)
• More efficient transport layer
• eXtreme Data Format (XDF)
• Serializes data for sharing between Java and C#/.NET applications.
• Index data on server without requiring user classes to be present.
• Automatic Versioning of classes
• Portal Farm Impacts
• Further performance improvements possible with XIO.
• The elimination of data serialization requirements will broaden Portal
caches that are appropriate for offload to WXS.
29

30. Cache Instance Configuration

31. DynaCache Instance Configuration

32. Portal Advanced Cache
DynaCache instance used to store rendered content
Specifically content pulled from a Web Content Manager database
Configuration used
Site level caching (rendered content)
30 day expiration
Do not clear cache on startup

33. So, what are eXtreme Scale and XC10
anyway?
33

34. IBM WebSphere eXtreme Scale
• Proven mature product:
– Fourth major release of product with V7.1
– Public References
– Private References
– Used at some of the largest web
sites/companies in the world
• Lightweight runtime footprint (20MB jar)
• Integrates with all versions of WebSphere and
almost any Java-based application container or
Java Virtual Machine
• Proven multi-data center capabilities
• Proven low-latency access to data

35. IBM WebSphere DataPower XC10 V2
 New Form Factor (2U)
 Larger Cache (240 GB)
 Better Performance (Faster SSD, Use of RAM)
 Improved monitoring (SNMP Support)
 Support for non-Java Applications (REST Gateway)
 Grid Capping

36. Utilizing WebSphere DataPower XC10 for DynaCache
Clients can attach to the
‘cache’ using the network
No dependency on a large
file system cache.
No disk dependency, no SAN
required.
Network
Cache is as large as the
XC10 Collective memory in the ‘grid’.
Each record is stored once in
the grid and shared by all
clients.
36

37. HTTP Session data cache
 No new code required
 Extension of legacy session management caching
mechanism in WebSphere Application Server
 Extensions to WebSphere Application Server
administrative console to support WebSphere
DataPower XC10 session management caching
and WebSphere eXtreme Scale session
management caching
 WebSphere Application Server connects
seamlessly to the WebSphere DataPower XC10
appliance or WebSphere eXtreme Scale
– Client code must be installed on WebSphere
Application Server systems
 Easily configure WebSphere applications to store
HTTP session data to a data cache on the
WebSphere DataPower XC10 appliance through
the WebSphere Application Sever administrative
console
 Replaces other session replication mechanisms
(memory-to-memory replication)
 Removes the need for Database traditionally used
for persistence
 Enables HTTP session failover between
WebSphere Application Server cells
37

38. Farming: Shared installations & Session caching
•Ability to share the profile & persist session
Manage the life cycles of HTTP sessions that are associated with the application
Improve QoS and Lower Memory footprint
Better guarantees of session availability during server failover
Topology spans multiple data centers across different physical locations
Elastic Cache
DataPower XC10