This is the introduction to datagrid plus use cases pitch that I give now to customers.

1. XTP using WebSphere
eXtreme Scale
@billynewport
IBM Distinguished Engineer

2. © IBM 2010, @billynewport
Agenda
• Gentle introduction to DataGrids
• General usage Patterns
• What they are good for and bad for
• Customer use cases
2

3. © IBM 2010, @billynewport
Traditional Cache Operation
App
App
App
App
EIS
A
A
A
A
App
Invalidationchatter
Invalidationchatter
3

4. © IBM 2010, @billynewport
WXS based Cache Operation
App
App
App
App
EIS
A
B
D
C
C’
D’
A
A
AppA
B’
A’
Cache is
4x larger!
Cache is
5x larger!
Cache cluster can be co-located with the application or run
in it’s own tier.
4

5. © IBM 2010, @billynewport 5
First, what’s a cache?
●
A database cache? A page fragment cache? A service Cache?
TOO SPECIFIC!
•
A cache is a tool for reducing application path length
•
OR the distance data has to travel before it gets to the
customer/ data sink
DB
OR
Map
Logic
Data
Service
Web
Channel
Mobile
Channel
Akamai

6. © IBM 2010, @billynewport 6
Customer Diversity
Data Grids are not just for investment banks!
• Retailers
• Insurance Companies
• Health care
• Retail Banking
• Hotel
• Travel Agencies
• Investment
Banking
• Telco
• Government
• Utilities
• Trucking
Companies
6

7. © IBM 2010, @billynewport 7
Market Drivers
1. “The Performance of Web Applications: Customers Are Won or Lost in One Second,” Bojan Simic, Aberdeen Group, November 2008.

8. © IBM 2010, @billynewport 8
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

9. © IBM 2010, @billynewport 9
Market Drivers
• Customers are looking to control the growth of
their enterprise systems.
– A caching tier in front of it can allow more growth
without expanding the existing enterprise systems.
• Customers are looking at building front ends
more independent from the back ends.
• Public and private cloud like systems will need
elastic state management solutions such as IBM
WebSphere eXtreme Scale.
• More resilient front ends decoupled from back
ends.

10. © IBM 2010, @billynewport 10
IBM WebSphere eXtreme Scale
• Proven mature product:
– Third major release of product with V7.0
– Public References
– Private References
– Used at some of the largest web
sites/companies in the world
• Lightweight runtime footprint (15MB 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

11. © IBM 2010, @billynewport 11
Common set of patterns
• Side Cache
– Hibernate/ OpenJPA L2 cache
– Dynacache (ND 6.1/ ND 7.0)
• Page fragment cache
• Web services cache
• Command cache
– SOA State store
– SOA Result cache
11
AppAppAppApp

12. © IBM 2010, @billynewport 12
Common set of patterns
• Inline backend cache
– Loaders used to integrate
with an existing data service
– Read through cache
– Write through cache
• System of Record Data
Store
– Cache is used as the system
of record
– Write behind technology
pushes changes
asynchronously to the
backend.
12
AppAppAppApp
Loader

13. © IBM 2010, @billynewport 13
Common set of patterns
• HTTP Session Store
– Application uses standard HTTPSession APIs
– Can be shared between applications sharing same
domain name
– Grid runs inside web cluster JVMs using affinity
• Application Session
– Application uses WXS APIs to manipulate the shared
session
– Works even when web apps use different domain
names
• Multi data center support for sessions
13

14. © IBM 2010, @billynewport 14
Common set of patterns
• XTP (eXtreme Transaction Processing)
– Lowest possible latency
– Application code runs in grid itself
• Think Grid + Stored Procedures
– Write behind
• Databases relegated to durable log/search and
reports
14
14

15. © IBM 2010, @billynewport
CRUD Evolves with KV or NoSQL stores
• Traditionally, we think of the big four
operations:
– (C)reate
– (R)ead
– (U)pdate
– (D)elete
15
• This changes now to become:
– (P)ut
– (R)etrieve by key
– (D)elete
– ** (Q)uery (this is different than search)

16. © IBM 2010, @billynewport
Schema becomes more flexible
• Traditionally, the data store understands the data
schema and enforces constraints.
• KV or NoSQL separates the schema management
from the storage.
– Schema is more like a JSON value
– Developers more in control
– More flexible to evolve than SQL oriented approach
– Remember, it’s about retrieval, not query/search!
16

17. © IBM 2010, @billynewport
SQL Benefits
• Relationships through joins
• Easy indexing
• No consistency issues, one copy/system of
record
• No need to partition data model.

18. © IBM 2010, @billynewport
SQL means domain centric
• Think about the data, find the nouns
• Nouns become tables
• identify attributes/keys
• normalize the tables to Nth normal form…

19. © IBM 2010, @billynewport
Domain centric
• Use SQL to ask any question
• Use indexes to speed up SQL queries.
• Think Data Model first, worry about
questions/access patterns later.

20. © IBM 2010, @billynewport
Question Centric
• NoSQL seems to start with the questions
rather than the data.
• Once we know the questions then we can
layout the data using some partitioned
model.
• We can now scale it out and all is good
What could you do if scale wasn’t an issue?

21. © IBM 2010, @billynewport
Question Centric
Ask a different question maybe?

22. © IBM 2010, @billynewport
Table scans aka Map/Reduce…
• Multi-machine table scans won’t work for
anything online.
–Google doesn’t map/reduce for every
google search!
• Offline complex queries can be done using
Map/Reduce
• You need to write code for most complex
searches!

23. © IBM 2010, @billynewport
SOME USE CASES
23

24. © IBM 2010, @billynewport 24
Client Usage: One of the largest retail US banks
Retail Banking & Investments
35x
reduced
response
times
22 Million
online banking users
Next-generation Online Banking
–
Before: 700ms to login with 2 backend calls
–
After: 20ms to login with profile cache access
–
$6M/year cost savings in MIPs reduction
–
700k logins per hour across 3 data centers
–
8Gb of data transfer per hour between DC’s
–
60 million page views/day
–
10 million logins per day
–
3 active data centers
$500k
reduced
costs per
month
20x
reduction
in “lost
sessions”

25. © IBM 2010, @billynewport 25
Session Persistence Results
Sample chart that shows response gains with Session &
without Session persistence changes.

26. © IBM 2010, @billynewport 26
Market Drivers
1. “The Performance of Web Applications: Customers Are Won or Lost in One Second,” Bojan Simic, Aberdeen Group, November 2008.
2
seconds

27. © IBM 2010, @billynewport 27
Session Persistence Results
•
Data represents the number of Session Recovery events logged each day
•
Key dates:
•
5/30, Session Recovery turned on & available for 60% of customers
•
Rollouts on 6/13 (to 80%) and 6/20 (to 100%)
•
Very high volume day on 6/15

28. © IBM 2010, @billynewport 28
Client Usage: Telco Mobile Application
Load profile for cell phone
3ms
Response time
160 million customers
46k tps
Mobile phone profile/feature checking
–
Before: DBMS uses to read profile. Mobile
applications and web sites generate too much
load.
–
After: 3.1ms response time. 46k profile look ups
per second.
–
Data distributed amongst several data centers
using the grid.
Linear
Scaling for
more
throughput

29. © IBM 2010, @billynewport 29
Client Usage: eCommerce Retailer
Catalog page cache
1k page views/sec
Faster startup
JVM restarts are nondisruptive
Cache consistency
One of the largest ecommerce sites
–
Before: Existing WebSphere Commerce Server
customer.
–
Per JVM catalog cache lead to lots of memory
wastage and cache warming problems on cluster
start as well as JVM restarts
–
After:
–
Moving to a shared cache using WXS, speeds
cluster start time by 60%
–
customer response times see no impact from JVM
restarts.
–
Memory is dramatically reduced.
–
Catalog consistency is better (time based
promotions)
–
Less CPU used

30. © IBM 2010, @billynewport 30
Entertainment
10x
reduced
response
times
7 Billion
requests per day
Fantasy Sports Web Infrastructure
–
Before: 60ms response time against database
–
After: WXS improved to 6ms response time
–
450k concurrent users
–
80k requests per second up to 1M in 2011
–
6 weeks from concept to production
Client Usage: Social Media Website
Oracle
ORMWXS
App ORMWXS
ORMWXS

31. © IBM 2010, @billynewport 31
Client Usage: Investment Bank
Investment Banking
4x
increase in
revenue
12 Million
orders per day
Next-generation Order Management System
–
Before: Oracle RAC based architecture unable to
scale to necessary demands
–
After: 300K transactions / day  12M / day
–
Revenue up 4X and growing … “all because of
WebSphere eXtreme Scale”
–
Response time drops to 2.5ms
–
Moving to “22 x 7” operations (more than 9AM -
4PM)
40x
number of
transactions
supported

32. © IBM 2010, @billynewport 32
Client Usage: Insurance Company (SOA Result Cache)
Insurance Policies
reduced
response
times
125,000
policies concurrently
processed
Reduce Database Processing
–
Before: Changes to policies required time consuming
and costly access to multiple databases (e.g. drivers,
accident history, previous claims, etc.)
–
After: Construct policy once, from multiple data
sources, for fast access (in-memory) and fault
tolerance (using replication)
–
Policies can be processed for up to 1 hour +
–
100 requests / second
–
1 MB of XML per policy, ¼ terabyte stored in cache
reduced
costs per
month
better
availability

33. © IBM 2010, @billynewport 33
Client Usage: Travel Web Site
Holiday Inventory
reduced
response
times
2,500,000
Package combinations
Improve response times
–
Before: Database cached inventory from SAP
system
–
After: Cache allows faster searches and reductions
in load on SAP system
reduced
costs per
month
(SAP)
better
availability

34. © IBM 2010, @billynewport 34
Client Usage: Investment Bank Global Risk Management
reduced
response
times
250,000 40ms
Counterparties SLA
Handle peaks
–
Before: Database held risk information information,
batch daily exposure calculation
–
After: Data held in memory, Monte Carlo exposure
calculations, multi-master global replication.
–
Multiple Global Data centers (US, Asia, Europe),
executing trades concurrently against counterparty
risk limits.
–
Local grids in each data center allow fast responses
versus centralized repository
–
Multi-master asynchronous replication between data
centers provides consistency.
Handles
peaks
better
Authorize trades
Higher
profits

35. © IBM 2010, @billynewport 35
Client Usage: Investment Bank
Stock price service
reduced
response
times
200,000
Prices updates/sec
Handle dramatic volume increases
–
Provides latest and 20 minute old prices for each
stock
–
Before: Z/390 application using VSAM kept latest
and 20 minute old price for each stock
–
After: WXS Grid maintains the same data.
–
200k stocks
–
200k price update/sec
–
20k price lookups/day
reduced
costs per
month
better
availability

36. © IBM 2010, @billynewport 36
Client Usage: Investment Bank
Algorithmic Trading
reduced
response
times
144 cores
2m TPS @ 800uS
Handle dramatic volume increases
–
Grid is system of record for algo trading application
which runs embedded
–
Before: Home grown infrastructure
–
After: 144 cores hosting application. 800uS response
time 90% of time. 4 WXS transactions for each
response. Approx 2m tps at peak possible.
800uS
24/7

37. © IBM 2010, @billynewport 37
Client Usage: Insurance company – SOA Result Cache
Mainframe service calls
reduced
response
times
25% reduction
Reduce mainframe spend
–
Before: All service calls went to mainframe
–
After: 25% of calls are serviced using results from
prior invocation within 24 hours.
–
25% reduction in backend transaction costs using a
cache to intercept calls on an ESB.
reduced
costs per
month
CICS
ORMWXS
App ORMWXS WXS
Filter
ESB

38. © IBM 2010, @billynewport 38
Client Usage: Trucking company
HTTP Sessions in DB/390
reduced
response
times
HTTP Sessions were stored in DB/390
–
Before: All session persistence used DB/390
–
After: All session persistence provided by
WebSphere eXtreme Scale.
–
Significant reduction in application response time
–
Reduction in MIPS cost on 390.
reduced
costs per
month

39. © IBM 2010, @billynewport 39
Client Usage: Telco LDAP caching
Cache LDAP Directory
reduced
response
times
Credential or data is stored in an LDAP directory
–
Before: Slow access to data in LDAP (84ms),
Complex striped LDAP server arrangement.
–
After: Sub millisecond access to same data stored in
WXS.
–
Significant reduction in application response time
–
Smaller LDAP infrastructure.
reduced
costs per
month

40. © IBM 2010, @billynewport 40
40
So how do I get started?
40

41. © IBM 2010, @billynewport 41
41

Two New Service Offerings
1. IBM Project Discovery Workshop for WebSphere eXtreme Scale
2. IBM QuickStart for WebSphere eXtreme Scale

ibm.com/developerworks/websphere/services/contacts.html

WebSphere Education

ibm.com/software/websphere/education/

YouTube IBM eXtreme Scale channel

youtube.com/ibmextremescale

DeveloperWorks Blog for XTP Community

ibm.com/developerworks/mydeveloperworks/blogs/xtp/?lang=en_us

Follow us on Twitter

twitter.com/WebSphereXTP

WebSphere eXtreme Scale V7 Solution Architecture Redbook

redbooks.ibm.com/redpieces/abstracts/redp4602.html

Download Replay and Presentation

ibm.com/developerworks/websphere/services/buzztalk.html

Contact your IBM Representative
41
Getting Started

42. © IBM 2010, @billynewport 42
Learn More About Dynamic Application
Infrastructure!
Application Foundation
ibm.com/appfoundation
Intelligent Management
ibm.com/intellmgmt
Extreme Transaction Processing
ibm.com/xtp
ibm.com/appinfrastructure

43. © IBM 2010, @billynewport 43
43