by Erik Brandsberg, Chief Architect of Heimdall Data
In using databases as a key component of internet infrastructure, IT departments may encounter the challenge of connection management.
There are three areas where connection management can be an issue:
The Heimdall Proxy helps developers, database administrators, and architects horizontally scale out their relational database (e.g. Cloud SQL) through connection pooling. As a result, you will reduce your database instance size and support higher user counts.
In this blog, we explain how these pooling features function and are configured.
Solution Overview
The Heimdall Proxy advanced connection pooling includes:
Tenant connection management: The combination of 1) per-user and per database connection limiting, and 2) multiplexing, control the number of active queries a particular tenant can use at a time. This protects database resources and helps ensure the service level agreement (SLA) is met and not disrupted by a noisy neighbor using the same multi-tenant database.
Figure 1 – Heimdall Proxy Architecture.
Basic Connection Pooling
A basic connection pooler opens a number of connections upfront (the pool). Then, as an application needs a connection, instead of opening a new connection, it simply borrows a connection from the pool and returns it as soon as it’s not needed.
For most pools to be effective:
For a typical application server environment (J2EE, for example), basic pooling is supported. If pooling was not part of the initial design, simply inserting a connection pooler can cause more overhead than expected. Instead of connecting directly to the database, for example, all connections are now routed through the proxy/connection pooler, which adds to overhead in the connections.
Let’s go through a few scenarios:
For basic connection pooling, an active (green) front-side connection is paired with a back-side connection, as shown in Figure 2 above.
Additionally, you may have idle (red), unassigned connections in the backend for new connections. As such, you are not reducing the total number of connections, but are reducing the thrashing that occurs as the connections are opened and closed. The main benefit of basic pooling is lower CPU load on the database server.
To configure connection pooling on Heimdall Central Console, select the Data Source tab. The only thing that’s required is to click the checkbox for Enable Pooled Connection.
Connection Multiplexing
Beyond basic pooling, there is connection multiplexing which does not associate a client connection with a fixed database connection. Instead, active queries or transactions are assigned to an existing idle database connection, or else a new connection will be established.
If a client connection is idle, no resources are used on the database, reducing connection load and freeing memory. As shown in Figure 3 below, only active connections (green) are connected to the database via the connection pool. Idle connections (red) are ignored.
Multiplexing is a more complicated technology than basic pooling. Therefore, many factors need to be accounted for.
In the following situations, multiplexing will halt and a connection will remain pinned, including:
To configure multiplexing on the Heimdall Central Console, go to the VirtualDB tab. Under Proxy Configuration, check the box for Multiplex.
In the event that special queries break multiplexing logic, and multiplexing needs to be disabled on the connection, go to the Rules tab for more granular control (along with other pool behaviors).
Below is an example for a Postgres environment. Click on the pencil icon to edit the existing rule.
Figure 4 – Postgres rule to disable multiplexing with a search path.
For a MySQL environment, here’s an example of two rules that:
Figure 5 – MySQL rule to disable multiplexing with an explicit lock.
Tenant Connection Management
The third use case helps ensure SLAs by enforcing per-tenant limits on connections, and when combined with multiplexing, total active queries. This prevents one user from saturating the database, ensuring fairness of resources for others. A second tier of pool management is activated, that of “user pools.”
In the Data Sources tab, the pool can be managed at two tiers: the user level and the database. Each user can be limited to a number of total connections and idle connections, as demonstrated by the following configuration.
Figure 6 – Multi-tenant connection configuration example.
As shown above, the total connections allowed to the database across all users is 1000, but each user is only allowed 100, and of those, only 10 can be idle. Excess idle connections will be disposed of.
Each time a connection is returned from the pool, there’s a chance the connection will be closed. A value of 1000 means there is a 1/1000 chance the connection will be closed. This behavior is different from most connection poolers that set an absolute connection age, which for large deployments can result in a stampede of many connections closing and reopening at once.
Figure 7 – Multi-tenancy with pooling, multiplexing, and per-tenant connection limits.
The two tenants shown in Figure 7 (with unique usernames or catalogs) allow only active connections (green) to the database when multiplexing is enabled. If Tenant A attempts to perform a third query (blue) while two are active, it will be queued until one of the current active queries completes.
The net result of the combination of pooling, multiplexing, and per-tenant limits is that no single tenant can saturate database capacity, resulting in the SLAs of other customers failing.
Furthermore, beyond a certain point, adding execution threads to the database will result in negative performance. This control can improve overall performance in many cases, allowing more capacity during peak load.
Customer Use Cases
Magento
Magento is an e-commerce package written in PHP. Since PHP does not support efficient connection pooling due to its processing model, each page view opens a connection to the database, requests all of the data it needs, and then closes the connection.
For every page view, it results in a high amount of connection thrashing against the database and can consume a large percentage of the database CPU. With the Heimdall Proxy, basic connection pooling alone can reduce the load on the database by up to 15 percent.
Odoo
Odoo is an e-commerce platform written in Python. The platform supports connection pooling, but it uses an Object-Relational-Mapping (ORM) to abstract the application layer from the database connections. The ORM uses transactions for every activity, which would normally prevent multiplexing from providing benefits.
The Heimdall Proxy has another advanced feature called “delayed transactions” that works around this problem. It will prevent a true transaction from starting until Data Manipulation Language (DML) is actually required. When activated with Odoo, the connection counts on the database can be reduced by up to 20x depending on the load.
Slatwall Commerce
Slatwall is an e-commerce platform written in Java and is natively designed to use pooling. Under heavy load, it can result in the saturation of the allowed connections on MySQL.
In order to support larger user loads, the Heimdall Proxy reduces the connection load by an order of magnitude, resolving connection limits on the database and allowing the CPU load to be the limiting factor in larger deployments. Per Slatwall, Heimdall proxy offload with multiplexing and pooling resulted in a 10x reduction in connections to the database.
Complementary Features
While the Heimdall Proxy provides connection management for databases, there are other features provided that further improve SQL scale, performance, and security.
Conclusion
The Heimdall Proxy was designed to support high web-scale environments by minimizing the number of backend connections so your database tier can operate optimally. The granular controls ensure fairness for connected users while ensuring the database is never overwhelmed.
Deployment of the Heimdall Proxy requires no application changes, saving months of deployment and maintenance. To get started, download our proxy VM on the Google Cloud Marketplace.
Resources