Site error after vs 3217 update

Update:

We’ve identified the reason behind multiple GET requests as shown below:

MYSERVERIP - - [10/Aug/2023:01:54:09 +0000] "GET /wp-content/uploads/wpo/images/XXXXX.png HTTP/1.1" 404 24197

Details: We have improved the WebP serving method in most recent release (v3.2.17). However, during the process, we should have reset the existing WebP serving method when updating to the latest version, but we didn’t. This oversight caused the above issue.

Solution: If you are still experiencing this issue, please reset the WebP serving method manually by clicking on the ‘Reset WebP serving method’ button. This should resolve the issue. Here’s a screenshot for reference: https://prnt.sc/87m1VI47CnPF

Note: It’s worth noting that the WebP serving method is designed to reset automatically within 24 hours. If you have updated the plugin more than 24 hours ago, there’s a high likelihood that the issue has already been automatically resolved.

Affected Users: We’re assuming that only a limited number of users, specifically those with a very specific server environment, experienced this issue.

Next Actions: As our next step, we will be releasing an update shortly to specifically address this issue.

We want to express our gratitude for the invaluable information you’ve shared with us. Your ongoing support is greatly appreciated.

• This reply was modified 1 year, 3 months ago by Kowsar Hossain.
• This reply was modified 1 year, 3 months ago by Kowsar Hossain. Reason: Formatting

@harmonious @imajaz @ktsembelis @cjlim

Regarding the high CPU load concern, it’s possible that this matter isn’t exclusively tied to the recent update. However, to establish certainty, we require additional details. The situation is this: if your website has the scheduled preload feature enabled through WP-Optimize, once you update any plugin (whether it’s WP-Optimize, Elementor, or any other), the existing cache is automatically cleared, triggering a preload process. This preloading task is demanding on the CPU. If your website encompasses numerous pages, the preload procedure might consume a considerable amount of time.

Another potential scenario is that even in cases where scheduled preload feature is disabled on your website, if your site experiences high traffic, it will rapidly generate new caches, also placing strain on the CPU. I guess you get the idea.

Now, I have a question specifically for those who have encountered this issue: Are you using the scheduled preload feature? Or does your website experience high traffic? Kindly share this information with us, as it will contribute to enhancing this plugin’s performance.

Thx Kowsar. For clarity, after i de-activated and re-activated the plug-in, the issue of high load went away, which I can 100% attribute to apache not attempting to load a specific image that (I believe) didn’t exist prior to the re-activation.

Hi @kowsar89,

When the issue first emerged, I undertook a debugging process by halting all websites and sequentially activating them one by one. Through this approach, I managed to pinpoint the problematic site. I subsequently disabled all plugins directly from the root directory, which led to the CPUs returning to their normal usage levels. However, upon reactivation, the issue resurfaced. Subsequently, I accessed the WordPress dashboard and began deactivating plugins one by one. It was during this process that I identified your plugin as the cause of the issue. Deactivating it alleviated the problem, but upon reactivation, the CPUs again spiked to 100% usage. Even the deactivation of cache preload (set for every 5 hours) did not resolve the matter, prompting me to uninstall the plugin.

Upon attempting an immediate reinstallation, the site displayed a server error. Consequently, I opted to remove the plugin once more directly from the root directory. In a subsequent test, I activated another site. This time, it was a simpler site utilizing the native WordPress theme and devoid of other editor plugins. After manually updating your plugin, the issue reemerged immediately. At this point, I decided to disable and remove the plugin from all sites, including the test site.

Throughout the day, there were additional updates, including a new WordPress version and updates to other plugins. It is plausible that a conflict arose during the cache preload, although the exact cause is uncertain. It’s worth noting that the server is a DELL PowerEdge R730XD 2U, equipped with 2x Intel Xeon 12-Cores (24 threads) E5-2690v3 processors running at 3.50 GHz, with 128GB DDR4 ECC RAM. Given this robust setup, observing 100% CPU usage is deemed unacceptable.

Thank you for sharing the information. We’ve just released a new update (v3.2.18). Kindly proceed to update the plugin on your website. I’ll now mark this thread as resolved. If you encounter any further complications with the most recent version, we kindly request that you open a new support topic. We appreciate your cooperation.

Hi?@kowsar89?,

I am using the preload with schedule being the same as cache lifespan. However, the number of pages my sites is very small (less than 20) and the traffic is very small as well, no more than 500-700 visits per day.

I was wondering if the GZIP compression and maybe elementor have also smth to do with the eevated load some of us experienced, but I am really guessing. Anyhow, so far so good.

Thanks a lot for reaching back.