Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Training Webinar: Enterprise application performance with distributed caching


Published on

2nd Session - Distributed Caching:
- What is Distributed Caching
- Performance hurdles solved by Distributed Caching
- When to use Distributed Caching
- Patterns to Populate a Distributed Cache
- How to use Distributed Caching in OutSystems

Free Online training:

Follow us on Twitter
Like us on Facebook

Published in: Software
  • Be the first to comment

Training Webinar: Enterprise application performance with distributed caching

  1. 1. Enterprise Application Performance Distributed Caching Tito Moreira Solution Architect - Experts Team
  2. 2. Performance Hurdles • Application code ○ Slow Queries / too many accesses to database ○ Slow Extensions ○ Large ViewState / Session • Infrastructure ○ Database ○ Network
  3. 3. Caching helps, right?
  4. 4. Caching helps, right? There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton
  5. 5. Out-Of-the-Box Caching in OutSystems • Queries • Actions • WebBlocks • Screens
  6. 6. Out-Of-the-Box Caching in OutSystems in-memory process (local server cache) • Queries • Actions • WebBlocks • Screens
  7. 7. Considerations when using local server caching • It shares resources (memory) with other apps in the same OutSystems Front End • Data in cache is not consistent across ≠ servers • Not fitted to store hundreds of Megabytes of data • It’s entirely managed by OS platform ○ Developers cannot control the cache entry keys ○ It is not possible to store local variables, e.g. lists of Structures ○ Cache invalidation mechanisms is somehow limited • Does not escalate well with the number of Servers ○ First hit in each local Server cache is always a “Miss”, however this can be dealt with using Warm-up procedures.
  8. 8. Data consistency using local server caching
  9. 9. What is Distributed Caching?
  10. 10. Distributed Cache concepts • Stores the cache on dedicated infrastructure resources ○ Distributed cache has different scalability needs • Maintains the infrastructure server caches synchronized ○ Every server in the distributed cache infrastructure should have the same data for a cache entry. • Makes the cached data remotely available to all Front-Ends in a transparent way ○ Front-Ends don’t have any knowledge about the distributed cache infrastructure • It is complementary to the OutSystems built-in cache ○ Distributed cache does not replace the local cache, it is used in addition to it in order to overcome certain local cache limitations inherent to that approach (e.g. cache data coeherence).
  11. 11. General Distributed Cache Infrastructure Load BalancerUser Cache protocol (over TCP/IP) HTTP Requests Internal Network (haProxy or other)
  12. 12. Patterns to Populate a Distributed Cache • On Demand / Cache Aside / Read-Through ○ The application tries to retrieve data from cache, when there’s a “miss” the application is responsible for storing the data in the cache so it will be available next time. ○ To implement Write-Through the Cache should be updated whenever the records are. MyApp (UI) DataServices_CS DB Distributed Cache infrastructure2 1 3Encapsulates Entities, providing Read or Write user Actions Consumes data related Actions Tries to read from cache On cache miss, data is read from DB CacheConnector 4 Data is updated in Cache, to be available on next access
  13. 13. Patterns to Populate a Distributed Cache • Background Data Push ○ Timer background Action “pushes” data into the distributed cache on a regular schedule. Any consumer application pulls the same data from the cache without being responsible for updating the cache data. MyApp (UI) DataServices_CS DB Distributed Cache infrastructure2 1 3 Encapsulates Entities, providing Read or Write user Actions Consumes data related Actions Updates cache on a regular interval CacheSync_CS Writes should invalidate cache! CacheConnector
  14. 14. Patterns to Populate a Distributed Cache On-Demand Background Data Push High frequency of data change Good (cache can be updated immediately on the Write use Action) Bad (background process makes high frequency cache updates not feasible) Exposed Write operations Good (cache is updated on demand) Bad (there might be conflicts between Write operations and background process - locking required) Performance on first access Bad (cache miss requires a DB read and cache update) Good (there shouldn’t be any cache misses - all data should be cached ahead) Cache of large blocks of Data Bad (small amounts of data only, since caching is done synchronously on cache misses) Good (caching of big chunks of data is done asynchronously)
  15. 15. Benefits from using Distributed Caching So what? How can I benefit from it? • Access cached data from anywhere ○ Actions, Extensions, external applications, etc • Get stats about what is stored • Relief data from Session • Store significant amounts of pre-processed data ○ Yes, Gigabytes of Query data! • Load cache data from background processes ○ It opens an entire spectrum of initialization possibilities • It’s easier to scale cache Servers than DB servers
  16. 16. Distributed Cache • Get stats about what is stored (most providers)
  17. 17. When to use Distributed Cache?
  18. 18. When to use Distributed Caching • Don’t use it if: ○ There are just a few Front End Servers (1 or 2) ○ Your Apps won’t have a significant amount of traffic ○ Your Apps don’t suffer from performance issues ○ You want to replace OutSystems local cache function entirely ■ Distributed Cache is a complementary component, and should be used in very specific scenarios!
  19. 19. When to use Distributed Caching • You should consider using it if: ○ You have more than 3 Front End Servers and you might need to scale even further ○ You have public-facing Web apps that display “static” data. ○ Your data changes often making local caches invalid ○ You need 100% control over the cache ○ You need to share state between Servers without using Database or Session
  20. 20. Recommended way to deploy a Distributed Cache
  21. 21. Distributed Cache deploy recommendations • Don’t install Distributed Cache services in OutSystems servers • Use a different infrastructure for the Distributed Cache servers • If in the OS Cloud, it’s advised to use AWS Elastic Cache in the same VPC • Plan for the Memory and CPU requirements of the Distributed Cache servers ○ Requests/sec, Reads/Writes, Size of cached data • Keep the Distributed Cache servers in the same network as the OS servers ○ Without firewalls, proxies or similiar in between ( < latency)
  22. 22. Managing Distributed Cache • Data remains cached even after a release (different infrastructure) ○ Not managed by Lifetime (Lifetime plugin for Cache purge?) • Cached data should to be purged whenever there is a release ○ Data model might have changed ○ Data from previous release might be incompatible with latest release ○ Cached data requirements might be different for the new release • Cached data initialization is possible with external processes • Distributed Caching locking mechanisms depend on implementation (Redis ≠ Memcached) • Distributed Caching resources should be monitored independently of OS Front-Ends
  23. 23. dmCache a Distributed Cache Connector
  24. 24. Introducing dmCache • dmCache is a Forge component that: ○ Provides actions to store/read OS data types and Records ○ Abstracts the developer from the Distributed Cache protocol and implementation ○ Helps the developer generate Cache entry keys: ■ Global (viewable by all applications) ■ Application ■ Session ■ Web Request
  25. 25. Using dmCache
  26. 26. Supported Cache Providers in dmCache • Memcached • Redis • Couchbase • AWS Elastic Cache • Azure Redis Cache
  27. 27. dmCache in Action! (Demo)
  28. 28. We’ll be back in 5 min to answer your questions
  29. 29. Thank you!