For the 1st glance, “Post views stats” plugin does its work honestly, quickly and effectively. But after looking inside plugin source code I changed my opinion. Let me explain, why it was happend.
1) Plugin stores counter for every post at self-created database table named ‘cn_track_post’. Any single page open action for post from your blog adds record to this table. If your blog got 1000 visitors a day, who look into 1500 posts, you will got 45000 records at this table after a month of work.
2) Plugin doesn’t check user agent of your blog visitor. Thus any bot or search engine crawler reading your posts will be taken into account and get correspondent record at plugin’s database table. So we can multiply quant of records from the 1st item to (what do you like better?), say, x2. Thus, we get about 100,000 records a month growth. What quant of records will be at this table after year of work, 5 years?
3) How plugins get its counters for every post? It counts them directly from the ‘cn_track_post’ DB table every time, when you need it. If you will decide to show ‘Most Popular’ widget at your blog side bar, that your server get such additional overhead for every page load. Effective decision is to store the only record for any post and just increase counter after post view event. In this case there is no need at the database cleanup and calculation job is quite less for your server.
4) I see some inaccuracy at SQL-command plugin author uses. Let’s look on it:
$select="SELECT *,count(*) as counts FROM $table_name WHERE post_id=$post_ID group by post_id order by counts desc";
Look, if data was filtered out by post ID value then
a) what is the sense to group select result by post_id?
b) what is the sense to order result by counts value if it is the only value, as we count it for the post with ID equal to $post_ID variable value?
What SELECT command we should use in this case?
$select="SELECT count(*) as counts FROM $table_name WHERE post_id=$post_ID";
Even if the last command produces the same execution plan (MySQL is smart enough to not fulfill unneeded operations), this command returns less data and more easy to read.
5) Take into account that while you have more and more thousands of records at ‘cn_track_post’ database table, this table has no index on the ‘post_ID’ field. And every ‘SELECT’ command will force MySQL server to go through all records, all tens thousands or hundred thousands records on blogs with high traffic.
6) Plugin has no cleanup code included in case user decide to remove it. Thus, those hundreds thousands records will be left at WordPress database as unneeded garbage.
WordPress plugin “Post views stats” WordPress plugin, version 1.0, is published at WordPress plugins repository at December 19th, 2012. Thus, it is quite young product. I hope that initial version will be followed by the next more robust update soon and those version will be professional and worth development by experts as declared at “Post views stats” WordPress plugin authors site – cybernetikz.com.
For this moment, I do not recommend to install and use it at production WordPress sites. Look on plugins with similar functionality. There are a lot of examples at WordPress plugins repository. Input ‘post views stats’ at search box of your ‘Plugins->Add New’ page and select some which would you like.