bug: multiple columns for single day in graph

marking this as resolved for now – my host had a disk go bad and it looks like this may have been the problem

Hey wp.Man,

I’m baaaaaack. Whew!

Yeah, something burped, though the routine does check to see if dates have already been created.

If you need to delete the extra March 10s, you’ll have to use phpMyAdmin (or whatever) to edit the ecstatic_cumulative table. The “day” column is human readable, and you can consolidate manually, if you’re so inclined.

Let me know.

happened again Mike – this time consecutively for 3 days – hundreds of graph columns for the 15th, 16th, 17th

i’ll do some troubleshooting and get back to you

Is a cached version of the table being fed to the program?

no sir
so far i haven’t been able to find the cause, but i’ll keep looking

Are you receiving numerous simultaneous hits to your site? I’m not a mySQL expert (now I tell you) and the cumulative table should lock while being updated, but perhaps it doesn’t? Ecstatic polls the table for the count of entries with “today’s” date (it should return either 0 or 1, and not create a new entry if anything other than 0 is found) so having multiple entries created is definitely unexpected behavior.

On the other hand, might it be the graphing routine that is somehow reporting duplicate (or more) entries from a single entry in the cumulative table? Are the numbers reported in the multiple graph bars the same, or does each one represent a single visit, or some variation? Or are they all ones, but maybe some are regular visitors, some are bots, and some are RSS hits? I guess what I’m getting at is wondering if the cumulative table itself contains duplicate entries, or whether the graphing routine is misreporting what it finds in the cumulative table.

site is pretty low traffic i would say – roughly 130K hits/mo. total (bots, visitors, etc.)

the multiple graphs for a single day follow a pattern, but the pattern seems to vary – often each instance shows slightly less hits than the previous instance, but sometimes the pattern seems to start over again. something like this (i don’t have enough data to show a screenshot because i just dumped the cumulative table)…

17-mar = 150
17-mar = 143
17-mar = 140
17-mar = 120
17-mar = 120
17-mar = 118
18-mar = 200
18-mar = 195
18-mar = 190
18-mar = 185

but there could be well over 100 repeated instances for a single day

i don’t have time to really troubleshoot now, but maybe later today

Just to be clear, you retyped the date names?

Entries actually look more like this…

day regi regp feedi feedp boti botp
2013-03-18 11 11 1 1 2 2

correct – sorry

here’s a screen-cap

there’s LOTS more columns, that’s just what fit in a single screen

The only other person (that I know about) having a similar problem was using Cloudflare (see support post titled “my site hit by bots very lot”).

Your stats seem to be off in a way similar to that poster’s claims.

Since my script will not create a new entry in the cumulative table unless no existing entry is found, I have to conclude that the mySQL SELECT query is not having the current state of the table returned to it.

I don’t know if an explicit flush after the table write will solve the problem, but will explore how to work that in.

hi Mike
i was using CloudFlare, but haven’t been for a while now

i’m flushing the cumulative db table manually – purging all data – and that hasn’t stopped the problem, nor has uninstalling/reinstalling the plugin

i would say don’t worry about it too much – there’s more troubleshooting i can do when i get a chance and maybe i can discover something

Ahem. It could be one of those stupid, stupid things that I hate, the basic test that works almost universally, but sometimes doesn’t.

I just noticed that WordPress’s get_var() function returns NULL if no entries are found, rather than 0 or false.

Obviously, if (!get_var($blah $etc)) works sometimes (almost all the time), but technically there should be an is_null() test, or NULL === .

So…

Approximately line 517 in ecstatic.php, this…

if (!$wpdb->get_var($wpdb->prepare(“SELECT count(*) FROM $this->cumulative_table WHERE day=%d”, $today))) //see if the today row has been created

… should be changed to this…

if (NULL === $wpdb->get_var($wpdb->prepare(“SELECT count(*) FROM $this->cumulative_table WHERE day=%d”, $today))) //see if the today row has been created

Basically, replace the ! with NULL === . Three equal signs.

I’ll further test it here, and will roll out a new version with only tiny changes/fixes tomorrow.

Oops. Don’t make that change!

The SELECT count(*) query doesn’t return NULL. It returns 0 if $today doesn’t exist. WordPress says, “Returns NULL if no result is found”, but a count of 0 is a found result.

Back to the drawing board.