How Many Database Connections Does a WordPress Site Open? (Experiment & Analysis)

4 min bacaan

Have you ever wondered how many database connections a single WordPress request actually opens? Understanding this is crucial for scaling your site and preventing the dreaded “Error establishing a database connection.” In this article, we\’ll dive into the factors that influence these connections and perform a live experiment to verify the results.

Factors Influencing Connection Counts

1. Number of Servers: Typical WordPress installations are hosted on a single server. However, in high-availability setups with a load balancer, multiple servers will interact with the database simultaneously.
2. WordPress Plugins: A properly written plugin should utilize the global $wpdb object provided by WordPress, which reuses the existing connection. Poorly written plugins may create new, separate connections, leading to more than one database connection per request.
3. Active Requests: Database connections are only open while a request is being processed. If your site has no visitors at a specific moment, there will be no active database connections.
4. Server Configuration: The type of PHP interface (such as PHP-FPM or mod_php) affects how connections are managed and pooled.

Experiment 🔬

In this section, we will verify if a default WordPress installation truly consumes only one database connection per request.

1/5: How to monitor active database connections

While you can use database tools like MySQL Workbench, you can also use a simple PHP script to query the information_schema.processlist table to see active connections in real-time.

Key Logic: The following script connects to the database and groups active processes by user, allowing us to isolate the connections made by the WordPress application user.

<?php
// Database credentials
$servername = "mysql";
$username = "root";
$password = "password";

// Create connection
$conn = new mysqli($servername, $username, $password);

// Check connection
if ($conn->connect_error) {
  die("Connection failed: " . $conn->connect_error);
}

// Query to get the number of threads connected based on user
$sql = "SELECT user, COUNT(*) as connections FROM information_schema.processlist GROUP BY user";
$result = $conn->query($sql);

if ($result->num_rows > 0) {
  while ($row = $result->fetch_assoc()) {
    // Filter for your specific WordPress database user
    if ($row['user'] == 'site_11703') {
      echo "User: " . $row["user"] . " - Connections: " . $row["connections"] . "<br>";
    }
  }
}

Note: Ensure the database user has the necessary permissions to access the information_schema tables.

2/5: Simulating a long-running request

Because clean WordPress installations load extremely fast, it can be hard to catch the active connection in a monitoring tool. To make it visible, we will deliberately slow down the execution.

By adding a sleep(10) command to the end of your wp-settings.php file, WordPress will hold the database connection open for 10 seconds before finishing the request.

3/5: Demo -> Single (1) request to WordPress site

Now, let\’s make a single request to the site and check the connection count in our monitoring script.

4/5: Demo -> Concurrent requests (5 requests)

To simulate concurrent requests, we can\’t just use multiple browser tabs because of HTTP/2 Multiplexing, which might combine them into a single connection. Instead, we use the k6 load testing tool to fire 5 separate requests simultaneously.

5/5: Demo -> Reaching the capacity limit (10 requests)

This test case highlights a critical server bottleneck: the PHP-FPM worker pool limit.

Because there are only 5 PHP worker processes available, the server can only process 5 WordPress requests at once. Even if we fire 10 requests, the database connection count stays at 5 because the remaining requests are queued by the web server.

Verdict

By default, WordPress opens exactly one database connection for the duration of its execution. Once the request completes, the connection is closed and returned to the pool.

When scaling your site, remember that both vertical scaling (increasing PHP workers) and horizontal scaling (adding servers) will increase the total number of simultaneous database connections. Always ensure your database max_connections setting is high enough to accommodate your maximum possible PHP worker count to avoid service interruptions.