Tracker slowness issues

Do you have the maintenance ON? This cleans out any daily table hits older than 6 months. That is the tracker so it’s clearly hitting the two tables and I suspect the daily is causing the issue.

This was the setting enabled: https://ibb.co/5WxNgm0F Any modifications needed?

I’ve been checking your site and there definitely seems to be a problem with the tracker hitting the database. One thing I’m not sure about is if the database tables are creating an issue. Can you please backup your database completely and then click on “Recreate primary key”. It would be helpful to also check out what the size of your tables are wp_top_ten* in the database. Lastly, I’d suggest optimising the tables as well.

Okay, also just so you know I have had the fast tracker disabled because there were too many hits. Before recreating the key, this is the situation of the tables: https://ibb.co/pBpptmRx I have backed up my database and I am recreating the key now Edit: I have recreated the key. Also how do I optimize the tables? Using wp-optimize? This reply was modified 1 year ago by hbk747 .

I think the issue is the 23m + entries in the table. Are you able to run this SQL Query in phpmyadmin or equivalent. DELETE FROM wp_top_ten_daily WHERE dp_date <= DATE_SUB(NOW(), INTERVAL 6 MONTH); I want to delete entries that are older than 6 months. If you have a very high-traffic site, you might need a shorter period of content storage.

You can put this in your wp-config.php define( 'TOP_TEN_STORE_DATA', 90 ); This would limit data to 90 days instead of the default of 180 days.

I ran the command and it deleted the entries. I have also edited my wp-config. Also I was wondering, could these really old entries be in the database because one of my top 10 widget’s is set to “Overall” in the period section. I hope this has fixed the issue. Edit: Is it safe to turn on the Fast tracker now? This reply was modified 1 year ago by hbk747 .

Yes please turn it on and check if this has been working fine. I have a feeling the old entries was the issue. What is the current count that you see in the daily table from the 23 million count.

Hello, I will turn it on. Also the entries are still a lot. It is showing 18M still. Any ideas?

If you don’t need that much data you can run the same command and instead of 90, use 60 or 30 days so you only retain data for this period.

You can be a better judge of that. So my webiste recieves around 100,000 ish visits per month. There are a a few Top 10 widgets enabled. One is titled Trending which shows the most visited posts in the past 7 days. The other is titled Most Read – All Time which has the “overall” period enabled. In the Most Read – All Time, the most famous articles are shown. If I use the command to delete 30 or 60 days, what effect will it have on these widgets? Will the overall period show articles that have done well in the 30 or 60 day period or will it still show the best articles from the start of the plugin’s time? So based on this information, should I run the command for 30 days or 60 days. If the data is inconsequential to me, I don’t mind deleting it but if it will affect the accuracy of the data then things are different. Also if the All Time – Most Read is causing slowness issues due to the database or whatever, I can with a heavy heart change it to Most Read – Monthly. Meaning that I can change the period from overall to 30 days. Since those Most Read All Time articles might disappear because of this, I hope it wont cause an SEO issue – since all of a sudden those articles disappear from most of my pages (I have the widget active on almost my posts). Warm regards,

I need to write up an article of the tables in Top 10. 100k a month is huge so I am glad the plugin is working well on your site. My suggestion is to first run it at 60 days – see if it’s a performance issue and then bring it down to 30 days or even lower. The daily tables are only used for the custom period (daily, weekly, monthly etc) when you select that in the widget. If you choose overall, then it uses the overall tables which only have an entry per post. So that widget can stay as-is. The daily tables also feed the chart in the dashboard in your admin area. If you’re not overly particular about very long time data, you can delete everything older.

Okay will do. Putting the new command for 60 days in the Wp config. Also the database entries are still sizeable, around 18M. Should I delete more or let them be? If yes to the delete option what should the time period be. You gave me the code to delete entries older than 6 months earlier.

Same code as earlier but use 1 month I’d suggest given that you don’t use the data beyond that period. DELETE FROM wp_top_ten_daily WHERE dp_date <= DATE_SUB(NOW(), INTERVAL 1 MONTH);

Sounds good. I deleted the entries and set the save state to 60 days for now. Lets see if this makes a difference. I think you are correct about these issues. Will keep you posted. Warm regards,

Hello, Unfortunately the issue persists. Cloudways replied: https://ibb.co/fY2TN8PZ We will need to optimize the WP-Crons and furthermore, for the requests of plugins, it is from the Top 10 plugin for WordPress. This plugin tracks page views using a PHP endpoint (fast-tracker.js.php) instead of a traditional JS pixel, which means every page view results in a POST request to your server, increasing CPU load and PHP processing time. Why This Is Causing Issue: > These POST requests bypass page caching and hit PHP directly. > They can become overwhelming on high-traffic sites. > They’re triggered even by bots, crawlers, or automated requests unless filtered. And this would require checking and optimizing the plugin with the help of their developer as this is code level optimization required to deal with the issue. If there is something you can do let me know. These high CPU issues started with Top 10 and other plugins after I changed my theme to Astra so I have asked Cloudways to investigate further. Still, even when I had my previous theme the Fast tracker did cause a lot of hits for me (although maybe not as much). Is the fast tracker needed for a website like mine or can I go without it? Warm regards,

The reality is that the fast tracker is designed to be faster than the traditional ajax or rest API trackers. You can switch to those and try it. Do you have the option to disable bots enabled on your site? There is one feature I do plan to eventually implement in the pro version which is on sampling. The idea being to not record every hit but a sample of hits. This only works for high traffic sites. I still think the issue is the size of the Top 10 daily tables. Are you okay with exporting the tables and then completely emptying it from the Tools page and see if that works? Please backup your database as always before making this change. This will lose tracking data for the custom period but not the overall data. I don’t understand the JS pixel comment they made above. I need to study this better.

I can try your suggestion. Will let you know. However I have a question. You said your solution wont affect the overall period but what will happen to the custom periods? Will those widgets not work or will they kind of restart?

Yes, that is correct. Your overall widget will stay as is. But, your “custom/daily” widget will restart. One alternative to that is if you’re only doing a Trending this week / day, you can even limit the counts to only the last 7 days. Same command as above but run it as 7 days instead of 6 months. I believe you should have the necessary sql index as well in the system but if after you cut down the tables, you can go to the Tools page and then Recreate Primary Key (Or even Recreate Database tables). BTW, I was researching JS Pixel concept and from what ChatGPT tells me, it is about running an Ajax request (which I do) on load – which means the problem is the same. Do you use Redis or a similar object cache on your site and do you know what your server specs are?

Sorry for the late reply. So I will run this command: DELETE FROM wp_top_ten_daily WHERE dp_date <= DATE_SUB(NOW(), INTERVAL 7 DAY); Then recreate database from Top 10 settings? Okay. Will do that soon. Also what about this wp config command: define( ‘TOP_TEN_STORE_DATA’, 90 ); This is causing errors, many of them. After making these changes, Cloudways let me know that the error log is full with this Top 10 error: [proxy_fcgi:error [pid 752755:tid 752820 [client 223.123.93.255:0 AH01071: Got error ‘tions/#non-prefetchable-groups; PHP message: objectcache.notice: The cache key `astra_addons_nav_menu_loader_nav_items_transien…………ache.pro/docs/configuration-options/#non-prefetchable-groups; PHP message: PHP Warning: Constant TOP_TEN_STORE_DATA already defined in /home/601622.cloudwaysapps.com/pcupncbqaz/public_html/wp-config.php on line 103’, referer: https://www.google.com/ [proxy_fcgi:error [pid 752632:tid 752658 [client 103.26.86.102:0 AH01071: Got error ‘PHP message: PHP Warning: Constant TOP_TEN_STORE_DATA already defined in /home/601622.cloudwaysapps.com/pcupncbqaz/public_html/wp-config.php on line 103’, referer: https://www.paradigmshift.com.pk/pakistan-the-balochistan-conundrum/ I am removing this code from the wp-config until you let me know where to put it which wont cause issues. Warm regards,

Yes on the command and recreating the table. This will limit the data to 7 days. I don’t understand the error on the constant. Do you have any more details on what line is giving that error? I’ll run some tests on my end as well to see.

Nope. I just used AI to understand what the error was and it said that this happens when it has be defined before. Not sure.

I have run the command and I recreated the primary. I did not recreate the database, however. If its important let me know

You shouldn’t need that. The primary keys are important especially if I’m not mistaken you have an older install.

@hbk747 How has the site been performing with these changes?

Hello, There doesn’t seem to be an issue now. I am not sure what worked – increasing the sever or trimming the top 10 database or both. Also for my case, what should be the max amount of data that top 10 saves. For example, above you said define( 'TOP_TEN_STORE_DATA', 90 ); However this was causing a recurring error in the error log. If this code starts working should I set it to 30 days instead or is 90 fine?

I think in your case 30 days will work well. I’ve filed a bug report for the constant issue. https://github.com/WebberZone/top-10/issues/176 I suspect that increasing the server capacity, as well as truncating the table, helped. The larger the table, the slower the code, unfortunately.

Hello, So some bad news the fast tracker is still one of the highest in count. Check this out. https://ibb.co/fdxFd0Km Does this happen with other websites as well or just mine?

What does the count mean? I’ve not had serious issues flagged by users on speed, particularly the tracker.

Count just means how many times it is used or hits in other words. I asked Cloudways and they suggested “We also understand you’ve experienced high CPU usage from the Top 10 plugin. In cases like this, here are a few suggestions that might help: Enable JavaScript-based tracking within the plugin settings to reduce direct database writes. Consider using the Query Monitor plugin to track and debug specific query load.”

On the count, given the hits that you told me you receive, I would expect the count to be high as each time you get a visit you should get a count. But this is specific to server load or it’s generic. 1. The plugin already tracks using JS. But the JS then needs to write to the DB to capture the hit. 2. You can install Query Monitor to check the queries on your site. It also shows the slower queries but I don’t think you can easily capture the tracker cause it’s JS driven. I’m not sure if there is way for QM to track those. If you’re okay to ignore the daily hits for a bit, you can disable the daily tracker in the Settings page and also remove your weekly widget. Then you can only use the overall widget. This reduces one DB write. Another thing to try, although I believe less optimum is to try one of the other trackers in the Settings page.