Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
Topic: Website users temporarily lose access to website |
|
Author |
|
jmullaney
Joined: 12 Mar 2021 Posts: 3 Location: Minneapolis
|
Posted: Fri 12 Mar '21 16:53 Post subject: Website users temporarily lose access to website |
|
|
This problem shows up when there is poor WiFi connectivity, or no WiFi. The problem can happen on PCs, tablets, and phones – Windows, Apple, or Android. Example: the user is using an android phone with chrome browser to connect to my website (LAMP), and limping along with poor response, but still happy and productive. But then they can't reach the website at all. Blank white page. They can reach other websites but not my website. I've tried to have the users:
o refresh (reload) the webpage from the browser controls
o use the refresh button on my webpage (this tries to force a full reload by putting something new into the URL)
o close the browser and reopen it
None of these things work.
What does work is to wait for several minutes and then retry. This is unacceptable, for more reasons than just the annoyance factor. The web-app they are using on my website is time-critical, so the long delay can be very disruptive.
Also what works is switching to a different browser. If the user switches to a different browser the can regain access to my website immediately. Sometimes though, if the network connectivity is bad, they have to do this again, switching back to the original browser. I had one user have to do this about every 5 minutes.
Recently I had over 50 users (participating in an outdoor class) lose access all at the same time. I couldn’t ask the whole group to switch to a different browser, so they had to just wait it out for several minutes and then retry. But some students did not lose access when most did. I did not have the chance to determine if there was a difference in devices/browsers for the students that did not lose access.
It seems like the bad connectivity causes Apache (or other intermediary) to temporarily ignore an offending browser connection. Perhaps some mechanism whereby the socket (or PHP session) is marked "bad" but not closed. So that socket/session has to timeout before the same browser-session can gain access again. Perhaps by switching browsers, a new “connection” is opened and the old one abandoned. I'm just guessing at a possible mechanism.
I've looked at the apache error log, apache access log, php error log, and php-fpm error log. I don't see anything that coincides with this connectivity-related problem. My php max_execution_time is set to 120. I'm not hitting that.
Perhaps a clue: A month before this problem came to my attention I had migrated my website to a new server.
Currently my LAMP server is running on: CentOS (7.9.2009), Apache/2.4.46 (cPanel), MySQL (10.3.28-MariaDB) , PHP 7.4.16.
Any suggestions would be much appreciated. |
|
Back to top |
|
James Blond Moderator
Joined: 19 Jan 2006 Posts: 7371 Location: Germany, Next to Hamburg
|
Posted: Fri 12 Mar '21 21:59 Post subject: |
|
|
Did you try KeepAlive Off ?
And tried different values for KeepAliveTimeout ? |
|
Back to top |
|
jmullaney
Joined: 12 Mar 2021 Posts: 3 Location: Minneapolis
|
Posted: Fri 12 Mar '21 22:28 Post subject: |
|
|
James Blond wrote: | Did you try KeepAlive Off ?
And tried different values for KeepAliveTimeout ? |
No I have not tried anything related to keepalives. Here are some of the settings in my current httpd.conf:
Code: | StartServers 5
<IfModule prefork.c>
MinSpareServers 5
MaxSpareServers 10
</IfModule>
ServerLimit 256
MaxRequestWorkers 5000
MaxConnectionsPerChild 10000
KeepAlive On
KeepAliveTimeout 5
MaxKeepAliveRequests 100
Timeout 300 |
Are you suggesting turning off keepalives as an experiment, or that it might be better for me to run that way permanently?
My current setting of 5 seconds for KeepAliveTimeout does seems excessive - maybe 1 second would be better.
It seems to me that keepalives might help when network quality is poor. Can you give me an idea of how you think that keepalives might be affecting my problem? |
|
Back to top |
|
tangent Moderator
Joined: 16 Aug 2020 Posts: 348 Location: UK
|
Posted: Sat 13 Mar '21 0:31 Post subject: |
|
|
You don't say which MPM you're using, though your config snippet suggests you're using prefork. Is that because your PHP code is not thread safe? If you can, I'd recommend using worker or event MPM.
You might also want to look at TCP tuning, especially since you suggest problems started after migrating to a new system.
In the past I've increased the socket ListenBackLog from the default of 511 to 1024, to help with slow connections. Note, on Linux you also need to increase the kernel variable net.core.somaxconn to at least this figure (often defaults to 128), else the backlog process doesn't work properly.
This kernel setting, along with a number of other network tuning entries, needs setting in /etc/sysctl.conf. See the following example article for some details on this backlog tuning - https://www.unixteacher.org/blog/tuning-apache-listenbacklog
Define network configuration in /etc/sysctl.conf and reload into the kernel with sysctl -p
Code: | net.core.somaxconn = 4096 |
|
|
Back to top |
|
jmullaney
Joined: 12 Mar 2021 Posts: 3 Location: Minneapolis
|
Posted: Sat 13 Mar '21 1:49 Post subject: |
|
|
tangent wrote: | You don't say which MPM you're using, though your config snippet suggests you're using prefork. Is that because your PHP code is not thread safe? If you can, I'd recommend using worker or event MPM. |
I don't know the words you speak. I will investigate...
Quote: | You might also want to look at TCP tuning, especially since you suggest problems started after migrating to a new system. |
I at least know these words, but I haven't done anything along these lines for decades. I will investigate...
Thanks, I will check that out...
Oh, my aching brain (grim determination) |
|
Back to top |
|
|
|
|
|
|