2018 jk

© 2013 IBM Corporation

2018 Designing a Scalable and High Performing Portal Infrastructure Hide Details

James Krueger – WXS DevelopmentNitin Gaur – Application Infrastructure and Mobility

With Thanks toBenjamin Parees – WXS DevelopmentPaul Chen – WXS Development

2 © 2013 IBM Corporation

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.

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 © 2013 IBM Corporation

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

Portal Topology : Conventional or Farm?


Conventional Topology Portal Farm Topology

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

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.

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 usageNo synchronized configuration (without the aid of file system utilities)No coordinated task schedulingNo 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

Why Choose Farming?

•Farming is a simple architecture with just a series of identical stand-alone portal instances with load balanced by a HTTP plug-in or any load balancer

•Server farms are effective way to build and maintain a highly scalable, highly available server environment

•Farms allows Dynamic Server Expansion and contraction of size without complex cluster configurations which are usually time consuming

•Sourcing additional servers using cloning or virtualization is very rapid. With WP7 Shared configuration it is much more rapid and simple

•Client had a very tight maintenance window. 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.

Unique install Portal Farm

Requests

LB

Portal

Node

Portal1

Node

Portal1

Node

REL JCR

CUS COM

REL JCR REL JCR

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

11

Web Tier

Portal

App Tier

DB Tier

Gateway Security

A Client

SILO

Web Tier

Portal

App Tier

DB Tier

Gateway Security

A Client

SILO

Web Tier

Portal

App Tier

DB Tier

Gateway Security

A Client

SILO

Web Tier

Portal

App Tier

DB Tier

Gateway Security

A Client

SILO

Web Tier

Portal

App Tier

DB Tier

Gateway Security

A Client

SILO

57K Clients

Web Tier

Portal

App Tier

DB Tier

Gateway Security

A Client

SILO

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?

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


Elastic Caching minimizes the impact of Transaction Overload

Web Server Tier Back-end SystemsDatabase Tier

App Server Tier Elastic Cache

IBM HTTP ServerWebSphere

Application ServerDB2 UDB

Improve Performance, Scalability & Availability

Highly Scalable Web Applications

Data-intensive Applications

Extreme Performance

14

Innovative Elastic Caching Solutions

“Data Oriented”

“Application Oriented”

Session management

Elastic DynaCache

Web side cache

Event Processing

In-memory OLTP

Worldwide cache

Petabyte analytics

Data buffer

In-memory SOA

eXtreme Scale

DataPower XC10 Appliance

• Ultimate flexibility across a broad range of caching scenarios

• In-memory capabilities for application oriented scenarios

• Drop-in cache solution optimized and hardened for data oriented scenarios

• High density, low footprint improves datacenter efficiency

Elastic caching for linear scalabilityHigh availability data replication

Simplified management, monitoring and administration

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

During a recent ‘News’ application promotion, the 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…

Welcome, User!

!#*!

… too slow!

DynaCache disk-offload




WPS

News Portlet Deployment - Failure

WPS

WPS

WPS

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

Welcome, User!

WXS

Elastic cache

WPS

WPS

WPS

WPS

During a recent ‘News’ application promotion, the customer response to the new portlet was very high. However, with addition of an elastic cache the web-site was able to handle the significant increase in load. The customers did not perceive any slow down of the web-site. The result, happy customers and a successful content promotion…

News Portlet Deployment - Success

With WXS DynaCache Grid configured, disk-offload is no longer required

Welcome, User!

WXS

Elastic cache

WPS

WPS

WPS

WPS

Fast start-up when adding more capacity – on the fly

WPS

New Server

New WebSphere Portal servers can be brought on-line quickly to meet increased capacity needs. When start-up is complete, the new server has immediate access to a warm cache provided by eXtreme Scale.

Welcome, User!

WXS

Elastic cache

WPS

WPS

WPS

WPS

Maintain consistent user experience during site maintenance

WPS Down for maintenance

If a WebSphere Portal server needs to be restarted after applying an iFix, eXtreme Scale can provide up to 54% improvement in time to reach steady-state

Scenario Details

Two Portal Servers with Web Content Manager

Single WCM DB Server

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)

300 concurrent users simulating Wiki/Blog accesses

Web Content Manager DB content: 50 gigs

WPS+WCM

WPS+WCM

WCM DB

2 XC10 Collective

Proxy

Portal Customer Experience – Steady State Comparison

Enabling WebSphere Content Manager Advanced Cache using an offloaded eXtreme Scale/XC10 grid cache

With WXS/XC10 average throughput in our steady state/concurrent user scenario was consistently faster than with Default Advanced Cache

42% improvement over no Advanced Cache in our scenario

24% throughput improvement over default cache implementation using Application Server JVM heap in our scenario

Using the Default Advanced Cache implementation requires available Application Server heap, offloading the cache to WXS/XC10 does not require heap

Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. Actual performance in a user's environment may vary.

Throughput(requests/second)50556065707580859095

100

Default WCM Advanced Cache

WCM Advanced Cache Offloaded to XC10


100

No WCM Advanced Cache


Cache Offload Performance

Portal Customer Experience – Steady State Comparison

Cache Offload PerformanceWith WXS/XC10 average steady state response-times are consistently faster than with Default WebSphere Content Manager Advanced Cache

5.5 second improvement over no Advanced Cache in our scenario

3.4 second improvement over default cache implementation using Application Server JVM heap in our scenario


Response Time(seconds)4

6

8

10

12

14

16

No WCM Advanced Cache



6

8

10

12

14

16

Default WCM Advanced Cache


Reducing Portal warm-up time – Cold Start Results

With WXS/XC10 average throughput of a newly started server is consistently faster than with Default WebSphere Content Manager Advanced Cache

54% throughput improvement in our scenario

With WXS/XC10 average response-times are consistently faster than with Default Advanced Cache

4 second improvement observed in our scenario

With WXS/XC10 response times improve faster due to quicker cache hydration


Cache Offload Performance


40

50

60

70

80

90

Default Advanced Cache

Advanced Cache Offloaded to XC10


6

8

10

12

14

16

Default Advanced Cache

Advanced Cache Offloaded to XC10

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 intensive2. 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.

Back-Up Slides


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.

Cache Instance Configuration

DynaCache Instance Configuration

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?

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

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.

Cache is as large as the memory in the ‘grid’.

Each record is stored once in the grid and shared by all clients.

Network

XC10 Collective

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

•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

Farming: Shared installations & Session caching

Elastic Cache DataPower XC10

2018 jk

Documents

Transcript of 2018 jk