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: https://www.outsystems.com/learn/courses/ Follow us on Twitter http://www.twitter.com/OutSystemsDev Like us on Facebook http://www.Facebook.com/OutSystemsDev

1. Enterprise Application
Performance
Distributed Caching
Tito Moreira
Solution Architect - Experts Team

2. Performance Hurdles
• Application code
○ Slow Queries / too many accesses to database
○ Slow Extensions
○ Large ViewState / Session
• Infrastructure
○ Database
○ Network

3. Caching helps, right?

4. Caching helps, right?
There are only two hard things in Computer Science:
cache invalidation and naming things.
-- Phil Karlton

5. Out-Of-the-Box Caching in OutSystems
• Queries
• Actions
• WebBlocks
• Screens

6. Out-Of-the-Box Caching in OutSystems
in-memory process
(local server cache)
• Queries
• Actions
• WebBlocks
• Screens

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. Data consistency using local server caching

9. What is Distributed Caching?

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. General Distributed Cache Infrastructure
Load BalancerUser
Cache protocol (over TCP/IP)
HTTP Requests
Internal Network
(haProxy or other)

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. 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. 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. 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. Distributed Cache
• Get stats about what is stored (most providers)

17. When to use Distributed Cache?

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. 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. Recommended way to deploy a
Distributed Cache

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. 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. dmCache
a Distributed Cache Connector

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. Using dmCache

26. Supported Cache Providers in dmCache
• Memcached
• Redis
• Couchbase
• AWS Elastic Cache
• Azure Redis Cache

27. dmCache in Action!
(Demo)

28. We’ll be back in 5 min to answer
your questions

29. Thank you!