is this something that happened once or is this a repeatable scenario?

This occurs only on Yesterday.

Now after making many tests, I guess the issue comes from the following.

We have a main website https://www.example.com, which uses a 15KB .htaccess, including rewriting rules for multi-languages.

Then recently we install vBulletin under https://www.example.com/forums/, which also contains a .htaccess.

Since .htaccess can inherit from the parent folder, it is likely that the combination of the root folder .htaccess with the /forums/ subdirectory .htaccess cause the problem.

When I try to rename the .htaccess to .htaccess.backup. Then when I reload any page, it will clear the old cache since there is no .htaccess in the root folder any more. Then if I rename it back to .htaccess, then the system will work well until someone access the pages under /forums/, which will also load the .htaccess under /forums/ and make the combination, then the problem comes again.

That is my guess.

[edited by: phranque at 10:52 am (utc) on Jun 21, 2023]
[edit reason] please use example.com [/edit]

while the directives in the server config files are processed once upon server startup, the .htaccess file directives are not "cached".
the directives in .htaccess files are processed each time a request is passed to the directory containing it.

If you have your WP install at the root directory and it is using a root directory .htaccess file, your second .htaccess file at the /forums directory may be not inheriting all the settings it would need. You need to be sure that traffic from either directory is getting the settings needed for it from both/either of your .htaccess files.

I would at least take a look at the access logs to see what is happening for visitors and requests for root directory resources from the /forums directory.

Hi, @not2easy +

I just check the access log and there are many lines, like below:

172.70.210.nnn - - [20/Jun/2023:23:13:34 -0700] "GET /forums/member/17931-username HTTP/2.0" 200 7976 "https://www.example.com/forums/member/17931-username" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.66 Safari/537.36"

This likes to be spammers.

But how to know whether they request root directory resources.

[edited by: not2easy at 4:20 pm (utc) on Jun 21, 2023]
[edit reason] anonymized per forum charter [/edit]

Also by removing the /forums/ folder, it seems the issue does not appear.

By the way, is the access log a DoS attack which makes the dashboard very slow?

172.70.210.nnn - - [20/Jun/2023:23:13:34 -0700] "GET /forums/member/17931-username HTTP/2.0" 200 7976 "https://www.example.com/forums/member/17931-username" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.66 Safari/537.36"

[edited by: not2easy at 4:22 pm (utc) on Jun 21, 2023]
[edit reason] anonymized per forum charter [/edit]

Incidentally...

which uses a 15KB .htaccess, including rewriting rules for multi-languages

That's not an unreasonable size for htaccess. (I just checked mine. The biggest site's htaccess is 18K; the shared htaccess is 20k. Definitely doesn't take the server 60 seconds to read them!) The main cause for htaccess-related delay is that it exists at all--or rather, that it is allowed to exist. The moment the server finds a single AllowOverride directive in the config file for the relevant directory, it has to check for htaccess on every request, even if it was in the same directory two picoseconds ago and didn't find one then.

But how to know whether they request root directory resources.

They don't have to. The question is whether /forums/ is in a directory that's physically located inside the same directory as the site root.

is the access log a DoS attack which makes the dashboard very slow?

Did you mean, does the quoted line from access logs indicate a DDoS attack? (“DOS attack” creates a pretty droll mental picture.) Only if the line you quote is one of hundreds of requests in rapid succession. Otherwise it's just a robot sending an autoreferer under the (mistaken) belief that this will make them less noticeable.

Most important: I’m puzzled by OP's reference to restarting the server. If it is your own server, why do you need to use htaccess at all? You could make things a lot easier on the server by simply turning off all AllowOverride directives and shifting all rules to the config file.

The separate /forums folder would need to have an appropriate .htaccess file that works with the root directory .htaccess file. If you have not set it to inherit, then WP rewrites aren't included in the /forums folder. That appears to be a forum user looking up a user profile. Only you would know whether the username shares that IP address. It is not related to DDOS it happens because of the WP settings and the snippet of WP rewrites that is in the root directory is conflicting with the .htaccess file in the /forums folder. Those two htaccess files need to work together.


Edited to add- as phranque asked earlier, please replace domains with example.com, please limit actual code to anonymized content for your privacy and for your users.

PS - I hadn't seen AllowOverride mentioned in this thread though that wouldn't help.

[edited by: not2easy at 4:38 pm (utc) on Jun 21, 2023]

That appears to be a forum user looking up a user profile.

In the quoted line, the referer is identical to the request. (I saw this thread before it was exemplified.) That's what made me jump straight to “robot with autoreferer”. In context it is generally easy to tell, because humans will request supporting files belonging to the page, while robots rarely do.

Thanks to all of your great helps!

A follow-up update:

1. The problem occurs since I try to install vBulletin in a subfolder of our website https://www.example.com/forums/
2. When the problem occurs, all WordPress instances under the same domain, i.e., https://www.example.com, https://www.example.com/blogs/ and https://www.example.com/license/ are all very slow. However, WP instances under other domains(but in the same server) are NOT affected.
3. After I backup and deleting the /forums/ subdirectory, the problem never occurs again. Though I need to wait for some more time to observe.

This is a dedicated server managed by a hosting company.

I asked the advanced support in the company why WP dashboard is so slow. And he just tell me to update the php.ini settings. After doing so and restart server for many times, the problem still exists so I try to solve by myself.

I do not plan to change the Apache config file as we may need to migrate the server later. And only cPanel account can be migrated.

After one day of normal status, now the problem occurs again. And the only solution is to rename .htaccess to .htaccess.backup, access a page under the domain example.com, and then rename .htaccess back.

The example.com directory contains your WP install, correct?

The .htaccess in the example.com directory contains something about 'Options' before the WP snippet of code at the end of the .htaccess file:

# BEGIN WordPress
<IfModule mod_rewrite.c>

blah blah blah

</IfModule>

# END WordPress

- correct?

It is at the very end of your .htaccess file, after your domain canonical rewrite, right?

The settings in your WP > Admin > Settings > General Settings panel agree with those rules, right?

So far so good. Now when you add a new subfolder 'forums' and it also has a .htaccess file, does that file contain something about 'Options' or RewriteBase /forums/ after a copy of your canonical rewrite rules at the top?

If you have neither Options nor canonical rewrite rules in subfolders, the server needs to try to find the linked resources and you can have numerous errors and delays.

@not2easy +

1. What is the "domain canonical rewrite"? Is it the one below(I find it in the root folder's .htaccess)

# 2015-05-08: Rewrite rule to redirect http to https version
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301,NC]

2. I have remove /forums/ folder completely. But the issue still reoccurs from time to time. Now the only solution is:
(1) Restart the server.
(2) Rename the .htaccess to someelse, and then rename it back.

3. I check the backup of a deleted forums folder, and it comment out the RewriteBase, as below:

# In some cases where you have other mod_rewrite rules, you may need to remove the
# comment on the following RewriteBase line and change it to match your folder name.
# This resets the other mod_rewrite rules for just this directory
# If your site was www.example.com/forum, the setting would be /forum/
#RewriteBase /

and there is no "Options"(I use find function to find keyword "Options")

Also I do not copy the canonical rewrite rules in forums .htaccess.

4. If a subfolder containing a .htaccess without a "Options" or RewriteBase will cause the problem, then there are many such subfolders that will also be the problem. Is that the case?

1. Yes the canonical rewrite ensures that if your domain uses URLs like https://www.example.com/ that if a visitor tries to visit https://example.com/, they will be sent to https://www.example.com/

This can happen when someone hears about your site but does not have a link so they type in the name or if they find a link to your site that is not using your preferred URL, they will all land on the same form you prefer to use. It prevent Google from seeing different versions and different, duplicate pages. That rule you list is part of the ruleset, it should also deal with the possibility of not coming in on port 80. And it does not need the NC flag that makes the server check every possible combination like eXAmpLe or ExAMpLe to process the rule.

If the people managing your server have covered the Inherit issue (that may be done in the configuration) then you don't need the RewriteBase directive. If you want to know for sure, you should be able to check whether it is properly rewriting to the preferred format within the /forums/ directory. I bring it up because from your description something is not working as expected. It is possible since your backup offers the RewriteBase lines - commented out - that you do need them.

Any subdirectories in the directory where you have installed WP, will use the settings in your WP > Admin > Settings > General Settings so that all the WP related folders don't need the RewriteBase, they are using the settings you have entered. (if the WP rewrite rules are after the canonical rewrite rules.)

It is not 'Options' that makes the difference, Inherit is one of the things you can control using Options, but it is not the 'only' Option you might see in a .htaccess file.

Up at the top of this thread there is a Menu dropdown labeled "Forum Options" and one of the places to find examples of right and wrong .htaccess content is there, in the Library [webmasterworld.com]
A person can find a lot of understanding in that Library.

But the mysterious is that:

1. I have already removed the whole folder /forums/, why the issue still exist.
2. The .htaccess has used for many years. And I make backup every week. It has not be changed a lot since the last month backup. Why the slow of the dashboard sudden appears in recent several days?
3. I have studies the RewriteBase and it only used for relative path in Target. I check all RewriteRule and they use absolute path so this should not be a problem.

And it does not need the NC flag that makes the server check every possible combination like eXAmpLe or ExAMpLe to process the rule.

In fact [NC] in this situation creates a teeny bit of extra work for the server, because then on every non-root request it first flattens the requested URL, even though the rule doesn't care what case it is.

Incidentally, the canonicalization rule should be broader, to cover both http/https AND www (with, or without, depending on individual preference). A common pair of Conditions (here for a site that prefers without-www) is

RewriteCond %{HTTPS} !on [OR]
RewriteCond %{HTTP_HOST} !^example\.com$

It is not 'Options' that makes the difference, Inherit is one of the things you can control using Options, but it is not the 'only' Option you might see in a .htaccess file.

Are you sure you’re not conflating Options--a core setting that can only be used in <Directory> sections of the config file--with RewriteOptions--a mod_rewrite directive that can be used in htaccess?

I never explain things the right way, that's what I meant by

It is not 'Options' that makes the difference, Inherit is one of the things you can control using Options, but it is not the 'only' Option you might see in a .htaccess file.

Because there are various 'Options' settings out there I was trying to find what was in use. I do not know what Apache version this is using. I wondered whether RewriteOptions Inherit was part of the setup. Apparently not. And there was nothing in the subfolder to deal with rewrites. Since removing that /forum/ subfolder removed the slowness I do think it was due to a missing RewriteBase directive. There was a rule, but commented out.

There is a related old 2015 thread with [webmasterworld.com...] that I thought might shed light for AlanCC. So far, I am guessing at the order and contents/rules that might be involved.

Hi, everyone,

Thank you for all your help.

I finally solve the problem. This post [serverfault.com...] gives me hints. So I check the error log of Apache and PHP FPM:

From Apache error log, I see one line of this:

[Mon Jun 26 20:10:43.367089 2023] [mpm_worker:error] server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

From PHP FPM error log, I see many lines of this:

[28-Jun-2023 03:42:30] WARNING: [pool example_com] server reached max_children setting (5), consider raising it

So I increase the PHP FPM limits as below:

Max Request from 20 to 128
Max Children from 5 to 75.

Now the error does not appear any more. The dashboard is always very fast.

Explanations:

1. The dashboard becomes slow when my PHP request is queued and wait for a completion of another one.
2. When I rename .htaccess, it seems some existing PHP requests will be cancelled. And then when I rename it back, the dashboard will be fast since the request can be served immediately.
3. The /forums/ and vBulletin just increase the number of PHP requests, which makes the waiting time longer or waiting more frequent. So when I remove them, it seems to "solve" the problem.
4. The limits seems to be domain-specific, see the PHP FPM error log. The main domain example.com is mostly visited by external visitors, so it will have the problem while other domains are actually for test purpose, so no one will visit it and they are be affected by the problem severely.

Hope this will help others with similar issues. Thanks to all of you again!

So I check the error log of Apache and PHP FPM:

my standard answer to many posts in this forum is invariably to "check the server error log files" and this is the one time i failed to do so.

When I rename .htaccess, it seems some existing PHP requests will be cancelled.

this is the part that seems like unexplained magic to me.
unless the server is somehow caching the .htaccess files for apache...

Let me double-check something. When you talk about renaming htaccess, do you mean literally just renaming the physical file, with no other changes? Or do you also mean changing the line

AccessFileName .htaccess

in the config file?

Just rename the physical file from .htaccess to .htaccess.backup

The issue still exists, but rare.

I find new warning in PHP FPM error log, as below:

[29-Jun-2023 05:00:34] WARNING: [pool example_com] server reached max_children setting (75), consider raising it

I just check the WHM/cPanel document:

1. Max Requests: Controls how many requests are served by a process (Max Children) before killing and spawning a new process.
2. Max Children: The number of PHP-FPM processes to spawn to process PHP code for web server requests.

So to my understanding, each time a new request comes, Apache will first utilize an existing Child process to process the request. If all existing Child process are full with Max Requests, then Apache will create a new Child process to process the request, until it reaches Max Children processes.

If that is correct, then my server should be able to handle Max Requests(128) * Max Children(75) = 9600 requests, about 96 times of the original ones(20 * 5).

And I check Apache Status from time to time, for most of times, it shows like below:

20 requests currently being processed, 130 idle workers

So, the total requests should <= 200, much less than 9600. Why I still get "server reached max_children setting (75)" error?