http-Aufruf geht, https braucht bis zu 2 Minuten

Hi,

ich betreibe zwei Blogs auf einer Datenbank (die Prefixe unterscheiden sich).
Der eine Blog läuft unter einer sehr alten WordPress-Version (2.0.x), der zweite Blog ist in der Version 3.0.1.

Aus dem Intranet kann ich beide Blogs per http bedienen und dies mit normalen Reaktionsgeschwindigkeiten. Normalerweise benutze ich die Blogs aus dem Internet heraus und verwende https. Die alte WordPress-Version reagiert normal schnell, die neue ist ätzend langsam, bis zu zwei Minuten vergehen, bis man von einem Beitrag zum anderen kommt.

Der https-Request kommt von Außen an meiner Firewall an und wird per Portforwarding auf eine Maschine in der DMZ weiter geleitet. Dort läuft eine aktuelle Apache2-Installation, die die Anfragen abhängig vom Pfad hinter der Domainangabe auf weitere virtuelle Maschinen in der DMZ verteilt (mit der Direktive ProxyPass - der weitergeleitete Request erfolgt mit http).

Diese Technik setze ich seit Jahren ein, sie funktioniert mit alten WordPress-Versionen sowie mit MediaWiki, SVN und WebDav einwandfrei.

Meine Vermutung:

• WordPress in der Version 3.0.x versucht erst eine Antwort mit https (der Ursprungsrequest ist ja https)
• Nach Ablauf eines Timers wird dann auf die Antwort mit http gegeben.

Messungen auf den beteiligten Maschinen zeigen während der Wartezeiten keinen IP-Trafik und keine Aktivitäten der beteiligten Apache-Server.

Gibt es einen Weg, das Verhalten der neuen WordPress-Versionen zu beeinflussen?

Gruß
Bernd

 

Hallo Ralf,

die Inspektion der Variablen _SERVER hat keinen Hinweis auf auf https oder den Port 443 ergeben. Der Request kommt über Port 80, so wie erwartet.

Ich habe auch mal die Function is_ssl manipuliert (sie lieferte immer false) - hat nichts gebracht.

Gruß
Bernd

 

Hi Ralf,

ich arbeite auf meinem eigenen Rechner (bzw. Intranet), nicht über einen Provider. Der Zugang zu meinem Rechner erfolgt über eine DynDNS-Adresse.

Da mein Intranet von Außen nur für wenige Personen geöffnet ist, baue ich gerade an einer offen erreichbaren, virtuellen Maschine, in der ich das nachbilde, was in der geschützten Umgebung nicht funktioniert.

Vielleicht finde ich dabei Unterschiede und kann das Problem lösen. Oder ein freundlicher Zeitgenosse testet von Außen und kann mir helfen.

Gruß
Bernd

 

Hi *,

ich habe die letzten zwei Tage einige Testfälle generiert und muss feststellen: meine Überschrift zum Thread ist falsch!

Das Problem ist nicht http oder https sondern sind Unterschiede in den Versionen 2.0 und 3.0 von WordPress.

Um meine Testfälle verstehen zu können, ist die Kenntnis meines Intranets wichtig.
Internet
|
v
Router
|
------------------ privates Netz 172.128.100.x (DMZ)
| : : : |
v v
'Maschine A' 'Maschine wpt'

Alle Anfragen über http (Port 80) und https (Port 443) werden vom Router an die Maschine 'A' weitergeleitet.
In der Maschine 'A' läuft ein apache2-Server, der Anhand der Pfadangabe entscheidet, welche Maschine für die Bearbeitung zuständig ist.
Wenn eine andere Maschine beauftragt wird, erfolgt die Weiterleitung per Apache-Directive ProxyPass.
Die Weiterleitung benutzt immer http, auch wenn der Request per https kam.

Für meine Testfälle habe ich eine virtuelle Maschine 'wpt' erstellt.
Sie bassiert auf debian, benutzt apache2, php5 und mysql5.0.32.
Vier WordPress-Installationen habe ich erstellt, je zwei mit der Version 2.0 und 3.0.
Sie benutzen alle die selbe mySQL-Datenbank, jede Installation hat ihren eigenen Tabellensatz (unterschiedliche Prefixe).

In der Maschine 'A' ist neben apache2 ebenfalls php5 und mysql5.0.32 installiert.
Hier sind zwei WordPress-Installationen erstellt, je eine mit der Version 2.0 und 3.0.

Damit ergeben sich die folgende 6 Testfälle:
lfdNr URL Protokoll WP-Version Ausführung in Maschine
1 http://v-h.homeip.net/wordpress-20/ http 2.0.10 A
2 http://v-h.homeip.net/wordpress-30/ http 3.0.1 A
3 http 2.0.10 wpt
4 http 3.0.1 wpt
5 https 2.0.10 wpt
6 https 3.0.1 wpt

Die genannten URLs können zum Testen verwendet werden ('/' am Ende ist wichtig!).
Zum Test der normalen Geschwindigkeit (ohne Nutzung von WordPress) kann 'mein_script.php' an die URL angehängt werden.
[ Nach Abschluss dieses Threads werde ich die Zugänge wieder verschließen. ]

Die von mir beobachteten Geschwindigkeitsunterschiede durch die interne Weiterleitung sind maginal.
Krass sind die Unterschiede zwischen Version 2.0 und 3.0. Dabei spielt die interne Weiterleitung offensichtlich keine Rolle.

Der Fehler muss an einer ganz anderen Stelle liegen. In der php.ini habe ich das Memory-Limit von 16 auf 48 MByte erhöht, brachte aber nichts.

Diese Diskussion sollte ggfs an einer anderen Stelle des Forums weitergeführt werden. Der Admin möge den Thread bitte verschieben.

Gruß
Bernd

PS: Der Tipp von Ingo hat leider nichts gebracht.

 

Hi Ingo,

dein Tipp geht sicher in die richtige Richtung.
Mit tcpdump, netstat und lsof sowie der paralellen Überwachung des Logs von Apache konnte ich sehen,
dass jeder Request von Aussen sofort ankommt.

Nach einem Abbruch des ersten Request und sofortiger Wiederholung funktioniert alles, wie erwartet.
Nach einer Minute (plus knapp eine Sekunde) behebt sich fehlerhafte Zustand von selbst.
Bricht man keinen Request ab, dauert jeder eine Minute.
Bricht man einen ab, kann man anschließend normal arbeiten.
Es darf jedoch keine längere Pause entstehen.
Ist die Pause länger als 25 .. 30 Sekunden, kommt das Programm wieder in den fehlerhaften Zustand.

Während des fehlerhaften Zustands gibt keine Kontaktversuche nach Außen.
Auch meine Firewall liefert keine Hinweise auf abgewiesene Pakete.
Die Maschinen der DMZ dürfen über die Ports 80, 53 und 123 mit der Außenwelt Kontakt aufnehmen,
dies ist bisher immer ausreichend gewesen.

Nun bleibt die Frage, auf was wartet der PHP-Code.
Der Abbruch eines Requests und seine Wiederholung scheint den Programmablauf für kurze Zeit in den richtigen Zustand zu bringen.
Oder man muss dem Programm geben, worauf es wartet - nur was könnte es sein?
Meine Forschungen haben haben keine Hinweise ergeben.

Gibt es ein Forum, in dem man mit den Entwicklern Kontakt aufnehmen kann?
Es geht ja nun nicht mehr um Fragen zur Installation.
Eine Frage der Konfiguration wird es wohl auch nicht sein.
Ich vermute fehlerhaften Code oder Unverträglichkeit in der Betriebssystemumgebung.
Irgend etwas wird erwartet, was in meiner Umgebung nicht vorhanden ist.

Gruß
Bernd

 

Hi Ingo,

den Hinweis aus das Plugin habe ich nicht die Aufmerksamkeit zukommen lassen, die ihm gebührt.
Ich bin zutiefst zerknirscht!!

Habe das "123 HTTP Transport" installiert.
Wenn "streams" und "fopen" deaktiviert sind, läuft alles wunderbar.

-------- Problem behoben --------

Vielen Dank für deine Hilfe.
Bernd

PS: Beim Aktivieren des Plugin gab es diese Fehlermeldung:
"Das Plugin hat unerwartet 166 Zeichen während der Aktivierung erzeugt. Falls du Meldungen “headers already sent” siehst oder dein Feed nicht funktioniert, solltest du das Plugin deaktivieren oder löschen."
Es scheint jedoch gut zu funktionieren.

 

Hi Ralf,

so alt, wie du es darstellst, ist mein System nicht. Ich habe lauter virtuelle Maschinen unter xen laufen.
Grundlage ist der "c't-Server" vom letzten Jahr (Debian etch).

Alle Maschinen sind auf dem aktuellen Stand, den man mit 'apt-get update; apt-get -y upgrade' erreichen kann.
Natürlich weiß ich, dass es eine neuere Debian-Variante gibt und dass auch Apache, mySQl und PHP sich weiter entwickelt haben.

Ein neues System aufzusetzen bedeutet, neue Hardware beschaffen. Das laufende System wird gebraucht und kann nicht einfach vom Netz genommen werden.

Das Host-System muss mit neuem Debian nachgebaut werden (einen neueren "c't-Server" gibt es leider noch nicht) und alle virtuellen Maschinen müssen portiert werden (einige Hundert GByte).

Ich denke, ein einigermaßen gut funktionierendes System sollte zwei bis drei Jahre laufen, bevor man es gegen etwas Neueres austauscht - zumindest im privaten Bereicht.

Wir sollten die Diskussion an dieser Stelle beenden.
Ich danke allen, die zur Lösung meines Problems beigetragen haben.

Gruß
Bernd