My site — gossiponthis.com — is on a 64-bit 3.20 GHz dedicated server with 32 GB RAM and two 120 GB HDs, but when we get traffic spikes, the server either comes to a slow crawl or we get 504 Gateway errors all over.
On a typical day we get about 10,000-15,000+ pageviews a day. On spike days we can go up to 30,000-50,000+ due to us being in Google News and them picking up an article with a highly ranked keyword.
On the typical days the theme works fine and the server stays up, but on the spike days, the theme’s MySQL requests overload the server, eventually bringing it to a complete halt.
We’re running W3TC cache with only the page cache option enabled, per the theme’s documentation. And I’m currently speaking with my host about other options, but it seems like we’ve hit a wall here and I want to know if there were any other options besides going to another theme. I’ve already spent money with this one and don’t want to have to buy another one if this can be fixed.
Any solutions?
Hi,
I see you didn’t optimized the site – http://screencast.com/t/qY1CL39D
Follow this guide – https://forum.tagdiv.com/newspaper-documentation/
You can also check this – https://forum.tagdiv.com/topic/tutorial-pagespeed-2015/
Try to reduce the number of blocks on page, reduce the number of elements which come with ajax pagination (mega menus, ajax pagination, load more, infinite load – blocks)
Disable the view counter (it updates the database counter on each page view).
Try to reduce the number of plugins, use only the really important ones.
Hope this helps.
Thank you, Emil G.
I tried installing the td speed booster plugin but I didn’t like how the front-end showed a “flash of unstyled content” so I disabled it.
Regardless though, this issue isn’t regarding the time it takes for the page to load in the browser, but rather the time it takes for my server to actually load the theme/template. I use New Relic and I’m noticing a major problem is coming from the database — specifically a process called “wp_posts – SELECT.”
I’ve been doing some research on this and I realized I’m using a “child theme” to modify random parts of the template. Could that be causing this issue with the database?
I’ve found that child themes are often an issue on our server, partially due to the CSS redirect. I try not to EVER use them anymore. It did cause issues for us, on multiple themes, not just this one.
Not sure this impacts you, but the other things that killed our server was a bot from Ukraine hitting our login panels over and over. “Limit Login attempts” plugin helped, and then in our case we had to block the entire country of Ukraine for abuse (!).
Optimizing the wp-config.php file helped a lot, too, putting in the actual paths to domain and also the the theme folder, to cut down on those queries for high traffic spikes. Couldn’t hurt 🙂
This is what my host sent me:
Your server’s issue is that there are some very inefficient SELECT queries and was exacerbated by a crashed table. The crashed tables have now been repaired and fragmented tables have been optimized but the inefficient queries need to be addressed.
Regarding the SELECT statement on wp_posts, the query being run (see below) involves the tmp table. This is a very ‘expensive’ query, cause it involves writing the data to a location on disk, which is I/O intensive and imposes a high load on the server. Unfortunately, these queries could be related to wordpress stats/metrics/data collection/plugin/themes. The quick and dirty fix is to put the tmp tables in RAM for cases where there’s excess ram on the server, which your server unfortunately does not. Identifying the plugin/theme/etc that’s causing the proper way to go.
Copying to tmp table |
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id ) WHERE 1=1 AND wp_posts.post_type = ‘post’ AND ((wp_posts.post_status = ‘publish’)) AND ( wp_postmeta.meta_key = ‘post_views_count_7_day_total’ ) GROUP BY wp_posts.ID ORDER BY wp_postmeta.meta_value+0 DESC LIMIT 0, 5
The bolded portion is where the problem lies, which looks like it’s coming from the view counter. Is there a better way to optimize the code or should I just disable that portion of the theme altogether? I particularly enjoy showing articles that are trending so I’m hoping someone has a solution other than turning it off.
Hi,
The code has been tested and optimized, there’s no better alternative to it. You could try to enable the Object Cache in W3 Total Cache plugin and see if it improves anything. Also disable the 7 Days Counter if you don’t use it. Try to optimize the rest, check the guide i’ve provided on my previous message.
Let me know how it works.
Thank you, Emil G.
Just to update you all, in case anyone else is having this issue … it was the “popular over 7 days” widget we were using in the sidebar that was taking the site down whenever we have traffic spikes. I haven’t experienced any issues since removing that particular widget.
With it, we can barely handle 1k-2k pageviews an hour, but after removing the widget, one day we were experiencing a traffic spike and were able to serve about 8,000 pageviews per hour with ZERO issues.
Hi,
Unfortunately that’s the way the poplar 7 days feature works, based on views counter, so it makes requests to the server to update the counter and keep track of the “most popular posts”.
Glad you’ve solved your issue, let us know if you experience this again and thanks for your feedback.
Thanks
