Caching Challenges
Application-database inefficiency (e.g. repeated queries, network latency) is a primary cause of performance bottlenecks. Many use Redis to improve responsiveness. However, developers are challenged to know what to cache, what to invalidate and to ensure data is up to date. Moreover, caching requires manual code changes to the application.
Solution
This blog will walk you through the deployment models and steps to configure automated caching on Azure for Redis. Please note that Heimdall’s proxy also works with other in-memory data grid vendors. Supported vendors include Redis Labs, Pivotal GemFire Hazelcast, GridGain; commercial or open source versions.
Architecture
Heimdall offers two software packages (Figure 1 below):
- Database Proxy: Postgres, MySQL, MariaDB, SQL Server, Azure Database, Hyperscale (Citus)
- JDBC Driver: Provides access to any JDBC-compliant database
Figure 1: Software Package Options
Figure 3: Heimdall Proxy Architecture
Route your application to the proxy host/port or JDBC URL. Heimdall provides two levels of caching: 1) locally on the application instance and 2) on Azure Cache for Redis; this is similar to an L1/L2 cache.
How it works
As the application talks to the database, the proxy intercepts the queries and determines what SQL results to serve out from cache. Additionally, the proxy can route queries to different servers (for load-balancing and read/write split) to the backend database.
How does the Heimdall proxy handle cache invalidations? We see all changes to the database. Upon a change, the proxy invalidates the associated cache entries and optionally updates the cache entry. Invalidation is automated and synchronized between proxies. There is no more complex TTL or expiry configurations for each query cache.
The following covers how to configure Heimdall with Azure Cache for Redis in a WordPress, MySQL environment.
Installation and Set up:
Start the Heimdall proxy VM instance from the Azure Marketplace. The installation will include both the proxy and Central Console. For more information, visit our technical documentation.
Access the Heimdall Central Console with the server URL and post 8087. On the left panel, click “Wizard”, and then click “Manual Configuration” shown below. Our configuration wizard takes you step-by-step to successfully connect the Heimdall proxy to your Azure components (i.e. application, database, cache), and configure features (e.g. Query caching, Read/Write splitting, Load balancing).
Step 2. Once you have completed the Configuration Wizard, review the configuration starting with the Virtual Databases tab, which provides connection information for the application. See below for a screenshot preview.
Step 4. Confirm the database connection settings in the Data Sources tab, which includes connection pooling, load balancing, automated failover, and read/write splitting. See below for another screenshot preview.
Step 5. The Rules tab controls how queries are cached, routed, and transformed. The default configuration is to 1) Cache traffic NOT in transactions, 2) Forward selected traffic to a read-only source, and 3) Log query traffic. You can create custom rules without restarting the application or database. Make any rule configuration changes and click Commit to finalize.
Step 6. To connect the application to Heimdall, just change the database configuration to match the Heimdall database proxy. The existing MySQL configuration in WordPress was changed to 127.0.0.1:3306. This change is typically straightforward but is specific to your application. Details on the URL to use for the Heimdall JDBC Driver are in the JDBC section of the Virtual Database; or for the proxy, in the Proxy Configuration section.
Summary
The below dashboard provides information on query traffic and server performance for a WordPress application. Notice that the average query time from cache was 50 microseconds compared to1000 microseconds from the database. Query caching resulted in a performance boost of over 20x times! With a 90% cache hit rate, the database load was significantly reduced allowing for more users to be supported on the same database infrastructure.
We made no changes to the application besides the database URL/host+port change; no database system changes were required.
Conclusion
The Heimdall proxy transparently improves read/write query performance. Our distributed caching offers a simple, low latency solution for users without disruption to the application or database. Customers will not only improve database scale but also save on operational and licensing costs up to 50%. Download a free trial.
Resources and links:
- Azure Marketplace
- Blog: Heimdall for Azure Managed Databases
- Blog: Advanced Connection Pooling
- Blog: Improve Read Replica Utilization (aka Read/Write splits)
- Contact: info@heimdalldata.com
Heimdall Data, a Microsoft technology partner, offers a database proxy that automates caching for Azure Cache for Redis. Users can now implement SQL caching within minutes without any code changes. Users will save months/years of developing and managing cache subsystems
