Gator Cache – Next Level Cache – Combo

I’m still learning about all of the various queries that WordPress executes. I’ve noticed that when there are zero cached items and a lot of Resets there is usually a plugin or two that are doing a lot of insert/update queries. The usual suspects are security plugins and logging.

Currently NLC resets the cache when and insert or update query is executed so all of these logging queries will cause the cache to constantly reset. In some cases there are plugins that do an insert/update on the admin dashboard page so therefore you will always see zero cached items.

In order to deal with this, if you go to the NLC settings page you’ll see in the information there is a “Last Reset Query” which shows whatever SQL statement was the last one that caused the cache to reset. The idea behind this is that you can see what is going on and then whitelist certain queries so that they will not reset the cache. Ideally you will see the cache resets happening only when you update actual blog content and not due to logging.

To whitelist certain terms, they go into your wp-config.php file. For example on one of my installs we have a security plugin and this is what our settings look like:

// do not read from cache is sql contains these
define('CACHE_READ_WHITELIST','posts WHERE ID IN|limit_login_'); 

// do not reset cache if sql contains these
define('CACHE_WRITE_WHITELIST','limit_login_');

Thank you for getting back to me. This is getting in way over my head. I wish I knew more coding. This is Last Reset Query:

I don’t what to add to the config.php

INSERT INTO sb_options (option_name, option_value, autoload) VALUES (‘_transient_wpsso_88aae904740ac066e280d585fcf4429f’, ‘a:13:{i:0;a:7:{i:0;s:50:\”<meta name=\”generator\” content=\”WPSSO 2.4.10G\” />\n\”;i:1;s:4:\”meta\”;i:2;s:4:\”name\”;i:3;s:9:\”generator\”;i:4;s:7:\”content\”;i:5;s:13:\”WPSSO 2.4.10G\”;i:6;s:0:\”\”;}i:1;a:7:{i:0;s:87:\”<link rel=\”publisher\” content=\”https://plus.google.com/112965149375202984899/posts\” />\n\”;i:1;s:4:\”link\”;i:2;s:3:\”rel\”;i:3;s:9:\”publisher\”;i:4;s:7:\”content\”;i:5;s:51:\”https://plus.google.com/112965149375202984899/posts\”;i:6;s:0:\”\”;}i:2;a:7:{i:0;s:58:\”<meta itemprop=\”description\” content=\”Tagged with bet\” />\n\”;i:1;s:4:\”meta\”;i:2;s:8:\”itemprop\”;i:3;s:11:\”description\”;i:4;s:7:\”content\”;i:5;s:15:\”Tagged with bet\”;i:6;s:0:\”\”;}i:3;a:7:{i:0;s:56:\”<meta property=\”fb:admins\” content=\”100001211666823\” />\n\”;i:1;s:4:\”meta\”;i:2;s:8:\”property\”;i:3;s:9:\”fb:admins\”;i:4;s:7:\”content\”;i:5;s:15:\”100001211666823\”;i:6;s:0:\”\”;}i:4;a:7:{i:0;s:56:\”<meta property=\”fb:app_id\” content=\”556077134507396\” />\n\”;i:1;s:4:\”meta\”;i:2;s:8:\”property\”;i:3;s:9:\”fb:app_id\”;i:4;s:7:\”content\”;i:5;s:15:\”556077134507396\”;i:6;s:0:\”\”;}i:5;a:7:{i:0;s:46:\”<meta property=\”og:locale\” content=\”en_US\” />\n\”;i:1;s:4:\”meta\”;i:2;s:8:\”property\”;i:3;s:9:\”og:locale\”;i:4;s:7:\”content\”;i:5;s:5:\”en_US\”;i:6;s:0:\”\”;}i:6;a:7:{i:0;s:57:\”<meta property=\”og:site_name\” content=\”Schnizzle.Biz\” />\n\”;i:1;s:4:\”meta\”;i:2;s:8:\”property\”;i:3;s:12:\”og:site_name\”;i:4;s:7:\”content\”;i:5;s:13:\”Schnizzle.Biz\”;i:6;s:0:\”\”;}i:7;a:7:{i:0;s:67:\”<meta property=\”og:url\” content=\”https://schnizzle.biz/tag/bet/\” />\n\”;i:1;s:4:\”meta\”;i:2;s:8:\”property\”;i:3;s:6:\”og:url\”;i:4;s:7:\”content\”;i:5;s:29:\”https://schnizzle.biz/tag/bet/\”;i:6;s:0:\”\”;}i:8;a:7:{i:0;s:65:\”<meta property=\”og:title\” content=\”bet – Schnizzle.Biz\” />\n\”;i:1;s:4:\”meta\”;i:2;s:8:\”property\”;i:3;s:8:\”og:title\”;i:4;s:7:\”content\”;i:5;s:25:\”bet – Schnizzle.Biz\”;i:6;s:0:\”\”;}i:9;a:7:{i:0;s:61:\”<meta property=\”og:description\” content=\”Tagged with bet\” />\n\”;i:1;s:4:\”meta\”;i:2;s:8:\”property\”;i:3;s:14:\”og:description\”;i:4;s:7:\”content\”;i:5;s:15:\”Tagged with bet\”;i:6;s:0:\”\”;}i:10;a:7:{i:0;s:46:\”<meta property=\”og:type\” content=\”website\” />\n\”;i:1;s:4:\”meta\”;i:2;s:8:\”property\”;i:3;s:7:\”og:type\”;i:4;s:7:\”content\”;i:5;s:7:\”website\”;i:6;s:0:\”\”;}i:11;a:7:{i:0;s:35:\”<meta name=\”author\” content=\” \” />\n\”;i:1;s:4:\”meta\”;i:2;s:4:\”name\”;i:3;s:6:\”author\”;i:4;s:7:\”content\”;i:5;s:1:\” \”;i:6;s:0:\”\”;}i:12;a:7:{i:0;s:54:\”<meta name=\”description\” content=\”Tagged with bet\” />\n\”;i:1;s:4:\”meta\”;i:2;s:4:\”name\”;i:3;s:11:\”description\”;i:4;s:7:\”content\”;i:5;s:15:\”Tagged with bet\”;i:6;s:0:\”\”;}}’, ‘no’) ON DUPLICATE KEY UPDATE option_name = VALUES(option_name), option_value = VALUES(option_value), autoload = VALUES(autoload)

Well you can try putting something unique from this query. For example this one looks like it’s coming from a WordPress SSO plugin of some sort. So this little bit of text “wpsso_” seems to be unique to that plugin. So you could try adding this to wp-config.php:

define('CACHE_READ_WHITELIST','wpsso_');
define('CACHE_WRITE_WHITELIST','wpsso_');

What this will do is to tell NLC to ignore any DB query that is coming from that plugin.

After you do that you may need revisiting the page to see if some other plugin is resetting the cache too often as well. If you found another one, say “limit_login_” then you would add that like so:

define('CACHE_READ_WHITELIST','wpsso_|limit_login_');
define('CACHE_WRITE_WHITELIST','wpsso_|limit_login_');

The trick is to find a balance where your cache is filling up and not resetting or pruning too often. So you kinda have to make changes and then observe after a bit of traffic comes through.

Ahh… I see. OK, thank you. I will try that!