Support » Plugin: Wordfence Security - Firewall & Malware Scan » Expired Transients in wp_options Table

  • Resolved timon33

    (@timon33)


    Hi.

    I’m experiencing very slow loading times in my wordpress website.

    It seems that the wp_options table is huge.
    The mysql_slow_query reported that too.

    It seems that wordfence stores/caches some info in wp_options table.

    _transient_wflginfl_
    _transient_timeout_wflginfl_

    in option_name field.

    There are almost 10k rows of those. Most of them are expired.

    Is it safe to delete the transients?

    • This topic was modified 3 years ago by timon33.
Viewing 6 replies - 1 through 6 (of 6 total)
  • Caleb

    (@crudhunter)

    Transients are just that. They expire and can be deleted.

    You might wanna try the plugin WP-Optimize.
    It has a function for cleaning up expired transients and other types of maintenance..

    timon33

    (@timon33)

    Thanks for your answer.

    Shouldn’t be a clearing method that removes the old expired transient data built-in wordfence?

    Caleb

    (@crudhunter)

    Welllllll… Transients is a WordPress functionality and used by every plugin, themes, and other functionality.

    If there should be a clean-up functionality, it should be in the core WordPress not allowing old junk to be sitting around. Once an expired transient is dead, WordPress’ own API would not be returning that data anymore. So it is dead data.

    The whole idea of many “transients” (temporary cached stuff) is to set it and forget it kinda thing. WordPress provides APIs to ‘set’ and ‘get’ transients, but NO cleanup actions are part of the API.

    It should logically be “unknown” to plugin developers where WordPress hide those transients at any time. (Depending on your installation they could be in the database option tables, in APC(u) memory based cache, or others caching options.

    WordPress does not really have a nice “cleanup” functionality, which means you would need every plugin developer to on their own be rooting around with manual MySQL code in the options tables, or whereever the transients are hiding at any time. Something they should NOT be doing, as the implementations could change in future versions of WordPress. And you really do not want every plugin author to add their own personal kick on running odd WP-cron jobs or other main clean-up junk just because of transients.

    So no.. Not a WordFence functionality, I think. Until WordPress learns to provide database maintenance and clean-up as a core functionality, I’d still suggest the “WP-Optimize” plugin, which is a work-around for the missing WordPress functionality.

    Hi,

    Great answer. I didn’t know that WordPress core routed the “transients” differently on each installation(OS? Server Configuration?).

    and Great idea BTW. I created a cron job running every week and check through a 50 line script if the transients are dead and delete them.

    Either way I’ll take this to WordPress codex support topic. If you know any active relative topic please share it here.

    Kind Regards
    and Thank you

    The base WordPress transient functionality (get/set transient functions) will in simple cases save all transients in the options table. On a base install of WordPress.

    But each function first checks whether an object cache is hooked up.

    With a line like

    	if ( wp_using_ext_object_cache() ) {
    		$value = wp_cache_get( $transient, 'transient' );

    WP checks for an external object cache, and then completely bypasses all the normal code to look for transients in the options table. Mapping transient functions to wp_cache_get/set functions instead.

    If you are finding the transients in your options table, it must be because you have not hooked up object cache functionality to speed up your site. Some plugins (including those I build myself) also use similar checks on availability of various caching systems to on their own completely bypass WP’s transient system, and go “Object Cache” all the way so to speak..

    My current sites for example make heavy use of APCu to keep all that temporary and “must find quickly” data in shared memory. Saving away the expensive database queries (and their network connections) entirely. I also on some sites build page portions with their own caching, so for example header and footer page sections and some widgets do not have to be rebuilt on each new page/post call, since they are common to and independent from page/post content. Smart themes should do something similar.

    Hence my view that if a plugin is really cache cognizant, it should handle it on its own. If it uses WordPress’ transient system, like most do, then the WordPress core should handle cleanup. The plugin developer should not go querying the options tables for stale data that may or may not exist. Or at least thats my thinking.

    Note, though, that using the options table (or generally a non-transient cache) does have one advantage.. If someone is saving longer term transients (day, week, month) the options table is a stable place to stick things. It maintains data across Apache and/or server reboots.
    Anything you place in for example APCu Object Cache is dead if the cache functionality is restarted, as it is in-memory only. So, using caches, one does have to think a little about what type of data is stored where. 🙂

    I for example store even page caches in memory based Object Cache, rather than on the default disk. Combined with PHP7 it is fast as lightning and no disk accesses are involved, but it comes with the side-effect that pages and related objects have to be rebuilt into the cache entirely if I restart Apache or PHP-FPM in some way. 🙂
    Them’s the little things one has to deal with. 🙂

    Great info you shared.

    Thank you for all your time and attention to my issue.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Expired Transients in wp_options Table’ is closed to new replies.