![16
OutSystems’ Built-In Cache – Site Properties
● Loaded by the server.
● Hold data that has to be available across the module.
● Cached for faster access.
● Should be updated manually in Service Center.
● Isolate site properties in separate module ([ModuleName]_Config).
Updating site properties invalidates the cache of the module and requires the
properties to be reloaded from the database.](https://image.slidesharecdn.com/helenalameiro-cachinginoutsystems-osug-220307153359/85/Caching-Data-in-OutSystems-A-Tale-of-Gains-Without-Pain-16-320.jpg)
Caching Data in OutSystems: A Tale of Gains Without Pain
- 1. Caching in OutSystems A Tale of Gains without Pain Helena Lameiro Senior Engineer @ NTT Data 2022-02-23 1
- 2. … another presentation on performance !!! Agenda Caching concepts When and why to use Cache? 1 OutSystems Built-in Cache How it works, slightly under the hood Cache invalidation Best practices and considerations Other Server-Side Caching Resources Application Cache component Distributed Caching Caching Client-Side Mobile and Reactive IndexedDB 2 3 4 2
- 4. 4 So, What Is Cache All About? Temporary store fetched data from server in fast memory or local resource Improve performance Better user experience Data displayed to user faster Data are available faster on next requests
- 5. 5 When To Cache Data? ● Elements fetched from databases or external systems with low mutability Lot of requests = Same Response ● Impact end-user experience ● Overload on system resources ● Elements with controlled scope parameters (user session) ● Data consistency ! ● Data changes frequently. ● Caching mechanism is hard to maintain ● System Architecture already has several cached components on external systems or DB (Caching mess) Don’t Cache! Cache!
- 7. 7 “Cache in Minutes” Property - Where To Find It? Server Logic: ● Server Actions ● Aggregates ● SQL Nodes Traditional Web: ● Web Blocks (without submit or ajax submit) On previous OutSystems versions: ● Screens ● Consumed SOAP methods
- 8. 8 OutSystems’ Built-In Cache – How It Works (I) RAM-based ● All front-end servers ● One stored instance per server ● Always first miss Factories with more than one front-end ● First miss on each front-end Cache expires ● “Cache in Minutes” property Caching instance is defined by: ● Front-end ● Input Parameters ● Consumer modules and reference type (weak or strong) ● Tenant in multi-tenant app Not available on personal environments (no RabbitMQ)
- 9. 9 OutSystems’ Built-In Cache – How It Works (II) 1st Request Application Request Cache Missed Data source Fetched Data Cache Back Further Requests Application Request Cached Data Cache Cached
- 10. 10 OutSystems’ Built-In Cache – How It Works (III) Cached Requests Application Request Cache Cached Data Cached Cache expired Application Request Cache Data source Expired Fetched Data Cache Back
- 11. 11 OutSystems’ Built-In Cache – Parameters Caching Actions is only possible if input parameters are not a binary or complex type.
- 12. 12 OutSystems’ Built-In Cache – Parameters Caching Actions is only possible if input parameters are not a binary or complex type.
- 13. 13 OutSystems’ Built-In Cache – How It Works (III) Server vs. Service Actions Flow with Server Actions – Strong dependency ● Action logic is executed in the context of each consumer module. ● Cached instances may differ by consumer module. Flow with a Service Actions – Weak dependency ● Cache is defined at the consumer module that holds the service action. ● All its consumers have access to previous cached data (per FE).
- 14. 14 Flow with Server Actions – Strong dependency Same Parameters - Different consumers Next Request Data source Fetched Data Cache Back Cache Missed End User Module 1 Application Request Entry Data source Fetched Data Cache Back Cache Missed End User Module 2 Application Request Entry
- 15. 15 Flow with Service Action – Weak dependency Same Parameters - Different consumers End User Module 1 Application Request End User Module 2 Application Request Cached Data Next Request Data source Fetched Data Cache Back Cache Missed Entry Cache Cached Entry
- 16. 16 OutSystems’ Built-In Cache – Site Properties ● Loaded by the server. ● Hold data that has to be available across the module. ● Cached for faster access. ● Should be updated manually in Service Center. ● Isolate site properties in separate module ([ModuleName]_Config). Updating site properties invalidates the cache of the module and requires the properties to be reloaded from the database.
- 17. 17 Some common use cases Bootstraps, data migration bulk operation with repetition of data fetched
- 18. 18 Some common use cases Data fetched from external resources used very frequently
- 19. 19 Some common use cases Generic actions commonly used on most applications
- 20. 20 Some common use cases Heavy calculation logic or request that is commonly requested
- 21. 21 OutSystems’ Built-In Cache – Cache Invalidation (I) “There are only two hard things in Computer Science: Cache Invalidation and Naming Things.” Phil Karlton
- 22. 22 OutSystems’ Built-In Cache – Cache Invalidation (I) Cache invalidation is hard to control: ● All or nothing ● Performance expensive (forcing evaluation on next usage) ● Possible problems with logic (outdated values)
- 23. 23 OutSystems’ Built-In Cache – How Cache Can Be “Cleaned” Cache in minutes property control ● Cache expired Logic ● New request forcing change on input parameter value (context or dummy). ● System actions: ○ EspaceInvalidateCache ○ TenantInvalidateCache System and Infrastructure ● RAM memory overrun ● Front-end server reboots ● Module is published ● Service Center – redeploy published version
- 24. 24 OutSystems’ Built-In Cache – How Cache Can Be “Cleaned” Cache in minutes property control ● Cache expired Logic ● New request forcing change on input parameter value (context or dummy). ● System actions: ○ EspaceInvalidateCache ○ TenantInvalidateCache System and Infrastructure ● RAM memory overrun ● Front-end server reboots ● Module is published ● Service Center – redeploy published version performance impact during the first access of an application
- 25. 25 OutSystems’ Built-In Cache – Cache Invalidation in OutSystem 11 (III) Cache Invalidation Service ● Underlying mechanism – publish/subscribe via RabbitMQ ● Notifies each of the front-end servers that cached values are evicted. ● When cache invalidation occurs for a module or a tenant: 1. All applications watching for changes on these elements are notified. 2. Flag their local copies as dirty. 3. Set to reevaluation on new requests.
- 26. 26 OutSystems’ Built-In Cache – Implementation Best Practices (I) Avoid caching isolated Aggregates or Queries Add _cached suffix to server action with cache ● Description should indicate that action is cached, its purpose, and for how long. ● Identify Parameters with specific cache context.
- 27. 27 OutSystems’ Built-In Cache – Implementation Best Practices (II) Use a dummy cache invalidation parameter to control Cache Avoid cached actions without input parameters
- 28. 28 OutSystems’ Built-In Cache – Implementation Best Practices (III) Define the way you want cache to occur Configure cache to your use case ● Short vs. Long Cache ● Warming cache or Background Loading (via timer) ● Performance Bottlenecks
- 29. 29 OutSystems’ Built-In Cache – Some considerations RAM memory is also shared to run your application logic ● Don’t over cache ● Cache in minutes should be the least possible for you business case ● Check for Performance Bottlenecks ● Be gentle on cache invalidation ●
- 32. 32 Distributed Cache - when to use? ● +3 Front End Servers ● public-facing Web apps with “static” data. ● Shared data with some mutability ● Need 100% control over cache ● Need to share state between Servers without using Database or Session ● 1 or 2 Front End Servers ● Low amount of traffic ● No performance issues ● Trying to replace entirely built-in mechanism! Don’t use it! Can use it!
- 33. 33 Distributed Cache - patterns Cache aside Background Data Push
- 34. 3 Caching Client - Side 34
- 35. 35 Mobile Application – Client-Side ● Use a Specific Sync Unit. ● Client variable or local entity attribute with cache timeout and last sync. ● Avoid first miss with warm-up. ● Sync local data if cache evicted ○ update cache timeout and last sync ● Mechanism of cache invalidation to ensure data consistency. Optimize Data For Your Use Cases Using Hot Cache Save cached data on local storage with cache synchronization Be careful with sensitive data storage.
- 36. What about Caching Client-Side in Reactive Web? 36
- 37. 37 Mobile and Reactive Web Applications – Client Side (II) ● Basic data types ● Key Value structure ● Add a last sync timestamp ● Verify last sync against cache in minutes value ● Avoid first miss ● Sync data if cache evicted ● Ensure a cache invalidation mechanism Web Storage API Client Variables or Web Storage API handling Be careful with sensitive data storage
- 38. 38 Reactive Web Application – Cache Client-Side ● Mimetize local storage entities. ● Storage cached data in IndexedDB in browser – check availability. ● DB instance must be created first. ● Data created asynchronously. ● Data can be indexed. Indexed DB Be careful with sensitive data storage.
- 39. 39 IndexedDB - Can I Use
- 40. 40 Cache in Client Side - general consideration ● Avoid first miss - warming strategy ● Sync data if cache evicted (set a condition for eviction) ● Add a last sync timestamp ● Ensure a cache invalidation mechanism on destroy / on app resume (only on entry module) ● Take into account: ○ Load of data being cached ○ Type of data being cached ○ Logic for retrieve data from cache Be careful with sensitive data storage
- 42. 42 Share your story ● Have you ever used Cache before? ● What were your Use Cases? ● Queries, Screens, WB, Never ● What about client side? ● local storage ● other approaches? ● Advantages and issues that you had with caching
- 43. 43 THANK YOU !!!! Helena Lameiro Senior Engineer @ everis, an NTT Data company Linked in