4

I have created a hit counter that stores all time hits and daily hits. This means that if a single post gets at least one view a day it will have 365 meta fields added to it by the end of the year. Multiply this by N posts and the number can grow considerably large. Will this ever be an issue? I know Wordpress caches stuff and this is why i am worried about it. Will all of these be loaded each time the post is loaded.

This will better explain what i have implemented.

$dailyhits = get_post_meta( $post->ID, 'hits_'.date('Y-m-d'), true );
if($dailyhits == null || $dailyhits == "" || $dailyhits == false) $dailyhits = 1;
else $dailyhits = $dailyhits + 1;   
update_post_meta($post->ID, 'hits_'.date('Y-m-d'), $dailyhits);
1
  • It's all relative, and obviously the greater the number of Post meta entries that you have, the slower things will be. Your best bet is to benchmark; calculate the average page load time now (across a range of devices/browsers), and then again in a few weeks. If you notice a big difference, you know you need to take action. There are some things you can do to help though, such as using AJAX to grab the number of hits and update the postmeta table after the page has loaded, or you could implement something to amalgamate daily hits in to total hits, then delete "old" data (say at 3 months). – David Gard Apr 25 '16 at 14:44
2

"You should not write to the DB on front end requests" is the eleventh commandment. Your performance will deteriorate due to the writes locking down the table much more than the impact the size of the table will have.

You should probably write such data in files instead of DB, or at least use a different table.

7
  • this seems a little unusual. surely the fraction of a second it takes to update a field isnt going to hurt a db table? do you have any documentation that goes into this further? – user1889580 Apr 25 '16 at 15:37
  • No documentation is needed, just look at your own snippet. What happens if you get two requests at the same time? You might lose one of the counts due to task switching. It is not very important for your use case probably, but DB have to have integrity all the time. therefor when there is a write request to the DB no read will be allowed because if allowed it might bring partial values.Write operation, which is also expensive in time, has to finish first before any read will be made. Since everything is in one table even unrelated queries will be suspended. – Mark Kaplun Apr 25 '16 at 15:55
  • i have this running as an ajax query so it doesnt slow down the main request. I can see where you are coming from, but most sql queries are executing in like 0.0005 seconds. Reading/writing to a file would surely take much longer than the time it takes to execute 2 sql queries. With 1000s of posts it will be slow. The file will also give the same issue of 2 views coming in at the exact same time. Using a second DB also is not an option with a WP plugin as most users wont know how to setup a db – user1889580 Apr 25 '16 at 15:58
  • 1
    you asked about theoretical impact, practical impact obviously depends on your hardware and the rate of requests and such. I didn't say different DB, but different table. BTW If you use ajax on every page load, it is a good way to bring your site down on the webserver side. – Mark Kaplun Apr 25 '16 at 16:08
  • +1 I've seen this grind a real Ruby site to a halt once it passed a certain visitor threshold. (They were storing the 'views' count in the product table that every request queried, and incrementing it on most requests.) You'll get away with this to start with, but best to use a separate table as Mark suggests. – Rup Apr 25 '16 at 16:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.