Ryan Stueve

Hi Nayeem, it is a longstanding issue that you assisted with in the past. We just have too many site views which creates some issues with PDF Viewer working. I’m just looking for a solution on our most visited packages that will allow us to reduce the number of fetch requests and using an iframe seems to work for what we are looking for. Is there a way to build a shortcode of my own that works like the [file_list] one? I realize it is meant for multiple files, but we aren’t going to be using it that way, so if I could strip out the code that removes it from my URL string, that would be awesome.

We tried making our own with some php and it places into the template perfectly on its own, but when I add it to the src url of an iframe, it doesn’t read the shortcode at all:

<iframe src="[wpdm_url_ae]" style="width: 100%; height: 400px; border: none;"></iframe>
  #document (https://resources.advisorsexcel.com/resource/test-package/[wpdm_url_ae])

Looks to be working now! Thanks, Nayeem!

Hi Nayeem! So I’ve implemented this code and it is working, but once I select that choice in my filter it reverts to the original name. Any idea why that might be?

Thanks for the update. My concern is that we get a lot of site traffic. Is there potential that the number of hits are causing issues that your other customers are not experiencing because they don’t have the same volume of traffic?

With the increase to our database, we are running optimally now, but we would love to not have to increase that for the WPDM plugin to function correctly under strain.

Nayeem, I’ve spoken to Flywheel and there isn’t really much more detail that we can provide that isn’t already in the logs. We saw these increases in slow errors happening with the spikes to 100% CPU usage within the MySQL layer. Over the course of the past 30 days, the download-manager plugin has been mentioned in over 44,000 slow errors, which well over 5x more than other plugins that were logging consistent slow errors. During these spikes there is usually a backlog of mySQL queries, however, those have to be caught in real time in order to know the specific query that’s happening. Since the database upgrade, we haven’t seen any of these large spikes, and simply reviewing the site, we’re not seeing a large amount of the same query running like what would have been happening previously. With that being said, the slow errors should provide enough information to your developers for them to have an idea of what is going on with the plugin at that time, and while other plugins may be throwing some slow errors, it was only those that were logging thousands upon thousands.

The logs provided from May 29th for reference, show the numerous logged errors calling out the download-manager plugin and specifically mentioning mySQL queries, indicating these played a large role in the problems that were seen.

Hey Nayeem, I think it might be time to see if there’s a developer or manager to loop in here. Yes, other plugins have errors, but when our site reaches the 100% CPU usage that causes things to crash, the plugin that is throwing thousands of errors and isn’t functioning in that moment is WPDM and PDF Viewer. These particular plugins are causing the increase in resources that is maxing out an already high database CPU and Flywheel has been able to identify the source is this plugin in particular.

I don’t want to point fingers or place blame, but we have got to get this figured out because everything I’ve been able to determine on our end says it is Download Manager. This plugin is the core to the functionality of our site, so when things act up, the site is completely unusable. We are now paying thousands of dollars a month to increase our database CPU to mitigate maxing it out when we shouldn’t need to be if the plugin could handle the load during peak times.

Just resent the error logs to support@wpdownloadmanager.com via WeTransfer.

Thanks for this explanation. So there’s no risk to losing any important stat data by clearing that cache and enabling auto clean cache functionality? Also, what’s the difference between storing the temporary files in the database vs a file?

We have not toggled the plugin on and off during these periods and can’t really test that now that we have increased our database CPU to combat the issue. But we can’t keep that database CPU increased as it is quite expensive and shouldn’t be necessary if the plugin ran properly.

I have provided slow logs as requested so I’m not really sure what else you need from me, Nayeem. I will resend the slow errors from 5/29 to support@wpdownloadmanager.com, where you should be able to see the numerous logged errors calling out of the download-manager plugin and specifically mentioning mySQL queries, indicating these played a large role in the problems that were seen.

There isn’t really much more detail that we can provide that isn’t already in the logs. We saw these increases in slow errors happening with the spikes to 100% CPU usage within the MySQL layer. Over the course of the past 30 days, the download-manager plugin has been mentioned in over 44,000 slow errors, which well over 5x more than other plugins that were logging consistent slow errors. During these spikes there is usually a backlog of mySQL queries, however, those have to be caught in real time in order to know the specific query that’s happening. Since the database upgrade, we haven’t seen any of these large spikes, and simply reviewing the site, we’re not seeing a large amount of the same query running like what would have been happening previously. With that being said, the slow errors should provide enough information for your team to have an idea of what is going on with the plugin at that time, and while other plugins may be throwing some slow errors, it was only those that were logging thousands upon thousands.

Yes, I’ve already provided those logs. Consistently it is your plugins that seem to be throwing the errors…and huge amounts of them. We just had to increase our Database CPU on our site to handle these requests as the high traffic hitting downloads was maxing this out although it was already very high. This upgrade is fixing our issue in the short term, but the cost is high to have the database increased to this level, so it can only be a workaround. We have got to figure out a way to reduce the errors and slow load/download times coming from WPDM/PDF Viewer if we are going to continue to utilize your plugins as the core functionality of our website.

Once your team authority has received and you’ve had a chance to review, please update any findings as you are able. We are leaving your admin user account open as you continue to assist, but are required to report weekly to our team what progress you are making in order to keep that account open.

I just sent php error logs, slow logs and database layer CPU usage for the last 7 days via WeTransfer to support@wpdownloadmanager.com.

For reference, Flywheel’s database layers already have an extremely high CPU spec, so seeing the usage spiking to 100% sustained usage is a bit surprising. They suggest working with WPDM developers to reduce the database usage as a recommended first step as problems only occur when the usage is pinned at 100%, which you can see happens somewhat regularly.