6.3.6 decimated my site’s performance

Hello,

Having same trouble. Reinstalled the new update a few times and the activation finally took hold, but now the site is painfully slow.

Meant to say that this is happening with the new 6.3.7

Hi @jaydisc,

In order to check if this could be related to your environment, could you please:

• Go to the Wordfence Tools page
• Click the Diagnostics tab
• In the Other Tests section (near the bottom of the page), click the link that reads “Click to view your system’s configuration in a new window”. This will open a Wordfence System Info page.

then check the values associated with the following parameters:

• Server API
• PHP Version
• Loaded Configuration File

Also, could you check if you see any warnings/errors in the web server log files?

Hi @wfyann,

I re-enabled Wordfence 6.3.7 (but not the WAF), and checked as you asked

Server API: FPM/FastCGI
PHP Version: 5.6.30-0+deb8u1
Loaded Configuration File: /etc/php5/fpm/php.ini

This is a Debian 8.7 VPS that I am the administrator for.

I have overridden the following directives in that php.ini:

disable_functions = pcntl_alarm, pcntl_fork, pcntl_waitpid, pcntl_wait, pcntl_wifexited, pcntl_wifstopped, pcntl_wifsignaled, pcntl_wexitstatus, pcntl_wtermsig, pcntl_wstopsig, pcntl_signal, pcntl_signal_dispatch, pcntl_get_last_error, pcntl_strerror, pcntl_sigprocmask, pcntl_sigwaitinfo, pcntl_sigtimedwait, pcntl_exec, pcntl_getpriority, pcntl_setpriority, eval, exec, passthru, shell_exec, system, proc_open, popen, curl_multi_exec, parse_ini_file, show_source

error_log = syslog

upload_tmp_dir = '/var/www/uploads'

upload_max_filesize = 5M

mail.add_x_header = Off

I have nothing in the virtual host’s error log. The access log is just showing hits, no warnings or errors. The log I have sent php errors to, is also empty.

• This reply was modified 7 years, 7 months ago by jaydisc.

Hi @jaydisc,

Apologies for the delayed response.

When you carry out the optimization procedure does Wordfence suggest the appropriate setting (“recommended based on our tests” labelled option)?

Is it consistent with your actual system configuration?

Hi @wfyann,

What procedure are you referring to? That link is to the Setup process and the only 2 mentions of optimisation are related to the auto_prepend_file directive, which I have disabled, and still experience the slowdowns.

Is it possible you’ve sent the wrong link? If not, could you please provide a bit more detail?

Hi @jaydisc,

Sorry about the confusion.

Reading this:

I use the auto_prepend_file directive for the active firewall, so that’s why I assume I was still having the poor performance, even with the plugin disabled (before I started rolling back). I’ve disabled the plugin and the auto_prepend_file directive and everything is snappy again[…]

I assumed the issue disappeared once you removed the auto_prepend_file directive, which is why I wanted to focus on the firewall optimization parameters; hence the link to the firewall setup documentation page.

If you’re still experiencing the slowdowns despite the firewall being disabled and the auto_prepend_file directive being removed, then the cause obviously lies elsewhere.

In order to gather more information on what’s happening, could you please enable WP_DEBUG and look into the debug.log file thus generated?

Hi @wfyann,

No, that is not correct. What I was trying to detail there, was that EVEN THOUGH THE PLUGIN WAS DISABLED in WordPress, by still having auto_prepend_file directive set, I WAS STILL experienced the slowness. On the surface, this seems wrong to me. I feel like the auto_prepend_file should by pass itself if the plug itself is disabled, as disabling WordFence in WordPress, DOESN’T REALLY DISABLE IT.

So, to summarise:

Wordfence plugin disabled, auto_prepend_file active: Bad Performance
Wordfence plugin enabled, auto_prepend_file inactive: Bad Performance

The only way I can get my performance back it to disable BOTH the plugin (in wp-admin) and auto_prepend_file in php.ini.

Hoping that’s clearer?

Hi @wfyann,

I turned on the debug.log and it spewed a couple of PHP notices from some of my functions in functions.php (minor things solved with a check for isset()/empty()). I resolved those, and then re-enabled Wordfence, and loaded a shop page, and while both suffered their expected performance hit, there was no output to debug.log at that time.

Addendum: The debug testing was done with the plugin enabled, but NOT with auto_prepend_file reactivated.

• This reply was modified 7 years, 6 months ago by jaydisc.
• This reply was modified 7 years, 6 months ago by jaydisc.

Hi @jaydisc,

Apologies for the delayed response.

Could you please:

• Go to the Wordfence Tools page
• Click the Diagnostics tab
• Scroll down to the Send Report by Email section
• Send the report to yann[at]wordfence[dot]com

Thank you.

OK, I went to that tab this morning, and noticed two permissions errors (paths shortened for brevity):

1. Couldn’t write to wp-content/plugins/wordfence/tmp
2. Couldn’t write to wp-content/wflogs

Before going any further, I went in and corrected those permissions, refreshed the Diagnostics page to confirm, and then tested the site, and the performance was fine!

I immediately reverted the permissions back to being wrong, but the site performance was still fine.

So I took a look at my recent commits:

* d267959 (HEAD, master) WooCommerce 3.0.7
* 2e7d858 My required fixes for WC Australia Post 2.4.3
* 7397f88 WC Australia Post Shipping 2.4.3
* 2ba100f Wordfence update
* 65beb13 Facebook update
* 5fa8e96 WP Update
* b50ac40 (origin/master) WooCommerce update

I checked out b50ac40 as a test, but performance was still fine. So, unfortunately, I’m not really sure what has happened here, and/or what has fixed it. Unfortunately, the wflogs directory is excluded from my repo, so it’s possible that whatever was done after I corrected the permissions was enough to resolve the issue?

• This reply was modified 7 years, 6 months ago by jaydisc.

Hi @jaydisc,

Thanks for letting us know! I’m glad you managed to identify the cause of the issue and to fix it.

If a request breaks a firewall rule or is blocked at the firewall level for any other reason, Wordfence will (attempt to) write into wflogs.
So it is possible that wp-content/wflogs not being writable was affecting the performance.

I would recommend you keep an eye on the permissions on that folder to make sure that they are not modified, for example, by a cron job running under another user than the one the web server runs as.