I made a fresh install of Ubuntu with ispconfig following the tutorial. As I only need Web and DB I skipped everything regarding email and dns. Also I did not install FTP. The server is running only one website is active and the server is only used from two persons that work on the website. So the performance should always be very good. Randomly some pages are very slow. It may take about 10 seconds until a page loads, which normaly loads in less then one second. I see that it takes a long time to do the TLS-Handshake. The website runs with php-fpm. I also tried fast-cgi, but not really a difference. In the error log of the webiste there is nothing. In the global error log i can find these errors: When using fast-cgi a also get: This is strange because at that time I was the only person connecting to the server and only called one or two pages. Python is not used in the website only php. I cannot see anything about the slow TLS-Handshake. Any ideas?
well the maxrequestworkers limit being reached will certainly cause delays. although you don't say if you've changed those settings from their default values at all. apart from the error logs, have you checked the access logs, just because you think only two people are using the site doesn't mean that's actually the case. if it's accessible from the internet you're probably getting loads of access attempts. also, although it shouldn't be necessary for a site with only a couple of users, you could try switching apache to mpm_event, and use php-fpm, both offer performance and resource utilisation improvements.
I left the default values, so they are pretty good (I also increased them for testing purpose) and the access log has nearly no other requests then mine. php-fpm is my favorite and is used in the website - fast-cgi was only used to see what happens. It seems to me that the TLS Handshake needs a lot of resources - but only sometimes.
One more info. I just disabled TLS1.3 in the vhost config (SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.3), where I added the -TLSv1.3. Now the website runs without problems. But I have another server with nearly the same configuration, where TLSv1.3 runs without problems. But I remember I had a similar problem on this other server. I think I made a change which I found here in some forum, a post from Till Brehm, but I forgot to make a documentation and do not find this post again. Has anybody seen this?
Not offhand, no. My first thought was maybe related to SSL stapling (possibly combined with bad/intermittent dns resolution?).
Bingo! "Bad DNS resolution" pointed me into the right direction. I forgot to look into my hosts file. Here I had an entry coming from some testing after the basic install of the server. I removed this, enabled TLS1.3 and it works What I do not understand is, why the problem comes up only with TLS1.3 and not with TLS1.2. I assume that my knowlede about TLS is not enought to understand this. Here is the info for everyone who might get a similar problem (my server's name is "web"). I had in hosts: 127.0.1.1 web web 127.0.0.1 localhost which is good, and a third line 111.222.111.222 web.mydomain.com web IP and name of course is only a dummy. This was obviously wrong and caused the problems with TLS1.3.
Using ISPConfig 3.2 on my VPS at Interserver.net, I was getting extremely slow (~30s) webpage loading, with the browser network panel reporting a delayed TLS response. I started noticing it over the past month, but it probably began once I upgraded my VPS to Ubuntu 20.04 several months ago. I went around with this one all over the place before I found the problem. The VPS environment at Interserver does not support ipv6. ISPConfig insisted on trying to use it! The cure: Disable ipv6 in Ubuntu. I used the grub fix shown here: (prefix)://itsfoss.com/disable-ipv6-ubuntu-linux (you can figure out the hypertext transfer protocol prefix with an "s" on the end), then search in page for "Disable IPv6 using GRUB". Remember to reboot. Disable ipv6 in Dovecot: In /etc/dovecot/dovecot.conf, remove "::" or "[::]" (which refers to ipv6) from the listen declaration, so it becomes "listen = *". (This one had me going around for awhile also.) Remember to reboot or (re)start Dovecot. Hope this helps! ------------- 8/11/2021: See the posts below about additionally changing the postfix configuration. Subsequently I have also changed the apache configuration to disallow ipv6 listening (check "ports.conf") just to be complete — no problems observed beforehand.
Also the postfix configuration should be changed to disallow ipv6, although failure to do so merely produces a warning, not a fatal error. Change "inet_protocols = all" to "inet_protocols = ipv4" in all main.* files in the /etc/postfix/ directory. Probably also a good idea to change "mynetworks = 127.0.0.0/8 [::1]/128" to "mynetworks = 127.0.0.0/8" in all those files. Remember to restart postfix ("service postfix restart") after making these edits.
You may be right. It was dovecot however, not postfix, that crashed and burned on trying to use nonexistent ipv6 service, hence my attention to it first. While an older reference, efod.se/dovecot-postfix-ipv6/ seems to imply independence of dovecot from the postfix configuration file "main.cf". Indeed, my whole mail system began functioning properly upon changing only dovecot.conf, albeit with some grumbling postfix messages in the log files. Also, thought the main.cf~2, main.cf~3, etc. files might be for different “sites”, and wasn’t sure a simple postfix restart would rebuild them, but I really don’t know. I have no plans to experiment with this. It works well now.
Adding a tilde is fairly common place to move something out of the way. the only niggle with it is that adding say, .bak makes it quite clear its a backup or at the very least its not used where the tilde is less clear in its meaning. All the same its still useful for keeping a backup of the file that was replaced.
i'd use both, i'd leave the system to use ~ for any system/automated backups, and use .bak for any that i make manually. easier then to keep track of what the system changed and what i changed.
