Getting concurrent users from SharePoint's RequestUsage SQL view

I've been curious about how our SharePoint farm is faring.  One of the statistics that is interesting to me is concurrent users - the number of users that the service can provide at any one time.  There are various methodologies behind this, but the one I opted to use was to look at how many unique users are accessing the site in a ten minute period.  It's not a 100% accurate determination of concurrency, but I didn't want to purchase additional software to do some analytics, and the SharePoint web analytics just wasn't cutting it for me.

First, I enabled Usage and Health Reporting (from Central Administration / Monitoring / Configure usage and health data collection), with the important event being Page Requests.  Enabling this will create a new database, typically named WSS_Logging, and a few SQL views to perform selects on this data.

Next, I used the following SQL.  I wanted to grab data for a one-week period.  Here's what I came up with:

SELECT 
MIN([LogTime]) AS 'From', 
MAX([LogTime]) AS 'To', 
COUNT([LogTime]) AS 'Total', 
COUNT(DISTINCT [UserLogin]) AS 'Unique'
FROM [WSS_Logging].[dbo].[RequestUsage]
WHERE LogTime < '2012-09-24 00:00:00.000' 
AND LogTime > '2012-09-17 00:00:00.000'
AND UserLogin != 'DOMAIN\AppPool'
AND UserLogin != 'SHAREPOINT\system'
AND UserLogin != 'DOMAIN\spfarmacc'
AND UserLogin != 'DOMAIN\ServFarmAcc'
AND UserLogin NOT LIKE '0#%'
AND UserLogin != ''
AND BytesConsumed > 0
GROUP BY
DATEPART(YEAR, [LogTime]),
DATEPART(MONTH, [LogTime]),
DATEPART(DAY, [LogTime]),
DATEPART(HOUR, [LogTime]),
(DATEPART(MINUTE, [LogTime]) / 10)

I realise there are probably better ways of doing this, but I'm no SQL expert. This will show a From and To datetime, a Total count of all applicable page requests, and a Unique count of unique user accounts within that Total. Therefore, the Unique column shows how many concurrent users were active during the times shown in From and To.

Consistently Slow performance with Server Publishing site feature enabled

Back from holiday to find the SharePoint 2010 site performing slowly.  On the previous day, there was an issue with SQL Server Agent and this needed to be restarted, but this may be unrelated.

The problem I faced was that seemingly every site or page was being delivered as expected, only with an additional delay of 10-15 seconds each time, consistently.  After this 10-15 seconds, the page would load instantly.  There was no mention of any problem in the system or SharePoint logs, and the latter was showing the usual request completion times.  It just seemed like the request was being held for 10-15 seconds.

Two site collections were unaffected: MySites (which is out-of-the-box SharePoint 2010 stuff) and Central Administration.  These both operated as usual, with response times between 1-2 seconds.

I later discovered that sites that have not had the SharePoint Server Publishing site feature were not affected.  To confirm this, I created a new Blank Site, and the pages loaded instantly.  As soon as I enabled the SharePoint Server Publishing feature, the performance problems reoccured.  Deactivating the feature did not fix the problem, so it seemed that any site that ever had this feature activated was afflicted.

Following this line of investigation, I checked the existing sites that had SharePoint Server Publishing activated previously. This feature was now deactivated on all sites, including the root site.

Following guidance from our SharePoint support contractors, I tried to view the Site Collection Output Cache settings.  This gave me an error, saying that the list does not exist, and a quick Google suggested I deactivate and reactivate SharePoint Publishing Infrastructure site collection feature.

I left this for the day, planning to try this when I came in this morning.  But when I signed in, the site was operating perfectly again.  The Server Publishing site feature was, again, activated for all sites.  I've looked through the logs to see if anything changed overnight, but can't see any record of this.  No-one in the office, or any of our contractors, made any changes to the server farm.  So, this is unsolved.  We do need to find out why this happened so we know how to prevent or fix it in the future, but so far, no solution.