8

Today I run a test over my db to explore the speed difference between accessing a key from options, custom table & transients. I ran the test for 1000 times and following is the time taken to run 1000 get operations:

  1. get_transient() 0.0245 seconds
  2. get_option() 0.0068 seconds
  3. simple select operation from Custom Table 0.65 seconds

I also checked that transient was not expired during this test. So the question is, is get_option() faster than get_transient() or did I mess up something in my test? Is custom table delay due to options being cached default by WordPress? Also, is options also cached by different caching plugins like the transients?

  • The answer to this is variable, keeping in mind that with an object cache, transients won't use options at all. Eitherway it's a micro-optimisation and a waste of time. Autoloading it as an option simply shifts the cost elsewhere – Tom J Nowell Feb 12 '18 at 19:43
14

Today I run a test over my db to explore the speed difference between accessing a key from options, custom table & transients. I ran the test for 1000 times and following is the time taken to run 1000 get operations:

Keep in mind that the options table is used for both options and transients on most systems, and that table has been optimised, with indexes added. So it's not a fair comparison

get_transient() 0.0245 seconds get_option() 0.0068 seconds simple select operation from Custom Table 0.65 seconds

This is also an unfair comparison, options with the autoload option set, will be loaded in advanced in a single query early on. So get_option is pulling from WP_Cache, the option has already been retrieved.

I also checked that transient was not expired during this test.

This shouldn't have an impact on a normal system on transient retrieval, after all it doesn't know if it's expired until it's been retrieved

So the question is, is get_option() faster than get_transient() or did I mess up something in my test?

It depends.

Is custom table delay due to options being cached default by WordPress?

Very possible, but how fast that select takes depends a lot on the query and table design

Also, is options also cached by different caching plugins like the transients?

Yes, WP_Cache is used, which will store it in memory for the rest of the request

Repeatability

These are all cached via WP_Cache so the second time you request it, no DB is involved.

Variability and It Depends

This all assumes a common basis, but what about object caches?

Lets introduce a MemcacheD instance, or a Redis instance ( I STRONGLY recommend you do so if you have the option, HUGE performance benefits for well built sites, especially if you use them for page caching, unless you have something like Varnish setup )

Now we have a new situation:

  • Now data is stored in RAM, and once it's fetched from the DB it's primed, and access times are dramatically reduced. Still slower than a variable, but significantly faster than a database query
  • A lot of new data is stored in WP_Cache that normally isn't. E.g. WP_Post objects, post meta, etc
  • WP_Cache now persists across requests
  • MemcacheD etc can eliminate expired transients etc

So now transients and options have the same access cost. They were already close, but they're now negligible and have more to do with the CPU load at the time the request was made.

So For Performance Should I Use Transients or Options?

While it's a worthy question to wonder about, the answer is that the difference is negligible and within the margins of error

its not that simple

So stop micro-optimising, they're the same storage medium, and this is not worthy of your time

  • Use options if you need to store something that's site wide
  • Use transients to temporarily store things that are expensive to calculate so you don't have to the next time

It is not worth your time to choose one over the other based on performance, there's no meaningful difference.

There are far better things to do to optimise that give significantly greater savings, e.g. using taxonomies instead of meta in post queries, not using __not style parameters, doing fewer things on the page, installing an object cache, lower posts per page, avoiding remote requests etc

What About A Custom Table That Will...

No, the options table is already well optimised, using a custom table will simply move operations outside of the WP Caching system, forcing you to write your own

  • Regarding, the option it is autoloaded in my case. The custom table contains just two rows and one select query to fetch data. – learning_13 Feb 13 '18 at 7:14
  • I am doing this for my plugin and have to choose between any one of them. The custom table was easiest to implement as per my design but fetch cost is large enough that will delay page load. – learning_13 Feb 13 '18 at 7:16
  • 2
    @learning_13, you were asking the wrong question, and maybe both tom and I failed to carry the message in our answers - Proper caching will make whatever you decide to use performant enough for sites that care about performance. The decision about how to store data should be made based on the structure of you plugin and its functionality, performance should be the last thing to think about. – Mark Kaplun Feb 13 '18 at 8:50
  • 2
    @aim100k, please don't get "parents" involved into the answers here. What people do for their living should not be brought up unless it is relevant to the answer or question. If you do not like an answer, downvote it. If you feel like the answer might be technically ok but offensive, you can either try to edit it, flag it, or discuss it on the meta site. – Mark Kaplun Feb 13 '18 at 8:54
  • @mark-kaplun, Let's say I store data in the custom table and fetch data from it for every post rendering where my plugin is involved to show some data. So, will the caching plugins or user's caching optimization will take care of caching that table? And will the additional efforts in implementation & design change just to use transients/options instead of using a custom table that fits more into my design a micro(premature)-optimization over page load speed? – learning_13 Feb 13 '18 at 12:01
4

If no object caching is found, get_transient calls get_option twice, once or the expiry interval and one for the value, therefor it is not going to be faster.

get_option performance by itself will be impacted on whether the option is "autoloaded" (default) or not. All autoloaded options are retrieved in one request for the DB and stored in the memory cache, and therefor there should be very little impact on how many times you call get_option even if it is for different options.

When you access the DB directly you bypass all caching and other performance improvements, and it is expected to be slower unless you implement some smart logic by yourself.

All that said, I am not sure your test was a good one, but regardless, the whole discussion is pointless as if you really care about performance you will use object cache system (and the relevant plugin) which will bring data access time much closer to zero.... and of course if you decide to use your own DB tables, you should integrate your access APIs with the object caching mechanism.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.