Wenn Du schon Plugins nutzt kann die Datenbank nicht leer sein. Wie groß ist sie? Selbst bei deaktivierten Plugins sind dort immernoch deren Daten.
Gibt es irgendwelche Einträge in Error-Logs? Hast Du auch mal den Debug-Modus von WordPress aktiviert und dort geschaut was im debug.log steht? Siehe: https://wordpress.org/documentation/article/debugging-in-wordpress/
Ist die Reaktionszeit auch im Backend so trägt oder betrifft das nur das Frontend?
Was sagt der Hoster dazu?
Hast Du das Projekt 1:1 mal auf einem anderen Hosting untergebracht und läuft es da besser?
Thread-Starter
Sven
(@kabelhochbau)
- Ist die Reaktionszeit auch im Backend so trägt oder betrifft das nur das Frontend?
Beides ist super langsam
- Was sagt der Hoster dazu?
Strato: Ist mein Problem – weil „mein“V-Server. Er macht da nichts. Kann auch Hardware nicht Upgraden, das ist „auf Ihrer alten Plattform nicht mehr möglich. Den Tarif gibt es schon lange nicht mehr“.( naja, keine 5 Jahre alt).
- Wenn Du schon Plugins nutzt kann die Datenbank nicht leer sein
Richtig. Aktuell 1.481 Datensätze, 9,7 MiB, 62 Tabellen. Also „fast leer“. Hab ja noch nicht einmal mit dem Inhalt der Webseite begonnen.
Error-Logs usw – nichts auffälliges. Aber ich habe fast so den Verdacht, dass es keine Lösung als Wechsel des Anbieters gibt.
- Hast Du das Projekt 1:1 mal auf einem anderen Hosting untergebracht und läuft es da besser?
Nein. Habe einfach keinen…. Und es muß ja auf Windoes laufen, wegen noch einzurichtender Lexware-Anbindung.
Windows? Das alleine könnte schon ein Grund sein. Habe selten positives gehört über Hosting unter Windows. Was für eine Lexware-Anbindung wird da benötigt?
Ich würde dir dennoch empfehlen das Projekt mal zu kopieren und z.B. bei dir lokal laufen zu lassen. Das könntest Du mit XAMPP oder localwp machen. Ich würde ganz stark drauf tippen, dass es dann besser läuft.
Alternativ würde ich dir nahelegen dir jemanden zu suchen der sich mit Windows-Hosts auskennt. Ich denke nicht, dass WordPress hierbei das Problem ist, eher das System.
Was liefert denn in WP der Website-Zustand > Bericht > Datenbank bei „Datenbank-Host“, „Maximal erlaubte Paketgröße“ und „Maximale Anzahl von Verbindungen“? Wie hoch ist das memory-limit für PHP?
Thread-Starter
Sven
(@kabelhochbau)
Nun, Lexware (Professional Office Pro, 5 Netzwerk-Zugänge) benötigt Windows. Die Anbindung soll so aussehen: WordPress, WooCommerce, Germanized kommunieren über Woo2LX zu Lexware.
- Was liefert denn in WP der Website-Zustand > Bericht > Datenbank bei „Datenbank-Host“, „Maximal erlaubte Paketgröße“ und „Maximale Anzahl von Verbindungen“? Wie hoch ist das memory-limit für PHP?
` wp-core
version: 6.6.2
site_language: de_DE
user_language: de_DE
timezone: Europe/Berlin
permalink: /%year%/%monthnum%/%day%/%postname%/
https_status: false
multisite: false
user_registration: 0
blog_public: 1
default_comment_status: open
environment_type: production
user_count: 1
dotorg_communication: true wp-paths-sizes
.......
image_editor: WP_Image_Editor_GD
imagick_module_version: Nicht verfügbar
imagemagick_version: Nicht verfügbar
imagick_version: Nicht verfügbar
file_uploads: 1
post_max_size: 8M
upload_max_filesize: 2M
max_effective_size: 2 MB
max_file_uploads: 20
gd_version: bundled (2.1.0 compatible)
gd_formats: GIF, JPEG, PNG, WebP, BMP, AVIF, XPM
ghostscript_version: not available wp-server
server_architecture: Windows NT 10.0 AMD64
httpd_software: Microsoft-IIS/10.0
php_version: 8.3.13 64bit
php_sapi: cgi-fcgi
max_input_variables: 1000
time_limit: 60
memory_limit: 128M
admin_memory_limit: 256M
max_input_time: 60
upload_max_filesize: 2M
php_post_max_size: 8M
curl_version: 8.7.0-DEV OpenSSL/3.0.15
suhosin: false
imagick_availability: false
pretty_permalinks: true
current: 2024-11-12T08:51:15+00:00
utc-time: Tuesday, 12-Nov-24 08:51:15 UTC
server-time: 2024-11-12T09:51:04+01:00 wp-database
extension: mysqli
server_version: 8.0.40
client_version: mysqlnd 8.3.13
max_allowed_packet: 67108864
max_connections: 151 wp-constants
WP_HOME: undefined
WP_SITEURL: undefined
...
WP_MEMORY_LIMIT: 40M
WP_MAX_MEMORY_LIMIT: 256M
WP_DEBUG: false
WP_DEBUG_DISPLAY: true
WP_DEBUG_LOG: false
SCRIPT_DEBUG: false
WP_CACHE: true
CONCATENATE_SCRIPTS: undefined
COMPRESS_SCRIPTS: undefined
COMPRESS_CSS: undefined
WP_ENVIRONMENT_TYPE: Nicht definiert
WP_DEVELOPMENT_MODE: undefined
DB_CHARSET: utf8mb4
DB_COLLATE: undefined wp-filesystem
wordpress: writable
wp-content: writable
uploads: writable
plugins: writable
themes: writable
fonts: writable
Ich fragte danach, weil es meines Wissens auch Schnittstellen für WooCommerce zu Lexware gibt die keine Installation des Webs auf dem gleichen Host erfordern. Schau dir mal das hier an: https://office.lexware.de/partner/german-market-woocommerce/
Bei deinem Website-Bericht fällt mir ins Auge, dass die PHP-Einstellungen post_max_size und upload_max_filesize stark voneinander abweichen. Das sollte den gleichen Wert haben und ggfs. auch höher gestellt sein, ist aber keine Bedingung für dein Datenbankverbindungsproblem denke ich (es sei denn unter Windows läuft da etwas anders ..).
Bei der Datenbank fällt mir auf, dass max_allowed_packet relativ niedrig eingestellt ist, wenn ich es richtig sehe bei 68 MB. Ich würde den Wert mal versuchen höher zu setzen, z.B. auf 128 MB oder 256 MB.
Die max_allowed_packet habe ich gerade mal bei einigen Installationen bei verschiedenen Hostern nachgeschaut, das liegt bei den Sharedhostern überall bei 64/68 MB, ein Dedicated hat 128MB. Scheint also nicht das Problem zu sein.
Die max_connections variieren bei diesen Installationen zwischen 151 (beim Dedicated) über 400-500 (div.) bis hin zu 3000 (Stratos zentraler Shared-DB-Server). Würde ich also auch als unkritisch ansehen.
Wenn/da die MySQL Workbench flott läuft, wurde ich auf das Zusammenspiel von IIS und PHP als Ursache tippen. WP-Zustand meint zwar php_sapi: cgi-fcgi, aber evtl. mal mit einer Test-PHP-Datei ohne DB-Zugriff ausprobieren (echo 'Hello World!'; oder phpinfo();), ob die auch so langsam starten.
Die Suchergebnisse zu „WordPress IIS slow“ schlagen sonst noch vor, die Windows-PHP-Variante „Non Thread Safe“ zu verwenden, siehe https://windows.php.net/download/
Thread-Starter
Sven
(@kabelhochbau)
Okay, erstmal super dank für ure Ausführungen. Oben das habe ich nicht 100% verstanden – aber mit Ü50 bin ich noch immer lenfähig.
Tatsächlich habe ich den Verdacht, das Problem lässt sich gar nicht extern lösen. Will meine Sicht auf die Dinge mal so schildern:
Ist ja ein V-Server (bei Strato). Wenn ich – als Vergleich – ein „shared store“ verwalten würde, bekäme ja auch nicht jeder, der was bei mir einlagert, einen eigenen Lagerraum. Ich würde das Zeug annehmen und nach bestmöglichem System stapeln. Was wenig gebraucht wird in die Räume ganz nach hinten, Dinge mit ständigem Zugriff gleich vorne hin, dass man schnell dran kommt. Also nicht Meiers Zeug zu Meiers Zeug, sondern Möbel zu Möbeln und Schuhschachteln zu Schuhschachteln.
Jetzt kommt einer und will ständig seine ganzen Schuhschachteln in seine Möbel hin-und her räumen. Ich hab ihm zwar zugesichert, er kommt schnell an seine Möbel und schnell an seine Schuhschachteln – aber vom Schuhschachtel-Raum zum Möbellager ist es eben ein langer Weg.
Kann es sein, dass bei Strato eben diese interne Verbindung zwischen „PHP-Lager“ und „MySQL-Lager“ so weite Wege hat, dass ich mit dem Wechsel vom Badelatschen auf Sportschuhe auch nicht wirklich schneller bin?
Wie kann ich mit einem einfachen PHP auf meines Server testen, wie schenell die Verbindung zur Datenbank tatsächlich ist?
Grüße, Sven
Könnte ein Problem mit der internen DNS-Auflösung sein.
Das hier passt zu den 5 Sekunden Ladezeit (die bei Dir ja selbst bei /wp-cron.php oder der WP-internen Weiterleitung von /favicon.ico auftreten):
https://stackoverflow.com/questions/3278863/iis-mysql-performance-issue
Also die MySQL-GRANTs auf 127.0.0.1 statt „localhost“ umstellen und MySQL davon abhalten, den verbindenden Namen aufzulösen.
Und zusätzlich – oder es kann auch sein, dass das alleine schon ausreicht – in der wp-config.php die Definition des DB_HOST umstellen von
define( 'DB_HOST', 'localhost' );
auf
define( 'DB_HOST', '127.0.0.1' );
Siehe: https://www.harnessdigital.co.uk/post/reduce-dns-lookup-by-changing-db-host-to-127-0-0-1-in-wordpress-config
Das spart den internen DNS-Lookup auf localhost. Selbst wenn der über die hosts-Datei erfolgt und sonst nicht hakt, würde es auch dann noch ein paar Millisekunden sparen.
Das erklärt auch, warum das bei MySQL Workbench so nicht auftritt – dort hakt es nur beim ersten Verbindungsaufbau, was wohl nicht aufgefallen war. Danach hält MySQL Workbench die Verbindung zur DB offen und damit schnell. Dagegen baut PHP die DB-Verbindung bei jeder WP-Anfrage wieder neu auf.
Thread-Starter
Sven
(@kabelhochbau)
Vielen Dank für deinen Input.
Ja – diese Überlegung hatte ich auch schon. Die halbe Nacht dran gebastelt, und mich final aus dem MySQL-Server ausgesperrt. Noch dazu sogar aus dem Windows-Service von MySQL. Man lernt eben nie aus.
Über PING sehe ich übrigens keine Zeiten länger als 1ms, egal, ob per IP oder localhost. Der intene Router scheint also zu funktionieren, mal laienhaft ausgefrückt.
Seze nun MySQL neu auf, und alles gleich mit 127.0.0.1 statt localhost. Mal sehen. Parallel noch einen anderen V-Server bestellt.
Aber dein Ansatz ist schon mal nachvollziehbar. Bleibe am Ball.
Thread-Starter
Sven
(@kabelhochbau)
So, habe nun alles probiert – scheint wirklich an Strato zu liegen.
Nun, habe einen neuen Server gebucht, und schwupps, geht das alles zufriedenstellend schnell. Passt also zu den testergebnissen, dass WP auf Strato-Servern auf dem letzten Platz landet.
Man muß aber auch fairerweise sagen, dass ich nirgendwo einen günstigeren Windows-V-Server gefunden habe. Hetzner hat das z.B. garnicht, soll man sich selbst aus Linux + Iso basteln, so deren Antwort.
Grüße, Sven
