This presentation was made by Emad Benjamin of VMware Technical Marketing. Normally I wouldn't upload someone else's preso but I really insisted this get posted and he asked me to help him out.
This deck covers tips and best practices for virtualizing latency sensitive apps on vSphere in general, and takes a deep dive into virtualizing vFabric GemFire, which is a high-performance distributed and memory-optimized key/value store.
Best practices include how to configure the virtual machines and how to tune them appropriately to the hardware the application runs on.
2. Agenda
The Data Challenge and Latency Sensitive Workloads
VMware vFabric Cloud Application Platform
High Performance Data with vFabric GemFire
Primary GemFire Topologies and Usage
Design and Sizing
Best Practices
Customer Case Study
Next Steps
2
4. Data Challenges in Modern Application Architectures
Explosive data growth
• 60% year over year
Bridging data supply with data demand
• Indeterminate user load, 24x7 access, new device types driving increased
application use
Business challenges
• How to outpace competitors by delivering superior service and experience
IT challenges
• Scalability
• Performance
• Data reliability
• Geographic distribution
4
5. Latency Sensitive
10ms to 100ms matter?
• Then this is a latency sensitive application
• High chatter between VMs – many small data packets – many updates
5
9. Your Apps Are Cloud-Friendly… but What About Your Data?
“ The big glaring hole [with cloud]
is data handling.
” -Adrian Kunzle, MD
Head of Engineering & Architecture, JPMorgan Chase
File Systems Databases Other Systems
9
11. What is VMware vFabric GemFire?
Data moves to the middle tier
• Closer to where it is needed
Scalability
• Easily accommodate more
application users
High performance
• Dramatic application performance
gains – execute from memory
Data reliability
• Data written through or behind
to disk
Geographic distribution
• WAN connectivity
11
12. vFabric GemFire in a Nutshell
Enterprise Data Consuming Applications
Reliable Event Notification Continuous Querying Parallel Execution Data Durability
High Throughput Low Latency High Scalability Continuous Availability WAN Distribution
vFabric GemFire Data Fabric
Conventional Data Storage Systems
File Systems Databases Other Data Systems
12
13. Enabling Extreme Data Scalability and Elasticity
Primary Use Cases
Web session cache, L2 cache
• Shopping cart state management
App data cache, in-memory DB
• High performance OLTP
Application Data Grid data fabric: client compute
Lives Here • Shared data grid accessed by many
clients executing app logic
Grid data fabric: fabric compute
• Shared data grid where app logic is
executed within the data fabric itself
Application Data
Sleeps Here
File Systems Databases Mainframes/other
13
14. GemFire Features
Java, C++, .NET
Update Update Java, C++, .NET
Rich objects Request
Ultra-low latency RAM durability
Elastic growth without pausing Regions
Customers Java
Customer
Partitioned active data Orders
Java O-R Mapper Java O-R Mapper
Redundancy for instant FT Redundant Copies Address
Co-located active data Products
Street
Promotions
Replicated master data OQL OQL
OQL
City
Ultra-fast co-located transactions
Distributed transactions* Preferences
Server-side event listeners
Client-side durable subscriptions
Parallel MapReduce function execution
Parallel OQL queries
Continuous queries
LRU overflow to disk in native format for fast retrieval
Parallel, shared nothing persistence to disk with online backup
Synchronous or asynchronous write-through, read-through
Uni- or bi-directional cluster synchronization over WAN * Available in v 7.0
14
16. Primary GemFire Topologies
Peer-to-peer
• Intercommunicating set of vFabric GemFire servers that do not have clients
accessing them
• For example, back office, or backend type of processing
Peer Peer
GemFire Server 1 GemFire Server 2
16
17. Primary GemFire Topologies
Client/Server is the most common topology used in practice
Client Tier
Standalone Standalone Standalone Standalone
Client Cache 1 Client Cache 2 Client Cache 3 Client Cache 4
GemFireServer 1 GemFire Server 2
Server Tier
17
18. Primary GemFire Topologies – Global Multisite Standby Gateway
Paths
GemFire
GemFire GemFire2 5
1 Standby Standby GemFire6
Gateway Gateway
GemFire3 GemFire4 GemFire8
GemFire7
Gateway Gateway
New York Site Tokyo Site
GemFire12
Standby GemFire9
Gateway Gateway Primary Gateway
Paths
GemFire 11 GemFire 10
London Site
18
22. Design and Sizing – Three Basic Steps
Step 1 Step 2 Step 3
Determine vFabric Benchmark vertical Benchmark horizontal
GemFire server JVM scalability to scalability to
heap size needed to determine VM size for determine how many
house region data for GemFire server vFabric GemFire
both RR and PR needed for the servers are needed in
regions building-block VM a cluster
22
23. Design and Sizing – Understanding JVM Memory Segments
VM
Memory
for Guest OS
GemFire Memory
-Xss per thread
Direct
Java Stack
Native
Other mem Memory
JVM
Memory Perm Gen -XX:MaxPermSize
for
GemFire Non
Direct
JVM
Memory
Max
Heap Virtual
-Xmx Initial -Xms Address
Heap Space
23
24. Design and Sizing – Understanding JVM Memory Segments
VM Memory for GemFire = Guest OS Memory + JVM Memory for GemFire
JVM Memory for GemFire =
JVM Max Heap (-Xmx value) +
JVM Perm Size (-XX:MaxPermSize) +
NumberOfConcurrentThreads * (-Xss) + ―other Mem‖
Guest OS Memory approximately 0.5-1G (depends on OS/other
processes)
Perm Size is an area additional to the –Xmx (Max Heap) value and
is not GC-ed because it contains class-level information.
“other mem” is additional mem required for NIO buffers, JIT code
cache, classloaders, socket buffers (receive/send), JNI, GC internal
info
24
25. Design and Sizing – Step 1: Calculating Region Data
Formula 1
TotalMemoryPerGemFireSystemWithHeadRoom = TotalMemoryPerGemFireSystem * 1.5
Formula 2
TotalMemoryPerGemFireSystem =
TotalOfAllMemoryForAllRegions +
TotalOfAllMemoryForIndicesInAllRegions +
TotalMemoryForSocketsAndThreads
Formula 3
NumberOfGemFireServers=NumberOfVMsInSystem=
NumberOfJVMsInSystem= TotalMemoryPerGemFireSystemWithHeadRoom / 32GB
25
26. Design and Sizing – Step 1: Calculating Region Data (cont.)
Formula 4
ApproxServerMachineRAM=
TotalMemoryPerGemFireSystemWithHeadRoom *
(DataLossTolerancePercentage/ (NumberOfRedundantCopies +1) )
26
27. Design and Sizing – Step 1: Calculating Region Data (cont.)
Set mem reservation to
31955m or set to Active
VM
memory used by VM which
Memory
Guest OS could be lower
for
GemFire Memory
500m used by OS
(31955)
Java Stack -Xss per thread (192k*100)
JVM
Memory
for Other mem (=1484m)
GemFire Perm Gen -XX:MaxPermSize (256m)
(31455m)
JVM Max
Heap Initial
-Xmx Heap
(29696m) -Xms (29696m)
27
28. What is the practical limit for JVM Memory sizing (not to scale)
Most limiting practical sizing
64 bit Java factor is the per NUMA node
Theoretical RAM
Limit
Guest OS
Limit
1 to 16 TB ESX5i limit
32vCPU
16 Exa Bytes 1TB RAM Physical
Server
limit
~256G Per NUMA
<1TB RAM
28
29. Design and Sizing – NUMA Considerations
NUMA Node Local Mem = Total RAM on Server/Number of NUMA nodes
For Example 1
• Assume 2 sockets server with 8 cores (8pCPU) and total of 196GB RAM
• This server has 2 NUMA nodes
• Each NUMA node will have 196GB/2=> 98GB RAM
• Hence the largest sized virtual machine should not exceed 8vCPU and 98GB
RAM
For Example 2
• 2 sockets quad core on each socket (4pCPU) and total of 64GB
• Each NUMA node would get 64/2=> 32GB
• Hence the largest GemFire virtual machine should be sized as 4vCPU and
32GB RAM
29
30. 2vCPU VMs
Less than
ESX 32GB RAM
on each VM
Scheduler
Each NUMA
Node has 128/2 128 GB RAM
64GB on Server
31. 4vCPU VM
2vCPU VMs
Less than
ESX 32GB RAM
on each VM
Scheduler
Split by ESX into
2 NUMA Clients
ESX4.1
Each NUMA
Node has 128/2 128 GB RAM
64GB on Server
32. 4vCPU VMs
Less than
32GB RAM
on each VM
Each NUMA
Node has 128/2 128 GB RAM
64GB on Server
33. Step 2 and Step 3: Establish Benchmark Vertical Scalability
ESTABLISH vFabric GemFire Investigate bottlenecked
Vertical scalability Test
BUILDING BLOCK VM layer
Size within NUMA boundaries of Network, Storage,
ESX host Application Configuration,
Establish JVM Heap Size and vSphere
Size the Building Block VM that
houses vFabric GemFire Server
Building Block If horizontal scaling
If building block
VM is bottlenecked
app/VM config
mitigate, and
problem, adjust
iterate scale out
and iterate No
test
Test
complete
Step 3 – Iterative Horizontal Scalability
DETERMINE HOW MANY VMs SLA
Horizontal Scalability Test Establish Horizontal OK?
ScalabilityScale Out Test
How many VMs do you need to
Building Block Building Block meet your Response Time
VM VM SLAs without reaching
70%-80% saturation of CPU?
Establish your Horizontal
scalability Factor before
bottleneck appear in your
application
33
34. Design and Sizing – Step 1: Calculating Region Data (cont.)
Formula 6 – for Global Multisite Topology
Maximum Throughput (bits/second) =
TCP-Windows-Size In Bits / Round Trip Latency in Seconds
Use WAN accelerators
34
36. vFabric GemFire on VMware – Best Practices
Best Practices paper here:
• http://www.vmware.com/resources/techresources/10231
vFabric GemFire on VMware
• Set appropriate memory reservation
• Leave HT enabled, size bases on vCPU=1.25pCPU if needed
• RHEL6 and SLES 11 SP1 have tickless kernel that does not rely on a high
frequency interrupt-based timer, and is therefore much friendlier to virtualized
latency-sensitive workloads
• Do not overcommit memory
36
37. vFabric GemFire on VMware – Best Practices
vFabric GemFire on VMware
• Put vSphere Distributed Resource Scheduler (DRS) in manual mode
• Locators process should not be VMware vSphere® vMotion® migration, it
otherwise would lead to network split brain problems
• vMotion over 10Gbps when doing scheduled maintenance
• Disable VMware HA
• Use Affinity and Anti-Affinity rules to avoid redundant copies on the same
VMware ESX®/ESXi host
37
38. vFabric GemFire on VMware – Best Practices
data Many enterprise apps
consuming data
GemFire VM
from GemFire and
running within
running within
NUMA boundary
NUMA boundary
38
39. vFabric GemFire on VMware – Best Practices
vFabric GemFire on VMware
• Disable NIC interrupt coalescing on physical and virtual NIC
• Extremely helpful in reducing latency for latency-sensitive virtual machines
• Disable virtual interrupt coalescing for VMXNET3
• It can lead to some performance penalties for other virtual machines on the ESXi host,
as well as higher CPU utilization to deal with the higher rate of interrupts from the
physical NIC
• This implies it is best to use dedicated ESX cluster for vFabric GemFire workloads
• All host is configured the same way for latency sensitivity and this insures non
GemFire workloads are not negatively impacted
39
40. vFabric GemFire on VMware – Best Practices
vFabric GemFire on VMware – JVM tuning
• Size with 50% headroom
• Use –XX:CompressedOops
• Use JDK 1.6.0_24 or later
• Set –Xms=-Xmx
• Use –XX:+UseConcMarkSweepGC low-pause collector and parallel Young
Generation
40
41. vFabric GemFire on VMware – Best Practices
vFabric GemFire on VMware – JVM tuning
• -XX:+DisableExplicitGC
• -XX:CMSInitiatingOccupancyFraction=<50-75>
• -Xmn 33% of –Xmx and ideally less than a range of 2GB
41
42. vFabric GemFire on VMware – Best Practices
vFabric GemFire on VMware – General
• All peer-to-peer members of the distributed system must have the same
version of vFabric GemFire
• Clients can be up to one major release behind. For example, any 6.x client
interoperates with any 6.x or 7.x server, but not with an 8.x server
• Set cache-server max-connections and max-threads
• Use GFMon and VSD tools for monitoring
• When troubleshooting performance problems, check to see you are not
impacted by SYN cookies
• SYN cookies are the key element of a technique used to guard against SYN
flood attacks. Daniel J. Bernstein, the technique's primary inventor, defines SYN
cookies as ―particular choices of initial TCP sequence numbers by TCP servers
42
44. Airline Industry
Client/Server topology Client Client Client
Re-architecture of their
main Web store
• To speed up search,
checkout/book process
In 2010 Next Gen
Session
Next Gen
Session
Next Gen
Session
Next Gen
Session
• 80+ million passengers carried Server Server Server Server
• 12B in revenue
Number of servers per data center 4
Number of JVMs per server 1
Heap Size per JVM 34GB
-Xms34G and –Xmx34G
Available heap memory per JVM 34GB
Available RAM per JVM 17GB
Includes 50% ratio for churn
Total RAM needed per data center 136GB
44
48. Consistency Model
Data Fabric Node Data Fabric Node Data Fabric Node Data Fabric Node
Data Fabric Node Data Fabric Node Data Fabric Node Data Fabric Node
Archival, OLAP and
Regulatory RDBMS
Synchronous consistency within the fabric
Database Node
Eventual consistency with archival database
Eventual consistency with other fabric instances
Storage Device
48
49. Memory-Based Performance
High vFabric GemFire uses memory on peer machines to make data
updates durable, allowing the updating thread to return 10x to
Performance 100x faster than updates written through to disk, without risking
any data loss. Typical latencies are in the few hundreds of
microseconds instead of tens to hundreds of milliseconds
vFabric GemFire can optionally write updates to disk,
or to a data warehouse, asynchronously and reliably
49
50. Cloud Ready
Elastic
Add or remove data servers
dynamically
Fabric is elastic so it can grow or shrink dynamically
with no interruption of service or data loss
50
51. Distributed Events
Active
• Targeted, guaranteed
delivery, event
notification, and
continuous queries
51
52. Partitioning and Co-Location Example
Counterparty Descriptions
Settlement Instructions
Netting Agreements
Replicated regions
model many-to-many
relationships
Data Fabric Node Data Fabric Node Data Fabric Node Data Fabric Node
Many-to-many, many-to-one, and one-to-many relationships can be modeled
Co-location of related data eliminates distributed transactions
All entities within the transaction are located on a single machine
Targeted procedures have all the data entities they need locally
52
53. Partitioning and Co-Location Example
Position Data
Trade Data
Market Data
Instrument Data
Rating Information
Partitioned Data
Partitioned regions
model one-to-many
and many-to-one
Data Fabric Node Data Fabric Node Data Fabric Node Data Fabric Node
Many-to-many, many-to-one and one-to-many relationships can be modeled
Co-location of related data eliminates distributed transactions
All entities within the transaction are located on a single machine
Targeted procedures have all the data entities they need locally
53
54. Parallel Queries
Parallel Batch Controller
or Client
Scatter-Gather (Map-Reduce)
Queries and Functions
54
55. Fault Tolerant, Data-Aware Function Routing
Data Aware Function
Targeted Batch Controller
or Client
vFabric GemFire provides ―data aware function routing‖—moving the
behavior to the correct data instead of moving the data to the behavior
55
56. Multisite Capability
Active Everywhere
Data replication for
disaster recovery is
done with the fault-
tolerant, bi-directional
shared-nothing, store-
and-forward gateways
56
57. Data Distribution
Distribute
vFabric GemFire can keep clusters that are distributed around the world
―eventually consistent‖ in near real-time and can operate reliably in
disconnected, intermittent, and low-bandwidth network environments
57
59. 12vCPU VM
ESX
Scheduler
Can be done through
12 vCPU vSocket/vNUMA
in ESX5
Each NUMA
Node has 128/2 128 GB RAM
64GB on Server
60. Primary GemFire Usage – Hibernate Cache
Hibernate configuration
• (hibernate.cfg.xml)
<property name="hibernate.cache.use_second_level_cache">true</property>
• Set region.factory_class to GemFireRegionFactory
(hibernate.cfg.xml version 3.3+)
<property name="hibernate.cache.region.factory_class">
com.gemstone.gemfire.modules.hibernate.GemFireRegionFactory
</property>
60
61. Enabling Extreme Data Scalability and Elasticity
Key Capabilities
Low-latency, linearly-scalable,
memory-based data fabric
• Data distribution, replication,
partitioning, and co-location
• Pools memory and disk across many
nodes
Application Data
Lives Here Data-aware execution
• Move functionality to the data for peak
performance
Active/continuous querying and
event notification
• Changes are propagated to one or
more ―active‖ copies
Application Data
Sleeps Here
File Systems Databases Mainframes/other
61
62. GemFire in Mission Critical Wall Street Applications
Reference data (top 3 US-based bank)
• Large amounts of in-memory data, mostly static but some intraday updates
• 5x–10x performance increase
• Global distribution – consistent global views
• Domain-specific and regional edge caches
Market data (top 3 Japan-based financials firm)
• Ultra low latency for value added ―derived‖ market data
• Fault tolerant store-and-forward global data distribution
• Global consistency
Risk processing system (top 3 US-based bank)
• Credit risk, market risk, trader risk
• Over 1TB of credit risk data processing
• Processing moving from batch toward real time
• Consistent snapshot of data across long running calculation/analysis
62
Notes de l'éditeur
NOTE: If this is the first time the customer has heard of vFabric GemFire, you can do a high level executive presentation, locatedat: https://www.gosavo.com/vmware/Document/Document.aspx?id=1959790&view= This slide deck provides answers for customers who ask, “We know a little about vFabric High Performance Data with GemFire, we have seen the 15 minute executive presentation. We would like to learn more.” This can be delivered in about 1 hour.Core VMware account teams can use this to introduce VMware vFabric GemFire.
This is a customer facing presentation. It covers the main concepts behind High Performance Data Cloud with vFabric GemFire.
Let’s start by reviewing what’s happening around data.Analyst firms show that data is growing 60% year-over-year. That’s huge.Feeding up-to-date data to the right applications and supporting a variety of device access types 24x7 has become really difficult. In some sense, demand for data has outstripped IT’s ability to supply it. (Or at minimum, IT can’t supply the necessary data quickly enough.)Modern applications are heavily data dependent—new social media applications, travel, and financial. Consumer applications leading the evolution of enterprise applications.On the business side, consumers aren’t very sticky and will abandon Web sites and applications quickly if the experience is poor or slow. IT is challenged in four key areas around data:How to scale out data supply in a cost effective way to meet demand as user load shifts indeterminately?How to maintain the high performance at any given load?How to ensure data remains highly reliable?How to provide data across geographies?
Let’s start by reviewing what’s happening around data.Analyst firms show that data is growing 60% year-over-year. That’s huge.Feeding up-to-date data to the right applications and supporting a variety of device access types 24x7 has become really difficult. In some sense, demand for data has outstripped IT’s ability to supply it. (Or at minimum, IT can’t supply the necessary data quickly enough.)Modern applications are heavily data dependent—new social media applications, travel, and financial. Consumer applications leading the evolution of enterprise applications.On the business side, consumers aren’t very sticky and will abandon Web sites and applications quickly if the experience is poor or slow. IT is challenged in four key areas around data:How to scale out data supply in a cost effective way to meet demand as user load shifts indeterminately?How to maintain the high performance at any given load?How to ensure data remains highly reliable?How to provide data across geographies?
The VMware Cloud Application Platform combines the Spring Framework for building new applications together with a complete set of Application Platform Services required to run and manage these applications.[CLICK] Spring Framework – Spring is a comprehensive family of developer frameworks and tools that enable developers to build innovative new applications in a familiar and productive way while enabling the choice of where to run those applications, whether inside the datacenter or on private, hybrid, or public clouds. Spring enables developers to create applications that:Provide a rich, modern user experience across a range of platforms, browsers, and personal devices Integrate applications using proven Enterprise Application Integration patterns, including batch processing Access data in a wide range of structured and unstructured formats Leverage popular social media services and cloud service API’s[CLICK] VMware vFabric – VMware vFabric is a comprehensive family of application services uniquely optimized for cloud computing including lightweight application server, global data management, cloud-ready messaging, dynamic load balancing and application performance management. [CLICK] The products behind these services include: Lightweight Application Server–tc Server, an enterprise version of Apache Tomcat, is optimized for Spring and VMware vSphere and can be instantaneously provisioned to meet the scalability needs of modern applications Data Management Services–GemFire speeds application performance and eliminates database bottlenecks by providing real-time access to globally distributed data Cloud-ready Messaging Service–RabbitMQ facilitates communications between applications inside and outside the datacenter Dynamic Load Balancer–ERS, an enterprise version Apache web server, ensures optimal performance by distributing and balancing application load Application Performance Management–Hyperic enables proactive performance management through transparent visibility into modern applications deployed across physical, virtual, and cloud environments Policy-Driven Automation–Project Napa is the code name for a new offering still under development that is focused on policy-based automation of application and platform configuration and provisioning tasks
We’ve talked a lot about the needs of new applications One important thing to understand is that these new applications are very data-intensive. And for these new applications to realize the full promise of cloud, new approaches to data management that support the needs of applications deployed across elastic, highly scalable, geographically distributed architectures are needed.Cloud computing is a distributed deployment model, and for that reason, caching , messaging, and global data accessibility are of far greater strategic importance than before.
So what’s the problem with today’s IT architecture when it comes to providing data to many types of modern applications?This is a really simple view of a typical architecture. End-user clients at the top accessing applications through a variety of devices.End-user application requests travel through Web and application servers. As applications need data, the application server will fetch it from a database.As user load increases and more requests come in, IT is well versed at horizontally scaling out the Web tier and application server tier.[CLICK] [CLICK]But how do you scale the data tier? [CLICK]Traditional databases don’t scale horizontally very well. Typically you scale the database tier vertically—in other words, buy a larger and more expensive database. Scaling this way does not help address the need to scale out quickly and easily as load changes. In addition, accessing data from the database adds another hop across the network to the database tier. So performance limitations in the form of network traffic and generally higher overall latency are introduced.
vFabric GemFire solves this by moving data to the middle tier.vFabric GemFire is an elastic, distributed, in-memory data management platform. One core principle of GemFire is to pool and share memory and disk resources to create one larger virtual space. GemFire then manipulates data in that shared memory delivering dramatically faster application performance. GemFire is also designed to scale out horizontally on commodity hardware. This matches what’s already being done today with Web and application server functions. GemFire enhances data reliability by writing it behind, or through, to disk in parallel.GemFire clusters also span the globe with WAN capabilities. This creates a single, global view of data.
Use Cases 3 and 4 are where GemFire excels, and is where we start to get well beyond simple caching technologies. Use Case 3:Customer is creating a true data grid: lots of clients, connecting to many nodes, some of which may cross WANs.The data is kept in sync across all nodes at all times and so is highly available. Data can be persisted using lazy writes to achieve database-like reliability.The data grid can be used to publish and subscribe messages across topologies—so for many use cases acts as the message broker as well as the data store—eliminating the need for a messaging layer altogether.There are typically many clients. One of the scenarios we often see is where the clients are desktops, executing macros and pulling real time data from the data grid. This is in fact a significant mostly what the financial services customers are doing on Wall Street—almost every bank is using GemFire today (primarily for their trading apps).The clients are pulling data from the grid and executing some kind of logic on the data, similar to a typical messaging use case with a message broker, except much faster because the data is always local to the app that needs it. In this way you get huge improvements in throughput. Scenario 4The primary difference with #4 is that the execution is actually being done in the data layer. Both GemFire and Coherence have the ability to execute code within the process, allowing for an even greater throughput when compared to scenario #3. In this case, it blurs the line between the typical 3 tier architecture, so is a relatively high-end use case. That being said, it is in fact what high end financial services customers are doing with the product.The end result is really about faster throughput.
Very High Throughput10x more read/write throughput compared with disk-based databases.Low and Predictable LatencyUses highly optimized caching layer that minimizes context switch amongst threads.High ScalabilityAchieved through dynamic partitioning of data across many members.Continuous AvailabilityGuaranteed consistent copies of data in memory across servers .Applications can synchronously or asynchronously persist the data to disk on one or more nodes.Reliable Event NotificationsData events – Applications simply insert/update/delete objects and Gem delivers the changes to interested subscribers to the event.Upon receiving the event, the subscriber has direct access to the relate data.Continuous QueryingApplications can express complex interest in data through OQL and receive notification with predictable latency.Parallelize Application Behavior on Data NodesData-Aware Function Execution Service allows for the routing and execution of business logic to where the data livesExecution can happen in parallel.
Client/Server is essentially all the benefits of a database without the drawbacks. Database capabilities in-memory. Access to the more sophisticated GemFire features—data-aware function routing.
So who’s using GemFire today?
So who’s using GemFire today?It’s heavily used in many industries where high volumes of data need to be accessed rapidly by applications.One of our customers operates a very large online travel site.Consumers are constantly searching, reserving, and booking travel itineraries including flights, hotels, and rental cars.This customer could calculate how their application performance impacted their revenue. Truly every second counts for them.Deploying GemFire enabled them to support peak loads while simultaneously increasing application performance. GemFire led directly to improving customer satisfaction and revenue.
[CLICK]This diagram shows how you first need to conduct a scale-up test to establish what is called “Building-Block-VM” and then use this as repeatable unit for your scale-out test. [CLICK]Note: By Adding additional JVMs instances on a VM you do incur a cost in the vicinity of 5% overhead, hence don’t be afraid to drive load on a single JVM, for example 4GB Heap space etc.Although at some point a very large heap space can incur GC cost[CLICK]Now you conduct the scale-out test, for example in scale-up you determined 100 concurrent users, but you need 300, then obviously you would symmetrically repeat the build-block VM[CLICK][CLICK]NOTE: keeping virtual machines symmetrical helps in simplifying your load balancer layer (choosing least connection algorithm etc.)[CLICK] if all is OK SLA met - DONEOtherwise, if there are issues [CLICK]Now if in the scale-out test you see performance issues, most likely they are inter-tier related, meaning Load balancer, Http thread configuration, Java threads, and JDBC connection pools. [CLICK]In addition to potentially ESX. In some cases you may find that you need to go back and re-adjust the vertical scalability test - potentially you might have found that at certain point you hit a database deadlock and have to go back and re-assess your building block size.[CLICK]No doubt that I see most common configurations are around 2-VCPU, with 1:1 ratio between JVM:vCPU, meaning 2JVMs on one 2vCPU VM, and once size does not fit all, but if you say we are a regular registration like web application, and doing 250-500 concurrent users per vCPU then this would be something we generally see.Now as your conducting the scale-up test you will need to play around with JVM tuning, not a restriction that vSphere places, but it is something you would do whenever you move from one platform to another, if you want to run optimally. If you choose not to do it, vSphere doesn't really care.
To see online demos, download whitepapers, and more, head to vmware.com/go/gemfire
We recommend displaying this slide after finishing the presentation and starting a Q and A session (not required).
Another GemFire customer is in financial services. This customer uses GemFire to keep data current and available worldwide for use with foreign exchange.GemFire is able to handle near continuous market data updates, enabling fast position recalculations, while also ensuring regulatory compliance with a permanent archive of every trade.This customer is really exercising many GemFire capabilities including WAN routing.