Proposal: Nuke site stats from the manager entirely

aNoble is quite right; I would absolutely avoid calling the PageView "stats", and would say somthing like:

Count page views? [x]
This increments the PageView each time the document is hit. This may need to be switched off if you have a stats module installed.

I don’t see any reason why to switch it off, actually. It certainly shouldn’t interfere with an external stats app and it’s one less configuration choice to have to worry about. I’d like to see a lot less configuration options in the manager.

If we modularize the existing stats, we’ll need to replace the logging parts that are currently embedded in the doc parser. This sounds like a perfect spot to insert an event hook as Jeff mentioned above. Any thoughts here?

Doing so would let us have our cake and eat it too it seems on the surface.

LOL ... and not 2 hours after this topic opens, i get this PM:

We got this message from our server people, they’ve disabled modx as it’s over heating the servers cpu - any clues ?

Server Logs
| 47985 | skr_admin | localhost | skr_escorts | Query | 269 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 47995 | skr_admin | localhost | skr_escorts | Query | 269 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48132 | skr_admin | localhost | skr_escorts | Query | 72 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48167 | skr_admin | localhost | skr_escorts | Query | 87 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48168 | skr_admin | localhost | skr_escorts | Query | 87 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48195 | skr_admin | localhost | skr_escorts | Query | 72 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48227 | skr_admin | localhost | skr_escorts | Query | 72 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48250 | skr_admin | localhost | skr_escorts | Query | 87 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48331 | skr_admin | localhost | skr_escorts | Query | 71 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48332 | skr_admin | localhost | skr_escorts | Query | 29 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48345 | skr_admin | localhost | skr_escorts | Query | 72 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48396 | skr_admin | localhost | skr_escorts | Query | 17 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48447 | skr_admin | localhost | skr_escorts | Query | 17 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48455 | skr_admin | localhost | skr_escorts | Query | 72 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48562 | skr_admin | localhost | skr_escorts | Query | 17 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48570 | skr_admin | localhost | skr_escorts | Query | 60 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48665 | skr_admin | localhost | skr_escorts | Query | 4 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |
| 48668 | skr_admin | localhost | skr_escorts | Query | 4 | Sending data | SELECT COUNT(DISTINCT(visitor)) FROM `skr_modx`.modx_log_access |

Long story short, the built in stats are overloading the DB on the shared server they’re hosting on and they are likely going to get booted because of it:

ah yes - it’s that what’s overloading the cpu ? Hostgator are ’really’ pissed they’ve put us in suspension pending the TAC abuse investigation.

Damn, Ryan! I’m glad I turned my logging off then and used Mint instead! Well then...I’d say we definitely need to address this then. I certainly wouldn’t want a bunch of devs screaming at us because something doesn’t work right.

And the conclusion:

Yeah it’s a bummer all our pages were using that counter to keep track of individual page views, we disengaged it - the servers all happy now. The site got over 2 millon hits last month it’s gotten a little bigger than we thought it would, now it’s exceeding 100,000 hits a day must have been too much of a strain on the counter pushing our cpu usage off the chart.

But the sites ’way’ quicker now too, so I’m pretty happy about that.

Thanks again for your time Ryan

Jason and I were chatting about this topic, then Raymond and I chatted about it and it seems like everyone is pretty much on the same page. I think event hooks to better enable stats tracking could be included. Jason suggested onBeforePostProcess and onAfterPostProcess, with usage, e.g., of $this->invokeEvent(’onAfterPostProcess’); for most typical stats tracking applications.

Only problem is, I’ve got no clue how to do this. Anyone want to take a stab?

On further inspection of the current trunk, it looks like the lines around line 942:


Could become:


and the code around line 508 from this:


to:


Also looks like the code around line 1577 can be removed:


Then we’d need to insert the appropriate events into the DB installer for new and upgrade installs and it should be ready for real stats tracking. Thoughts?

Hi,

Joining the dicusssion on a late note but it’s better to be late than never.

In keeping with Jeff’s suggestions and a few others here’s what I would propose:

1) We convert the existing Stat system into a plugin/Module (Maybe called PageStats). This way user’s will be able will be able to (optional) read or us there existing system.

2) We create a new System Event called OnLogPageView. This way a developer can create his/her own Page view counter or statistic plugin/module.

3) Tune SlimStats and PageStats to use the OnLogPageView system event.

What do you all think?

Sounds good to me Raymond. Is the location above the appropriate location for the events, though?

I still am definitely in favor of a simple pagehit counter ... or a dedicated hits counter table.