Optimize GemFire Performance for Latency Sensitive Workloads
•
4 gostaram•2,098 visualizações
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.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a Optimize GemFire Performance for Latency Sensitive Workloads
Semelhante a Optimize GemFire Performance for Latency Sensitive Workloads (20)
Mais de Carter Shanklin
Último
Último (20)
Optimize GemFire Performance for Latency Sensitive Workloads
- 1. VMware vFabric™ GemFire® Virtualizing Latency Sensitive Workloads and vFabric GemFire – PEX 2012 Emad Benjamin – Staff Architect © 2011 VMware Inc. All rights reserved
- 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
- 3. The Data Challenge and Latency Sensitive Workloads 3
- 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
- 6. VMware vFabric Cloud Application Platform 6
- 7. VMware Cloud Application Platform Programming Rich Social and Data Integration Batch Spring WaveMaker Cloud Model Web Mobile Access Patterns Framework Tool Suite Foundry Java Runtime Web Runtime Messaging Global Data In-mem SQL App Monitoring Performance Mgmt (tc Server) (ERS) (RabbitMQ) (GemFire) (SQLFire) (Spring Insight) (Hyperic) Java Automated Optimizations Virtual Datacenter App Provisioning (EM4J, …) (AppDirector) Cloud Infrastructure and Management 7
- 8. High Performance Data with vFabric GemFire 8
- 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
- 10. What’s the Problem? How do you scale the data tier? 10
- 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
- 15. Primary GemFire Topologies and Usage 15
- 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
- 19. Primary GemFire Usage – Hibernate Cache 19
- 20. Primary GemFire Usage – HTTP Session Management 20
- 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
- 45. Getting Started – vmware.com/go/gemfire 45
- 46. Thank you! Any Questions? You can buy my book here: https://www.createspace.com/3632131 46
- 47. Backup Slides 47
- 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
- 58. Design and Sizing – Step 1: Calculating Region Data (cont.) Formula 5 TotalMemoryForSocketsAndThreads = TotalMemoryForSockets + TotalMemoryForThreadOverhead TotalMemoryForThreadOverhead = MaxClientThreads * ThreadStackSize TotalMemoryForSockets = TotaNumbrOfsockets * SocketBufferSizeBytes TotalNumberOfSockets = NumberOfServers * NumberOfThreadsOnServer + AppThreads + MaxClientThreads + MaxClientThreads * 2 * NumberofServers * IfHostPartitionedRegionAndConserveSocketsIsFalse 58
- 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
Notas do Editor
- 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.