vbop 2.3.0 and XCache 1.3.0 cache misses

[ctrlbrk]

Hi,

I just purchased and install vB 2.3.0 today. Running on vb 3.8.5 with xcache 1.3.0 on php 5.3.2 and nginx and php-fpm, on a core i7 860 with 12gb. It's been running about 2 hours and is reporting about 80,000 queries saved, so that's exciting.

However, I took a peek over at my XCache interface a few minutes ago and noticed it was using the #var cache. My var cache was fine before but it was totally full now with vB Optimise Pro. No problem, I have plenty of memory, so lets increase var cache and restart php-fpm w/nginx.

Ok, so did that. Hmm. Now I am seeing HUGE numbers of cache misses. Was not seeing this before. All the cache misses were showing up on one of the var# count rows, the other rows showed basically nothing. OK, I thought, I reduced var count in php.ini down to 1 and restarted. Same thing.

Here is a screenshot, it's been running about 10 minutes as I typed this.

If I go to the Lis Var Data detail output, there are several hundred templates and such. I am not sure why I am getting huge cache misses, like 100 a second. It's up to over 100,000 as I finish typing this email.

I already tried using vb admincp and Flush Cache. System Test reports no problems.

Mike

 

[Deceptor]

Hey Mike,

Misses generally occur when a cache item is attempted to be fetch but doesn't exist, or something within XCache failed so cache was not returned. Typically a large amount of misses will occur after a flush as cache re-populates. To verify content, I'd recommend running a Cache Flush via the Admin CP and seeing if cache begins to re-populate.

Keep in mind the XCache statistics don't give a true hits/misses overviews, the Hits is broken into hourly averages and misses is a total aggregation (or so I believe from the XCache documentation). If your misses continues to increase it might be worth enabling vBulletin debug mode as vB Optimise will output results in the debug menu (located at the bottom of every page) on cache handling, a typical example would be: vBOptimise: Fetched style from cache (ID: x), that message means the cache was successfully captured.

Let me know how it goes

 

[ctrlbrk]

XCache was restarted, so the stats shown are from the first 10 minutes or so. It's been about 40 minutes now, the misses are up over 250,000. It is showing hits of about 900,000. I did a flush cache before I opened the ticket.

I've never done debug before, does this output to EVERY page for ALL users, or only for admins? I want to minimally impact users.

Attached is the latest.

Mike

 

[ctrlbrk]

Also, in case it helps narrow this down --- When I first opened the ticket 45m ago you'll notice I said 80,000 queries saved. That number was dramatically incrementing for the first two hours that I was running vbo. But now it is still 80,000 an hour later. I thought at first it wasn't incrementing at all, but I checked carefully and it is, just very very slowly. The activity on the site is actually busier now than 2 hours ago, so that isn't it.

Mike

 

[Deceptor]

The debug does output to every page for all users, but you can make it only show to certain userids, for example, we have something like this in our config.php to show debug info. I've altered the code as an example to you, with it only User ID 1 would see the debug information. You'd just need to add it to the end of config.php manually (before the ?>)

if ($_COOKIE[$config['Misc']['cookieprefix'] . '_userid'] == 1)
{
	$config['Misc']['debug'] = true;
}

In regards to hits/misses, I'd say let it run for a while (few hours), the hits vs misses should level off to an average of 90%/10% (depending on how long your TTL settings are within vB Optimise), it's expected to begin with there are a lot of misses while cache populates as we don't cache everything, we cache on demand - if your site has a lot of active guests they'll be causing pages to become cached and that's probably where the majority of misses are coming from. That said, with the Hits being successful too and at a higher rate than the misses it looks to me like everything is okay.

Just for some extra information, the hits/misses is controlled by XCache itself, we can't do anything to record that data ourselves and misses are expected to be seen

Edit

In regards to the statistics, if you view them in the chart within the ACP you'll see them increase in small amounts (depending on current activity), where as if you leave it the cron should rebuild the data every 10 minutes so the count should be chunking upwards. If the stats don't seem to grow any further in the next hour let me know and if possible send me an FTP Login / Administrator Login so I can take a closer look
Also note that if you flush cache through the XCache Administration, the statistics we collect for queries saved will be deleted without being saved - the ACP Interface within vB Optimise however will safely flush without removing this statistic.

 

[ctrlbrk]

Thanks Deceptor for the help and quick responses, I appreciate it.

I enabled debug. I couldn't get your cookie if {} to work, so I just turned it on for everyone for about 5 seconds. Wow, that was a mistake! Server load spiked huge as fast as I could save the file and refresh the page...

Anyway, here is some of the output. Based on what you are saying, everything is fine.

I have to step away for a few hours. But I wanted to write this down:
1.3m hits / 400k misses as of 9:50am central

So we'll revisit later and see if its as you suspect, the hit percentage continues to rise.

Mike

 

[Deceptor]

Hey Mike,

Sorry to hear the debug info caused you issues, never seen it cause spikes before but I've never really enabled it globally on a large site so who knows

I appreciate the stats, once we see what they are later we can see if everything is leveling off. If you have any further questions meanwhile feel free to ask!

 

[ctrlbrk]

I forgot the last attachment apparently, here it is.

Ok, so 2 hours later 11:50am central:
3.6m hits / 1.1m misses.

So the ratio seems to be steady so far. Does this still seem normal to you? It just seems very odd to me. But if you think it's normal then I'll let it go. What doesn't make sense to me is if we have a couple hundred requests a second to cache files, why are we still incrementing at the same rate 2 hours later?

Mike

 

[ctrlbrk]

Sorry for extra posts. I am not very with it today, I haven't slept since Wed.

Attached is the resource graph. So, it is incrementing, which is good news.

Mike

 

[Deceptor]

Hey Mike,

Thanks for the information To me it seems fine, cache is being served correctly from vB Optimise without issue it seems and the stats are increasing. The ratio is a little high in my opinion but that could be due to a number of reasons, like how much TTL you have for guest content (if it's 2 minutes, content will keep expiring, which is fine because you want it relatively fresh).

If you have any more questions feel free to ask!

 

[ctrlbrk]

I've noticed this behavior twice. I never saw it prior to install vB Optimise, so I would have to say they are related.

Notice the -1 for guests. After a few minutes and refreshing the page, it's done and is back to normal. I pay close attention to this part of the forum home And I've never seen it before, so like I say, I think it's from vB Optimise which I recently installed.

The WOL cache in vbO options is set to 5.

The correct count (after a few minutes, and refreshes) was something like 35 members and 48 guests and 7 spiders.

Mike

 

[Deceptor]

Is there any modification you're using Mike to get the spiders count? It may be conflicting with the WOL cache within vBO.

 

[ctrlbrk]

Is there any modification you're using Mike to get the spiders count? It may be conflicting with the WOL cache within vBO.

Yes, this is the only one I know of (attached).

Mike

 

[Deceptor]

Mike,

Is there any chance you could ZIP that and upload it? We currently have an issue with XML uploads that we're looking into

Thanks!

 

[ctrlbrk]

Sure, here you go.

Mike

 

[Deceptor]

Yeah I see the problem. vB Optimise will cache the active users/guests, but the addon will execute another query (not cached) to fetch the guest count and process which of those are spiders, when doing so it will reduce the guest count by 1. So for example, if vB Optimise cached: 30 members, 5 guests, to begin with it would be fine. But then let's assume 2 minutes later there are 7 guests online, all of which are spiders, the webcrawler addon would show Spiders 7, but Guests -2 because the guest count will still be 5 from the cache (but 7 from the mod which fetches realtime data).

Best option here would either be to disable forumhome wol cache, try reduce it to 1/2 minutes so the error has little chance of showing, or disable the web crawler addon (which adds queries to the page just to show spider count).

 

[ctrlbrk]

Thank you for the excellent responses. I will change WOL cache to 0 for now.

Mike

 

[Deceptor]

No problem Let me know if you have any other questions.