Wordpress site traag na verhuizing

[Paul van der Vlis]

Hoi,

Ik heb een Wordpress site verhuist van een gespecialiseerde provider
naar mijn webserver. Eerst voor test, dus ik kan hem alleen zien via een
aangepast hosts-bestand.

Maar hij is nu erg traag, het laden van de eerste pagina duurt soms meer
dan 25 seconden... Mijn webserver is behoorlijk snel omdat alles op NVMe
staat, dus er klopt ergens iets niet.

Ik doe dit wel vaker, en dat gaat altijd wel goed. Ik kopieer de
bestanden, pas wat dingen aan (zoals de naam van de database). Verder
dump ik de database, pas daar de paden aan, fix de serialisatie, en lees
hem weer in.

Het viel me hier op dat er een map "wp-content/mu-plugins" was die niet
te kopieren was (een symlink naar elders). Dit zijn een soort verplichte
plugins:
https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/
Mijn ervaring is dat als je een plugin-mapje verwijderd de plugin gewoon
weg is. Dus dan zou er niets aan de hand zijn.

Verder was er een rare .htaccess van 1 byte groot, daar moest ik wat
anders inzetten anders werkten de paden niet. Wellicht stond er iets in
wat ik niet kon lezen via SFTP.

Ik heb ingelogged, maar ik zie in het beheer-interface geen
foutmeldingen o.i.d.

Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
correct, maar hij laadt heel erg traag...

Groet,
Paul

[Jaap]

Post by Paul van der Vlis
Hoi,
Ik heb een Wordpress site verhuist van een gespecialiseerde provider
naar mijn webserver. Eerst voor test, dus ik kan hem alleen zien via een
aangepast hosts-bestand.
Maar hij is nu erg traag, het laden van de eerste pagina duurt soms meer
dan 25 seconden... Mijn webserver is behoorlijk snel omdat alles op NVMe
staat, dus er klopt ergens iets niet.
Ik doe dit wel vaker, en dat gaat altijd wel goed. Ik kopieer de
bestanden, pas wat dingen aan (zoals de naam van de database). Verder
dump ik de database, pas daar de paden aan, fix de serialisatie, en lees
hem weer in.
Het viel me hier op dat er een map "wp-content/mu-plugins" was die niet
te kopieren was (een symlink naar elders). Dit zijn een soort verplichte
https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/
Mijn ervaring is dat als je een plugin-mapje verwijderd de plugin gewoon
weg is. Dus dan zou er niets aan de hand zijn.
Verder was er een rare .htaccess van 1 byte groot, daar moest ik wat
anders inzetten anders werkten de paden niet. Wellicht stond er iets in
wat ik niet kon lezen via SFTP.
Ik heb ingelogged, maar ik zie in het beheer-interface geen
foutmeldingen o.i.d.
Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
correct, maar hij laadt heel erg traag...

Een bijzonder probleem. Als ik het zou hebben zou ik eerst naar het
.htaccess kijken, kan je daar niet iets 'echts' maar onschuldigs in
zetten? Zit er niet een byte order mark voor die problemen oplevert?

Werkt de database snel als je er direct zelf een query naar toe stuurt?

Is er nog een process wat veel tijd neemt tijdens een request?

Ooit heb ik op mijn werk het verhaal gehoord van een leverancier die bij
elk request even naar huis belde. Maar ja, onze firewall stond dat niet
toe dus werd de applicatie zeldzaam traag. Heb je een firewall?

Heb je alle Apache plugins voor PHP geladen? Ik heb wel eens een Perl
applicatie gehad die zeldzaam traag was omdat een plugin ontbrak.

Veel succes!
Jaap

[Paul van der Vlis]

Post by Jaap

Post by Paul van der Vlis
Hoi,
Ik heb een Wordpress site verhuist van een gespecialiseerde provider
naar mijn webserver. Eerst voor test, dus ik kan hem alleen zien via
een aangepast hosts-bestand.
Maar hij is nu erg traag, het laden van de eerste pagina duurt soms
meer dan 25 seconden... Mijn webserver is behoorlijk snel omdat alles
op NVMe staat, dus er klopt ergens iets niet.
Ik doe dit wel vaker, en dat gaat altijd wel goed. Ik kopieer de
bestanden, pas wat dingen aan (zoals de naam van de database). Verder
dump ik de database, pas daar de paden aan, fix de serialisatie, en
lees hem weer in.
Het viel me hier op dat er een map "wp-content/mu-plugins" was die
niet te kopieren was (een symlink naar elders). Dit zijn een soort
https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/
Mijn ervaring is dat als je een plugin-mapje verwijderd de plugin
gewoon weg is. Dus dan zou er niets aan de hand zijn.
Verder was er een rare .htaccess van 1 byte groot, daar moest ik wat
anders inzetten anders werkten de paden niet. Wellicht stond er iets
in wat ik niet kon lezen via SFTP.
Ik heb ingelogged, maar ik zie in het beheer-interface geen
foutmeldingen o.i.d.
Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
correct, maar hij laadt heel erg traag...

Een bijzonder probleem. Als ik het zou hebben zou ik eerst naar het
.htaccess kijken, kan je daar niet iets 'echts' maar onschuldigs in
zetten?

Dat heb ik gedaan, ik heb er neergezet wat er default in staat.
Maar ik weet dus niet wat er in de originele stond.

Voordat ik dit deed deed de "voorkant" het wel, maar liep elke URL in
het niets.

Ik zat me nog te bedenken dat ik het wellicht niet zie via SFTP, maar
dat Apache het wel moet kunnen lezen. Via een applicatie als phpshell
zou ik het dus wel moeten kunnen lezen. Maar wellicht stuit dat weer op
andere problemen.

Post by Jaap
Zit er niet een byte order mark voor die problemen oplevert?

Dat ken ik niet goed.. Wat doet zoiets?

Post by Jaap
Werkt de database snel als je er direct zelf een query naar toe stuurt?

Er draaien vele websites op die server, deze draaien goed & snel.

Ik zat nog te denken aan te loggen op slow querys, maar heb daar niet
zoveel verstand van...

Dit wou ik eens bestuderen en proberen, aanwijzingen zijn welkom:
https://mariadb.com/kb/en/slow-query-log-overview/

Het valt me wel op dat de voorpagina veel trager is dan de andere pagina's.

Post by Jaap
Is er nog een process wat veel tijd neemt tijdens een request?

Hoe kom ik daar achter? Ik zie niets hierover in de logs.

Wat me daar wel opvalt is dat ik na elk request "nocache=1" zie.

Post by Jaap
Ooit heb ik op mijn werk het verhaal gehoord van een leverancier die bij
elk request even naar huis belde. Maar ja, onze firewall stond dat niet
toe dus werd de applicatie zeldzaam traag. Heb je een firewall?

Uiteraard, maar die doet niet veel bijzonders. Uitgaand verkeer en
antwoorden daarop zijn gewoon toegestaan.

Post by Jaap
Heb je alle Apache plugins voor PHP geladen?

Dat zijn er nogal wat... Vast niet alle.

Post by Jaap
Ik heb wel eens een Perl
applicatie gehad die zeldzaam traag was omdat een plugin ontbrak.

Ik zou toch verwachten dat in de logs te kunnen zien.

Groet,
Paul

[Paul van der Vlis]

Post by Paul van der Vlis

Post by Jaap

Post by Paul van der Vlis
Hoi,
Ik heb een Wordpress site verhuist van een gespecialiseerde provider
naar mijn webserver. Eerst voor test, dus ik kan hem alleen zien via
een aangepast hosts-bestand.
Maar hij is nu erg traag, het laden van de eerste pagina duurt soms
meer dan 25 seconden... Mijn webserver is behoorlijk snel omdat alles
op NVMe staat, dus er klopt ergens iets niet.
Ik doe dit wel vaker, en dat gaat altijd wel goed. Ik kopieer de
bestanden, pas wat dingen aan (zoals de naam van de database). Verder
dump ik de database, pas daar de paden aan, fix de serialisatie, en
lees hem weer in.
Het viel me hier op dat er een map "wp-content/mu-plugins" was die
niet te kopieren was (een symlink naar elders). Dit zijn een soort
https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/
Mijn ervaring is dat als je een plugin-mapje verwijderd de plugin
gewoon weg is. Dus dan zou er niets aan de hand zijn.
Verder was er een rare .htaccess van 1 byte groot, daar moest ik wat
anders inzetten anders werkten de paden niet. Wellicht stond er iets
in wat ik niet kon lezen via SFTP.
Ik heb ingelogged, maar ik zie in het beheer-interface geen
foutmeldingen o.i.d.
Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
correct, maar hij laadt heel erg traag...

Een bijzonder probleem. Als ik het zou hebben zou ik eerst naar het
.htaccess kijken, kan je daar niet iets 'echts' maar onschuldigs in
zetten?

Dat heb ik gedaan, ik heb er neergezet wat er default in staat.
Maar ik weet dus niet wat er in de originele stond.
Voordat ik dit deed deed de "voorkant" het wel, maar liep elke URL in
het niets.
Ik zat me nog te bedenken dat ik het wellicht niet zie via SFTP, maar
dat Apache het wel moet kunnen lezen. Via een applicatie als phpshell
zou ik het dus wel moeten kunnen lezen. Maar wellicht stuit dat weer op
andere problemen.

Post by Jaap
Zit er niet een byte order mark voor die problemen oplevert?

Dat ken ik niet goed..  Wat doet zoiets?

Post by Jaap
Werkt de database snel als je er direct zelf een query naar toe stuurt?

Er draaien vele websites op die server, deze draaien goed & snel.
Ik zat nog te denken aan te loggen op slow querys, maar heb daar niet
zoveel verstand van...
https://mariadb.com/kb/en/slow-query-log-overview/

Ik heb in /etc/mysql/mariadb.conf.d/50-server.cnf deze regels gezet:
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mariadb-slow.log
long_query_time = 10
log_slow_verbosity = query_plan,explain

Er verschijnt een /var/log/mysql/mariadb-slow.log, maar ik zie hierin
niets als ik de pagina reload.

Groet,
Paul

Post by Paul van der Vlis
Het valt me wel op dat de voorpagina veel trager is dan de andere pagina's.

Post by Jaap
Is er nog een process wat veel tijd neemt tijdens een request?

Hoe kom ik daar achter?  Ik zie niets hierover in de logs.
Wat me daar wel opvalt is dat ik na elk request "nocache=1" zie.

Post by Jaap
Ooit heb ik op mijn werk het verhaal gehoord van een leverancier die
bij elk request even naar huis belde. Maar ja, onze firewall stond dat
niet toe dus werd de applicatie zeldzaam traag. Heb je een firewall?

Uiteraard, maar die doet niet veel bijzonders. Uitgaand verkeer en
antwoorden daarop zijn gewoon toegestaan.

Post by Jaap
Heb je alle Apache plugins voor PHP geladen?

Dat zijn er nogal wat... Vast niet alle.

Post by Jaap
Ik heb wel eens een Perl applicatie gehad die zeldzaam traag was omdat
een plugin ontbrak.

Ik zou toch verwachten dat in de logs te kunnen zien.
Groet,
Paul

[Richard Lucassen]

On Tue, 30 Jan 2024 16:24:12 +0100

Post by Paul van der Vlis
Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
correct, maar hij laadt heel erg traag...

Zou het een resolving probleem kunnen zijn? Dat-ie naar z'n eigen
hostname zoekt die niet bijvoorbeeld in /etc/hosts staat?

[Paul van der Vlis]

Post by Richard Lucassen
On Tue, 30 Jan 2024 16:24:12 +0100

Post by Paul van der Vlis
Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
correct, maar hij laadt heel erg traag...

Zou het een resolving probleem kunnen zijn?

Zoiets zou kunnen, maar hoe kom ik er achter?
Ik gebruik mijn eigen nameservers.

Post by Richard Lucassen
Dat-ie naar z'n eigen
hostname zoekt die niet bijvoorbeeld in /etc/hosts staat?

Als hij via DNS naar zijn domeinnaam zoekt krijg hij inderdaad een heel
ander IP. Maar dat is normaal geen probleem.

Ik heb voor de grap even de domeinnaam in /etc/hosts gezet met het IP en
IPv6 van die machine, maar dat maakt geen verschil.

De hostname staat wel correct in /etc/hosts. Het is een server die al
jaren correct draait met vele sites, ook veel Wordpress.

Groet,
Paul

[Richard Lucassen]

On Wed, 31 Jan 2024 11:33:46 +0100

Post by Paul van der Vlis

Post by Richard Lucassen
Dat-ie naar z'n eigen
hostname zoekt die niet bijvoorbeeld in /etc/hosts staat?

Als hij via DNS naar zijn domeinnaam zoekt krijg hij inderdaad een
heel ander IP. Maar dat is normaal geen probleem.
Ik heb voor de grap even de domeinnaam in /etc/hosts gezet met het IP
en IPv6 van die machine, maar dat maakt geen verschil.
De hostname staat wel correct in /etc/hosts. Het is een server die al
jaren correct draait met vele sites, ook veel Wordpress.

Ik bedoelde eerder dat-ie zoekt naar de hostname van de server waar het
eerst op draaide. Je had het spul toch verhuisd? Misschien zoekt-ie wel
een niet zo belangrijke lib die op de oude server wel stond maar op de
nieuwe niet?

Apache in debug mode draaien een optie?

[Paul van der Vlis]

Post by Richard Lucassen
On Wed, 31 Jan 2024 11:33:46 +0100

Post by Paul van der Vlis

Post by Richard Lucassen
Dat-ie naar z'n eigen
hostname zoekt die niet bijvoorbeeld in /etc/hosts staat?

Als hij via DNS naar zijn domeinnaam zoekt krijg hij inderdaad een
heel ander IP. Maar dat is normaal geen probleem.
Ik heb voor de grap even de domeinnaam in /etc/hosts gezet met het IP
en IPv6 van die machine, maar dat maakt geen verschil.
De hostname staat wel correct in /etc/hosts. Het is een server die al
jaren correct draait met vele sites, ook veel Wordpress.

Ik bedoelde eerder dat-ie zoekt naar de hostname van de server waar het
eerst op draaide. Je had het spul toch verhuisd?

Inderdaad.

Post by Richard Lucassen
Misschien zoekt-ie wel
een niet zo belangrijke lib die op de oude server wel stond maar op de
nieuwe niet?
Apache in debug mode draaien een optie?

Dat doe ik nu, en dat blijkt zelfs per vhost geregeld te kunnen worden ;-)

Het zou een SSL probleem kunnen zijn. Uiteraard doet de SSL het niet
correct want dit is een test-verhuizing, daarom gebruik ik een verkeerd
certificaat en heb ik een uitzondering in Firefox toegevoegd. Normaal is
dat geen probleem, misschien hier wel door de HSTS policy?

Of heeft dit iets met mod_deflate te maken?

----------
[Wed Jan 31 12:58:31.245619 2024] [ssl:debug] [pid 826854]
ssl_engine_io.c(1147): [client 188.213.90.187:59426] AH02001: Connection
closed to child 5 with standa
rd shutdown (server mydomain.nl:443)
[Wed Jan 31 13:02:33.859558 2024] [ssl:debug] [pid 828018]
ssl_engine_kernel.c(415): [client 188.213.90.187:36442] AH02034: Initial
(No.1) HTTPS request received for child 10 (server mydomain.nl:443)
[Wed Jan 31 13:02:33.861954 2024] [authz_core:debug] [pid 828018]
mod_authz_core.c(815): [client 188.213.90.187:36442] AH01626:
authorization result of Require all granted: granted
[Wed Jan 31 13:02:33.861999 2024] [authz_core:debug] [pid 828018]
mod_authz_core.c(815): [client 188.213.90.187:36442] AH01626:
authorization result of <RequireAny>: granted
[Wed Jan 31 13:02:33.862647 2024] [authz_core:debug] [pid 828018]
mod_authz_core.c(815): [client 188.213.90.187:36442] AH01626:
authorization result of Require all granted: granted
[Wed Jan 31 13:02:33.862681 2024] [authz_core:debug] [pid 828018]
mod_authz_core.c(815): [client 188.213.90.187:36442] AH01626:
authorization result of <RequireAny>: granted

<hier duurt het lang, ik heb niets verwijderd>

[Wed Jan 31 13:03:00.576336 2024] [deflate:debug] [pid 828018]
mod_deflate.c(869): [client 188.213.90.187:36442] AH01384: Zlib:
Compressed 609772 to 86828 : URL /index.php
[Wed Jan 31 13:03:00.776425 2024] [ssl:debug] [pid 828018]
ssl_engine_kernel.c(415): [client 188.213.90.187:36442] AH02034:
Subsequent (No.2) HTTPS request received for child 10 (server
mydomain.nl:443), referer: https://mydomain.nl/
----------

Ik zag nog deze instelling:
SSLCompression off

Groet,
Paul

[Paul van der Vlis]

Op 31-01-2024 om 13:30 schreef Paul van der Vlis:

<knip>

Ik heb de compressie uitgezet met "SetEnv no-gzip 1" in de vhost
configuratie. Ik zie nu niets meer in de logs hierover.

Verder SSL uitgezet door in de SQL "https:" te vervangen door "http:",
ik zie nu niets meer over SSL in de logs.

Het lijkt met "mod_authz" te maken te hebben, dat is het enige wat ik
nog zie in error_log:
--------
[Wed Jan 31 14:15:26.166270 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of Require all granted: granted
[Wed Jan 31 14:15:26.166382 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of <RequireAny>: granted
[Wed Jan 31 14:15:26.166860 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of Require all granted: granted
[Wed Jan 31 14:15:26.166885 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of <RequireAny>: granted

<hier zit de vertraging, niets verwijderd>

[Wed Jan 31 14:15:51.018340 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of Require all granted: granted, referer:
http://mydomain.nl/
[Wed Jan 31 14:15:51.018408 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of <RequireAny>: granted, referer: http://mydomain.nl/
[Wed Jan 31 14:15:51.035364 2024] [authz_core:debug] [pid 841414]
mod_authz_core.c(815): [client 188.213.90.187:37944] AH01626:
authorization result of Require all granted: granted, referer:
http://mydomain.nl/
--------

In mijn vhost-config staat gewoon dit:

<Directory /home/edagenda/www>
AllowOverride all
Require all granted
</Directory>


Groet,
Paul

[Paul van der Vlis]

Hallo allen,

Wat me nog opvalt is dat de vertraging optreed als er voor het eerst een

Post by Paul van der Vlis
authorization result of <RequireAny>: granted
<hier zit de vertraging, niets verwijderd>
[Wed Jan 31 14:15:51.018340 2024] [authz_core:debug] [pid 841348]
http://mydomain.nl/
[Wed Jan 31 14:15:51.018408 2024] [authz_core:debug] [pid 841348]

Groet,
Paul

[Paul van der Vlis]

Post by Paul van der Vlis
Hallo allen,
Wat me nog opvalt is dat de vertraging optreed als er voor het eerst een

Post by Paul van der Vlis
authorization result of <RequireAny>: granted
<hier zit de vertraging, niets verwijderd>
[Wed Jan 31 14:15:51.018340 2024] [authz_core:debug] [pid 841348]
http://mydomain.nl/
[Wed Jan 31 14:15:51.018408 2024] [authz_core:debug] [pid 841348]

Ik heb hem ook nog overgezet naar een andere domeinnaam, compleet met
SSL-certificaat wat nu goed werkt. Maar hij is nog steeds net zo traag.

Opvallend is dat de voorpagina een stuk trager is dan andere pagina's.
De voorpagina heeft echt wel een vertraging ruim boven de 20 seconden.
Andere pagina's laten je ongeveer 10 seconden wachten.

Iemand een idee?

Groet,
Paul

[Richard Lucassen]

On Wed, 31 Jan 2024 17:16:53 +0100

Post by Paul van der Vlis
Ik heb hem ook nog overgezet naar een andere domeinnaam, compleet met
SSL-certificaat wat nu goed werkt. Maar hij is nog steeds net zo traag.
Opvallend is dat de voorpagina een stuk trager is dan andere
pagina's. De voorpagina heeft echt wel een vertraging ruim boven de
20 seconden. Andere pagina's laten je ongeveer 10 seconden wachten.
Iemand een idee?

20 sec riekt wel erg naar wachten op een antwoord van iets, Wat zegt de
log van je DNS vanaf die host? Staat die server soms in een DMZ en wil
hij bijvoorbeeld een CRL ophalen o.i.d. wat-ie niet mag van de firewall?

Wil hij misschien ipv6 gebruiken en dat mag/kan ergens in het
path niet?

Het zijn lastige dingen in ieder geval.

[Paul van der Vlis]

Post by Richard Lucassen
On Wed, 31 Jan 2024 17:16:53 +0100

Post by Paul van der Vlis
Ik heb hem ook nog overgezet naar een andere domeinnaam, compleet met
SSL-certificaat wat nu goed werkt. Maar hij is nog steeds net zo traag.
Opvallend is dat de voorpagina een stuk trager is dan andere
pagina's. De voorpagina heeft echt wel een vertraging ruim boven de
20 seconden. Andere pagina's laten je ongeveer 10 seconden wachten.
Iemand een idee?

20 sec riekt wel erg naar wachten op een antwoord van iets, Wat zegt de
log van je DNS vanaf die host?

Hoe kan ik dat het beste bekijken?

Ik heb in de logs van mijn bind9 server gekeken, maar die logt zoiets
niet. Misschien kan hij ook meer verbose loggen.

Of door het netwerkverkeer te monitoren? (niet mijn sterke kant...)

Post by Richard Lucassen
Staat die server soms in een DMZ en wil
hij bijvoorbeeld een CRL ophalen o.i.d. wat-ie niet mag van de firewall?

Alles staat in het datacenter.

Het lijkt geen SSL probleem. Ik heb hem ook zonder SSL gedraaid en toen
was hij net zo traag.

Op diezelfde machine draai ik ook allerlei andere sites en die doen het
prima. Het is mijn shared hosting server.
https://vandervlis.nl draait er ook op, en ook vele Wordpress sites.

Post by Richard Lucassen
Wil hij misschien ipv6 gebruiken en dat mag/kan ergens in het
path niet?

IPv6 doet het prima...

Post by Richard Lucassen
Het zijn lastige dingen in ieder geval.

Ik log de "slow queries" boven 1 seconde. Ik zie een query van ongeveer
2 seconden bij een reload, dat lijkt me toch niet echt alarmerend.

Ik weet het ook even niet.

Groet,
Paul

[Richard Lucassen]

On Fri, 2 Feb 2024 00:53:16 +0100

Post by Paul van der Vlis

Post by Richard Lucassen
20 sec riekt wel erg naar wachten op een antwoord van iets, Wat
zegt de log van je DNS vanaf die host?

Hoe kan ik dat het beste bekijken?

Ik zoek dan in de logs op SERVFAIL, dan is er iets aan een server
gevraagd die niet bestaat of eventueel op NXDOMAIN

Post by Paul van der Vlis
Ik heb in de logs van mijn bind9 server gekeken, maar die logt zoiets
niet. Misschien kan hij ook meer verbose loggen.

Ik ken eigenlijk alleen maar unbound

Post by Paul van der Vlis
Of door het netwerkverkeer te monitoren? (niet mijn sterke kant...)

tcpdump -ni eth0 udp port 53

Of met -v zie je meer.

Post by Paul van der Vlis

Post by Richard Lucassen
Staat die server soms in een DMZ en wil
hij bijvoorbeeld een CRL ophalen o.i.d. wat-ie niet mag van de firewall?

Alles staat in het datacenter.

Ook in DC's staan fw's ;-)

Post by Paul van der Vlis
Het lijkt geen SSL probleem. Ik heb hem ook zonder SSL gedraaid en
toen was hij net zo traag.

Ja, en hij haalt niet bij ioedere query een CRL op lijkt me

Post by Paul van der Vlis
Op diezelfde machine draai ik ook allerlei andere sites en die doen
het prima. Het is mijn shared hosting server.
https://vandervlis.nl draait er ook op, en ook vele Wordpress sites.

Post by Richard Lucassen
Wil hij misschien ipv6 gebruiken en dat mag/kan ergens in het
path niet?

IPv6 doet het prima...

Post by Richard Lucassen
Het zijn lastige dingen in ieder geval.

Ik log de "slow queries" boven 1 seconde. Ik zie een query van
ongeveer 2 seconden bij een reload, dat lijkt me toch niet echt
alarmerend.
Ik weet het ook even niet.

Het zijn ook complexe systemen die je niet even snel kan debuggen lijkt
me. Als het een vast draaiend proces is zou je nog wat kunnen stracen;

strace -p <pid> -o /tmp/strace.txt -f

Maar ja, speld, hooiberg en je weet dan nog niet waar de hooiberg staat.

Bovendien zal die machine erg druk met van alles zijn neem ik aan. Maar
waarom doet hij een "reload"?

[Paul van der Vlis]

Post by Richard Lucassen
On Fri, 2 Feb 2024 00:53:16 +0100

Post by Paul van der Vlis

Post by Richard Lucassen
20 sec riekt wel erg naar wachten op een antwoord van iets, Wat
zegt de log van je DNS vanaf die host?

Hoe kan ik dat het beste bekijken?

Ik zoek dan in de logs op SERVFAIL, dan is er iets aan een server
gevraagd die niet bestaat of eventueel op NXDOMAIN

Post by Paul van der Vlis
Ik heb in de logs van mijn bind9 server gekeken, maar die logt zoiets
niet. Misschien kan hij ook meer verbose loggen.

Ik ken eigenlijk alleen maar unbound

Post by Paul van der Vlis
Of door het netwerkverkeer te monitoren? (niet mijn sterke kant...)

tcpdump -ni eth0 udp port 53

Wel interessant om te zien wat er gebeurd. In onderstaande dump heb ik
alles wat er niets mee te maken heeft weggehaald.

De DNS is nu overigens overgezet op mijn machine omdat de originele
hoster het niet meer deed. Dus alles staat nu echt online maar is heel
traag. Iets minder traag weliswaar, een reload van de pagina in de
browser duurt nu ongeveer 20 seconden.

Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij het
nog een keer, en die tweede keer is het goed. Lijkt me niet goed, maar
heeft hiermee wellicht weinig te maken.

Post by Richard Lucassen
Of met -v zie je meer.

Dit is met -v:
----
10:34:21.271056 IP6 (flowlabel 0x09a3e, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.47865 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0x00ae!] 30538+ A?
mydomain.nl. (32)
10:34:21.271076 IP6 (flowlabel 0xc3062, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.56527 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0xa699!] 44936+ A?
mydomain.nl. (32)
10:34:21.271078 IP6 (flowlabel 0xc3062, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.56527 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0x8279!] 54157+ AAAA?
mydomain.nl. (32)
10:34:21.271088 IP6 (flowlabel 0x09a3e, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.47865 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0x1e3b!] 22946+ AAAA?
mydomain.nl. (32)
10:34:21.271855 IP6 (flowlabel 0x4604b, hlim 64, next-header UDP (17)
payload length: 56) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.47865: [udp sum ok] 30538* 1/0/0 mydomain.nl. A
91.198.178.59 (48)
10:34:21.271855 IP6 (flowlabel 0x39b2f, hlim 64, next-header UDP (17)
payload length: 56) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.56527: [udp sum ok] 44936* 1/0/0 mydomain.nl. A
91.198.178.59 (48)
10:34:21.271956 IP6 (flowlabel 0x39b2f, hlim 64, next-header UDP (17)
payload length: 68) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.56527: [udp sum ok] 54157* 1/0/0 mydomain.nl. AAAA
2a01:1b0:7999:424::59 (60)
10:34:21.271956 IP6 (flowlabel 0x4604b, hlim 64, next-header UDP (17)
payload length: 68) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.47865: [udp sum ok] 22946* 1/0/0 mydomain.nl. AAAA
2a01:1b0:7999:424::59 (60)
10:34:21.301336 IP6 (flowlabel 0x64cae, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.60662 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0x9905!] 44277+ A?
mydomain.nl. (32)
10:34:21.301364 IP6 (flowlabel 0x64cae, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.60662 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0xabe1!] 39422+ AAAA?
mydomain.nl. (32)
10:34:21.302046 IP6 (flowlabel 0x291f6, hlim 64, next-header UDP (17)
payload length: 56) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.60662: [udp sum ok] 44277* 1/0/0 mydomain.nl. A
91.198.178.59 (48)
10:34:21.302046 IP6 (flowlabel 0x291f6, hlim 64, next-header UDP (17)
payload length: 68) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.60662: [udp sum ok] 39422* 1/0/0 mydomain.nl. AAAA
2a01:1b0:7999:424::59 (60)
-------

Post by Richard Lucassen

Post by Paul van der Vlis

Post by Richard Lucassen
Staat die server soms in een DMZ en wil
hij bijvoorbeeld een CRL ophalen o.i.d. wat-ie niet mag van de firewall?

Alles staat in het datacenter.

Ook in DC's staan fw's ;-)

Bij mij is het vrij overzichtelijk. Uitgaand verkeer en antwoorden
daarop staan op deze machine open.

Post by Richard Lucassen

Post by Paul van der Vlis
Het lijkt geen SSL probleem. Ik heb hem ook zonder SSL gedraaid en
toen was hij net zo traag.

Ja, en hij haalt niet bij ioedere query een CRL op lijkt me

Inderdaad.

Post by Richard Lucassen

Post by Paul van der Vlis
Op diezelfde machine draai ik ook allerlei andere sites en die doen
het prima. Het is mijn shared hosting server.
https://vandervlis.nl draait er ook op, en ook vele Wordpress sites.

Post by Richard Lucassen
Wil hij misschien ipv6 gebruiken en dat mag/kan ergens in het
path niet?

IPv6 doet het prima...

Post by Richard Lucassen
Het zijn lastige dingen in ieder geval.

Ik log de "slow queries" boven 1 seconde. Ik zie een query van
ongeveer 2 seconden bij een reload, dat lijkt me toch niet echt
alarmerend.
Ik weet het ook even niet.

Het zijn ook complexe systemen die je niet even snel kan debuggen lijkt
me. Als het een vast draaiend proces is zou je nog wat kunnen stracen;
strace -p <pid> -o /tmp/strace.txt -f
Maar ja, speld, hooiberg en je weet dan nog niet waar de hooiberg staat.
Bovendien zal die machine erg druk met van alles zijn neem ik aan. Maar
waarom doet hij een "reload"?

Ik bedoel daarmee dat ik op de "reload" van de browser klik. En kijk hoe
snel de site er weer is.

Groet,
Paul

[Wil Taphoorn]

Post by Paul van der Vlis
Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij het
nog een keer, en die tweede keer is het goed.

Die "tweede keer goed" is niet te zien. De dump zegt dat de client
in drie sessies om A en AAAA records van zichzelf vraagt, *alle* zes
aanvragen met foute checksum. Dat de server op deze zes aanvragen
toch het goede antwoord geeft snap ik dan weer niet.

Kijk maar: (volgorde niet veranderd, sessienummers ervoor gezet)

1 client.47865 > server.53 [bad udp cksum} A?mydomain.nl.
2 client.56527 > server.53 [bad udp cksum} A?mydomain.nl.
2 client.56527 > server.53 [bad udp cksum} AAAA?mydomain.nl.
1 client.47865 > server.53 [bad udp cksum} AAAA?mydomain.nl.
1 server.53 > client.47865 [udp sum ok] mydomain.nl. A91.~~.59
2 server.53 > client.56527 [udp sum ok] mydomain.nl. A91.~~.59
2 server.53 > client.56527 [udp sum ok] mydomain.nl. AAAA2a01:~~::59
1 server.53 > client.47865 [udp sum ok] mydomain.nl. AAAA2a01:~~::59
3 client.60662 > server.53 [bad udp cksum} A?mydomain.nl.
3 client.60662 > server.53 [bad udp cksum} AAAA?mydomain.nl.
3 server.53 > client.60662 [udp sum ok] mydomain.nl. A91.~~.59
3 server.53 > client.60662 [udp sum ok] mydomain.nl. AAAA2a01:~~::59

[Paul van der Vlis]

Post by Wil Taphoorn

Post by Paul van der Vlis
Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij het
nog een keer, en die tweede keer is het goed.

Die "tweede keer goed" is niet te zien. De dump zegt dat de client
in drie sessies om A en AAAA records van zichzelf vraagt, *alle* zes
aanvragen met foute checksum. Dat de server op deze zes aanvragen
toch het goede antwoord geeft snap ik dan weer niet.
Kijk maar: (volgorde niet veranderd, sessienummers ervoor gezet)
1 client.47865 > server.53 [bad udp cksum} A?mydomain.nl.
2 client.56527 > server.53 [bad udp cksum} A?mydomain.nl.
2 client.56527 > server.53 [bad udp cksum} AAAA?mydomain.nl.
1 client.47865 > server.53 [bad udp cksum} AAAA?mydomain.nl.
1 server.53 > client.47865 [udp sum ok] mydomain.nl. A91.~~.59
2 server.53 > client.56527 [udp sum ok] mydomain.nl. A91.~~.59
2 server.53 > client.56527 [udp sum ok] mydomain.nl. AAAA2a01:~~::59
1 server.53 > client.47865 [udp sum ok] mydomain.nl. AAAA2a01:~~::59
3 client.60662 > server.53 [bad udp cksum} A?mydomain.nl.
3 client.60662 > server.53 [bad udp cksum} AAAA?mydomain.nl.
3 server.53 > client.60662 [udp sum ok] mydomain.nl. A91.~~.59
3 server.53 > client.60662 [udp sum ok] mydomain.nl. AAAA2a01:~~::59

Je hebt gelijk, het zijn steeds de aanvragen.

Ik moet hier een keer naar kijken.

Maar andere sites hebben hetzelfde op deze machine, dit is niet de
veroorzaker van het probleem van de trage site.

Groet,
Paul

[Richard Lucassen]

On Sun, 4 Feb 2024 10:44:30 +0100

Post by Paul van der Vlis

Post by Richard Lucassen
tcpdump -ni eth0 udp port 53

Wel interessant om te zien wat er gebeurd. In onderstaande dump heb
ik alles wat er niets mee te maken heeft weggehaald.
De DNS is nu overigens overgezet op mijn machine omdat de originele
hoster het niet meer deed. Dus alles staat nu echt online maar is
heel traag. Iets minder traag weliswaar, een reload van de pagina in
de browser duurt nu ongeveer 20 seconden.
Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij
het nog een keer, en die tweede keer is het goed. Lijkt me niet goed,
maar heeft hiermee wellicht weinig te maken.

Zet dat mydomain.nl eens in /etc/hosts met alleen het ipv4 nummer (en
eventueel later ook ipv6) Als het goed is gebruikt-ie dan de dns niet
meer voor dat domain.

Dit zie ik;

# tcpdump -vni wlan0 udp port 53
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:58:55.931258 IP (tos 0x0, ttl 64, id 60739, offset 0, flags [none], proto UDP (17), length 57)
192.168.66.252.51184 > 192.168.64.1.53: 10258+ A? mydomain.nl. (29)
22:58:55.936485 IP (tos 0x0, ttl 64, id 63622, offset 0, flags [none], proto UDP (17), length 73)
192.168.64.1.53 > 192.168.66.252.51184: 10258 1/0/0 mydomain.nl. A 92.63.163.157 (45)
22:58:55.937490 IP (tos 0x0, ttl 64, id 8767, offset 0, flags [none], proto UDP (17), length 57)
192.168.66.252.41981 > 192.168.64.1.53: 4363+ AAAA? mydomain.nl. (29)
22:58:55.939617 IP (tos 0x0, ttl 64, id 63624, offset 0, flags [none], proto UDP (17), length 85)
192.168.64.1.53 > 192.168.66.252.41981: 4363 1/0/0 mydomain.nl. AAAA 2a01:a680:a1:d::157 (57)
22:58:55.940446 IP (tos 0x0, ttl 64, id 55214, offset 0, flags [none], proto UDP (17), length 57)
192.168.66.252.50626 > 192.168.64.1.53: 23829+ MX? mydomain.nl. (29)
22:58:55.943856 IP (tos 0x0, ttl 64, id 63625, offset 0, flags [none], proto UDP (17), length 72)
192.168.64.1.53 > 192.168.66.252.50626: 23829 1/0/0 mydomain.nl. MX . 0 (44)

Post by Paul van der Vlis

Post by Richard Lucassen
Ook in DC's staan fw's ;-)

Bij mij is het vrij overzichtelijk. Uitgaand verkeer en antwoorden
daarop staan op deze machine open.

Ja, dus een Rus die je machine hackt heeft vrij spel, hij mag overal
heen. Ik zet een webserver altijd in een DMZ, zodat ze er zo weinig
mogelijk aan hebben als ik een onbedoelde extra root admin aan boord
heb ;-)

R.

[Paul van der Vlis]

Post by Richard Lucassen
On Sun, 4 Feb 2024 10:44:30 +0100

Post by Paul van der Vlis

Post by Richard Lucassen
tcpdump -ni eth0 udp port 53

Wel interessant om te zien wat er gebeurd. In onderstaande dump heb
ik alles wat er niets mee te maken heeft weggehaald.
De DNS is nu overigens overgezet op mijn machine omdat de originele
hoster het niet meer deed. Dus alles staat nu echt online maar is
heel traag. Iets minder traag weliswaar, een reload van de pagina in
de browser duurt nu ongeveer 20 seconden.
Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij
het nog een keer, en die tweede keer is het goed. Lijkt me niet goed,
maar heeft hiermee wellicht weinig te maken.

Zet dat mydomain.nl eens in /etc/hosts met alleen het ipv4 nummer (en
eventueel later ook ipv6) Als het goed is gebruikt-ie dan de dns niet
meer voor dat domain.

Inderdaad, en als er een IPv4 staat dan vraagt hij ook niet om een IPv6
aan de DNS.

Maar hij wordt er niet sneller van. Ook niet als er zowel een IPv4 als
een IPv6 in /etc/hosts staat.

Hij is nu overigens wel iets sneller dan voorheen, maar een reload van
de browser duurt nog altijd ca 19 seconden.

Post by Richard Lucassen
Dit zie ik;
# tcpdump -vni wlan0 udp port 53
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:58:55.931258 IP (tos 0x0, ttl 64, id 60739, offset 0, flags [none], proto UDP (17), length 57)
192.168.66.252.51184 > 192.168.64.1.53: 10258+ A? mydomain.nl. (29)
22:58:55.936485 IP (tos 0x0, ttl 64, id 63622, offset 0, flags [none], proto UDP (17), length 73)
192.168.64.1.53 > 192.168.66.252.51184: 10258 1/0/0 mydomain.nl. A 92.63.163.157 (45)
22:58:55.937490 IP (tos 0x0, ttl 64, id 8767, offset 0, flags [none], proto UDP (17), length 57)
192.168.66.252.41981 > 192.168.64.1.53: 4363+ AAAA? mydomain.nl. (29)
22:58:55.939617 IP (tos 0x0, ttl 64, id 63624, offset 0, flags [none], proto UDP (17), length 85)
192.168.64.1.53 > 192.168.66.252.41981: 4363 1/0/0 mydomain.nl. AAAA 2a01:a680:a1:d::157 (57)
22:58:55.940446 IP (tos 0x0, ttl 64, id 55214, offset 0, flags [none], proto UDP (17), length 57)
192.168.66.252.50626 > 192.168.64.1.53: 23829+ MX? mydomain.nl. (29)
22:58:55.943856 IP (tos 0x0, ttl 64, id 63625, offset 0, flags [none], proto UDP (17), length 72)
192.168.64.1.53 > 192.168.66.252.50626: 23829 1/0/0 mydomain.nl. MX . 0 (44)

Post by Paul van der Vlis

Post by Richard Lucassen
Ook in DC's staan fw's ;-)

Bij mij is het vrij overzichtelijk. Uitgaand verkeer en antwoorden
daarop staan op deze machine open.

Ja, dus een Rus die je machine hackt heeft vrij spel, hij mag overal
heen. Ik zet een webserver altijd in een DMZ, zodat ze er zo weinig
mogelijk aan hebben als ik een onbedoelde extra root admin aan boord
heb ;-)

Ik doe dat ook op sommige machines, maar niet op deze.

Ik vind het in de praktijk nogal lastig overigens, daarom heb ik op deze
machine andere methoden me te beschermen.

Groet,
Paul

[De ongekruisigde (ds. dr. in de kerk van Roodkapje)]

Post by Paul van der Vlis
Hoi,
Ik heb een Wordpress site verhuist van een gespecialiseerde provider
naar mijn webserver. Eerst voor test, dus ik kan hem alleen zien via een
aangepast hosts-bestand.
Maar hij is nu erg traag, het laden van de eerste pagina duurt soms meer
dan 25 seconden... Mijn webserver is behoorlijk snel omdat alles op NVMe
staat, dus er klopt ergens iets niet.
+++
Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
correct, maar hij laadt heel erg traag...

Te weinig geheugen (RAM) waardoor hij continu aan het swappen is?

[Paul van der Vlis]

Op 02-02-2024 om 18:45 schreef De ongekruisigde (ds. dr. in de kerk van

Post by De ongekruisigde (ds. dr. in de kerk van Roodkapje)

Post by Paul van der Vlis
Hoi,
Ik heb een Wordpress site verhuist van een gespecialiseerde provider
naar mijn webserver. Eerst voor test, dus ik kan hem alleen zien via een
aangepast hosts-bestand.
Maar hij is nu erg traag, het laden van de eerste pagina duurt soms meer
dan 25 seconden... Mijn webserver is behoorlijk snel omdat alles op NVMe
staat, dus er klopt ergens iets niet.
+++
Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
correct, maar hij laadt heel erg traag...

Te weinig geheugen (RAM) waardoor hij continu aan het swappen is?

Zoals ik al zei is het een shared hostingserver waarop allerlei sites
prima draaien. Dus nee, hij is niet aan het swappen.

Groet,
Paul

[Paul van der Vlis]

Op 30-01-2024 om 16:24 schreef Paul van der Vlis:

<knip>

Ik ben eruit gekomen door alle plugins te verwijderen op een
testmachine, en ze in kleine porties weer terug te zetten.

Ik deed het door de plugins directory leeg te maken, maar ik had net zo
goed alle plugins kunnen disabelen in de webinterface denk ik achteraf.

Wel belangrijk goed te noteren welke plugins al gedisabled waren, die
moet je natuurlijk niet gaan enabelen.

Het probleem bleek te komen door de plugin "Happy Elementor Addons Pro".

Alhoewel... op de testmachine (Debian 12) was het probleem hiermee
opgelost. Op de productiemachine (Debian 11) niet. Dus ik heb van de
testmachine de productiemachine gemaakt door de DNS te veranderen.

Ik wou wellicht nog wel uitzoeken wat het probleem op de voormalige
productiemachine was. Maar hij doet het nu in elk geval snel ;-)

Groet,
Paul