One of the main causes of slow application performance is the inefficient SQL interaction between the application and database. Today, costly in-house resources are spent on developing a data access layer. For IT organizations you often have several constraints: 1) project priority conflicts and 2) third-party applications cannot be changed. Yet these applications need increased scale. Heimdall Data, a Microsoft Partner, offers a database proxy in the Azure Marketplace for developers and DBAs to improve SQL performance and reliability without application changes. Notable features include: Query caching Read/write splitting with replication lag detection Connection pooling Automated database failover The Heimdall proxy supports any relational database in Azure and is deployed as a side-car process. Just route the application to the proxy and turn on features from the Heimdall Central Console. From the Azure Marketplace, we support a proxy tier architecture. Figure 2: Heimdall Proxy Tier Architecture Query Caching: Caching introduces complexity and risk as it requires modifying the application. The Heimdall’s proxy is scalable and safe. Our caching logic determines which queries to cache into the cache of your choice (e.g. local heap, Redis). We automate cache invalidations without manual TTL expiry configurations. You are also is given the option to include or exclude cache policies. Our proxy ensures the cache instances are synchronized, keeping data fresh. To learn more, go to Automated Query Caching without application changes Figure 3: Read/Write Split Architecture Read/Write Split: To scale an application’s database capacity, database clusters are often divided into writeable primary and read replicas. This requires the application to be aware of the different servers and roles and requires code changes. The Heimdall proxy is SQL aware and routes queries to the appropriate database instance accounting for replication lag and transactional state. This is all configured as policy rules on the Heimdall Data Central Console. For more details, check out our read/write split blog. Connection Pooling: When idle connections are established, they consume unnecessary hardware resources, eventually slowing down performance. Heimdall’s connection pooling and multiplexing optimize connections by establishing only as many connections to the backend as there are concurrent queries. What makes our proxy unique is the level of control: Operators can limit connections on both a per-user and aggregate level. Automated Failover: When the Heimdall Data proxy detects a database failover, the Heimdall proxy queues the front-end connection and transparently fails over to the designated standby instance. This greatly reduces application errors and database exceptions. SQL Analytics: On the Heimdall Data Central Console, we provide client-side and server-side performance metrics. This includes the cache hit rate, database processing time, overall response time and query extraction plan. This allows users to identify performance bottlenecks whether it be in the application, database, or network. Figure 4: SQL Analytics on Heimdall Central Console The Heimdall architecture was designed for ease of deployment in Azure without the need to modify the application or database. Developers can improve query read/write performance without modifying a single line of code. Download a trial version in the Azure Marketplace. Resources: Partner Page: Heimdall for Azure website Blog: Using the Heimdall Proxy to Split Reads and Writes for Azure Databases Blog: Automated Query Caching without application changes Contact: [email protected]
