As a developer there are some tricks you can put in place to reduce the load on your MySQL database. They are called WordPress transients.
What’s the problem?
WordPress has some great APIs that allow you to retrieve information that is stored in your database (DB).
Indeed every page that you view on the front-end of your website will have queried the DB several times for post, widget and plugin data.
It makes sense that the more calls that are made to the DB to get information, the slower it is going to get and that of course impacts on the performance of the website overall.
A simple solution is to make less requests to the DB in your code right?
But what if you really, really need all that information for your page. You can’t just ignore it.
Rather than grabbing data from the DB for every request, why not store that data in a WordPress transient instead?
WordPress transients can be used to store data for a specific period of time which makes them ideal for storing and caching data that may change at a particular interval.
For example, let’s say you want to display the latest 10 posts on web page for a site which editors post new articles every 6 hours.
One method would be to use a custom [codelet]WP Query[/codelet].
That would of course work and get the correct latest posts but there’s no caching involved and each visit to that web page means that the DB is having to do the same query and spit out the same data.
That’s wasteful of DB resources considering there won’t be any new posts published for another 6 hours.
Using WordPress Transients
Rather than use a WP Query object you can query the DB once using SQL and store the results in a transient, setting the expiry for 6 hours.
Here’s what I mean.
This bit of code first tries to get the information from the transient. If there is no data then we do our SQL search and store the results in the transient.
In this case I’m just returning the post ID but you could return any information you need to display on your web page such as the title and author.
Let’s go through the code.
Line 1 – sets up the global variable $wpdb for access to the DB.
Line 2 – stores the unique name of the transient in a variable (reduce the chance of you mistyping the name).
Line 3 – uses [codelet]get_transient()[/codelet] to attempt to read any existing transient data into the variable $post_ids.
The function will return a FALSE if no transient is found.
Line 4 – tests the transient storage variable to see if it is FALSE. It’s important to test for the type FALSE and not just for 0 or 1 because that could be valid stored data.
If the result is FALSE then we set up the query to get the data and populate a new transient.
Lines 5 – 12 – is a standard SQL statement which gets the latest 10 published posts in descending date order (newest first and returns just the post ID for each result.
Line 13 – does the actual DB query storing results in $results.
Line 14 – tests to see if there was any results returned.
Lines 15 – 17 – loop through each result
Line 16 – stores the ID in an array called post_ids. Note that $post_ids is equivalent to doing an array_merge() each time.
Line 18 – creates a new transient using [codelet]set_transient()[/codelet], the transient name, the post ID data and the final argument is the expiry time.
Expiry time is in seconds so 60 * 60 * 6 is 6 hours in total.
Note: WordPress doesn’t automatically delete transients in any scheduled way.
When a transient is read using get_transient() the expiry time is evaluated and if expired the data is deleted from the DB and FALSE is returned.
If you are developing a plugin then it may be handy to manually delete transient at uninstall or at least give your users that option.
Deleting transients is done through the [codelet]delete_transient()[/codelet] function.
Ideal for external services too
For example, just say your client needs to display the last ten Tweets from a particular Twitter account on a web page.
Accessing an external service such as Twitter can take time and that will slow down your overall page loading speed.
This is a common issue when using external web services.
You could extend the example above to read in your latest 10 tweets and store them in a transient.
Of course you would need to set a realistic expiry time so that you can see new Tweets coming through but that’s going to depend on the frequency you or your client Tweets at.
That’s why WordPress transients are handy little things.
You can store transients across sites in a Multi Site installation using [codelet]get_site_transient()[/codelet], [codelet]set_site_trasient()[/codelet] and [codelet]delete_site_transient()[/codelet].
They have the exact same parameters as the regular single site WordPress functions.