Skip to content

Database response time

Database response time is how long it takes PHP to ask the database a very simple question and get the answer back. WordPress keeps all its content and settings in the database, so it asks many such questions for every page it builds.

Each query has a fixed cost: the request goes to the database server, gets processed and comes back. For a single query, that’s barely noticeable. But an uncached WordPress page often runs many queries one after the other, and a slow round trip adds up to a noticeable part of the uncached server response time.

The value shows the basic speed of the connection to the database, not how long the queries of a real page take. A page with a few slow queries can be slow even when this value is low.

Server: The most common cause of a slow database response is the setup of the database server. When it runs on a separate machine, every query crosses the network. A database server shared by many sites, or one with slow storage or too little memory, answers more slowly when it’s busy.

WordPress: Heavy queries running at the same time, for example from a plugin’s reports, a search or an import, keep the database busy and slow down the simple ones too.

Cache: A persistent object cache answers many of WordPress’s questions from memory, so pages need fewer trips to the database. It doesn’t change this measurement, though: Permo goes around it on purpose.

The value is in the History, view Server, as Database response, next to the load and PHP memory.

At the start of every check, Permo sends the same small query to the database three times and takes the middle value (the median). The query reads a single entry, the site address (siteurl), from the options table by its key. It goes directly to the database, past any object cache. This measures the round trip from PHP to the database and back for a simple query, not the queries a page runs. If the query fails, the value stays empty.

Sources