Gerade arbeite ich an einem Projekt, in dem die Anzahl der Tabellen auf einem MySQL-Server mit mehreren Datenbanken rasant steigt. Zur Verwaltung nutze ich u.a. phpMyAdmin in der Version 4.0.1. Nun haben wir kürzlich die ersten Testsysteme auf einen größeren Server mit einer restriktiven Firewall verlagert. Danach fiel mir auf, dass phpMyAdmin unmittelbar nach dem Login für ca. 1 Minute nicht reagiert, wenn man sich die Tabellen der angelegten Datenbanken auflisten lassen will. Irgendwann kommt dann jedoch die erwartet Übersicht über die Tabellen. Und danach funktioniert auch alles wieder so rasch wie erwartet.
Diese initale Verlangsamung von phpMyAdmin – besser dieses initiale Hängenbleiben – machte mich total nervös. Zumal dieses Verhalten für mich neu war, und ich es auf anderen Systemen bislang nicht beobachtet hatte. Wartezeiten von 1 Minute sind während hektischer Entwicklungsarbeiten nicht tolerierbar. Das beschriebene Verhalten tritt nämlich immer wieder auf, wenn die maximale Inaktivitätszeit, die in phpMyAdmin oder in den php-Einstellungen des Servers gesetzt ist, abläuft und man sich erneut einloggen muss. Und dann will man natürlich keine zusätzliche Verzögerung bei der Abfrage nach den vorhandenen Tabellen im Minutenbereich erleben.
Also hieß es: Logs einsehen. Die Firewall zeigte denn auch tatsächlich, dass der Server, auf dem phpMyAdmin installiert war, versucht, eine HTTP-Verbindung zu der Adresse 216.34.181.97 aufzubauen. Solche aktiven HTTP- Verbindungen in die weite Welt werden von unserem Server aus aber nicht zugelassen.
Ein Nachforschen mit “whois” zeigt, dass diese Adresse möglicherweise unter der Hoheit von SourceForge steht. Oder aber etwas mit phpmyadmin.net zu tun hat. Ok – für einen Test mal die Firewall-Regeln abändern und die Verbindung vorübergehend zulassen. Und siehe da:
Keine initiale Verlangsamung mehr, sondern ein gewohnt spritzig reagierendes phpMyAdmin. Reproduzierbar! Dass phpMyAdmin nach dem Startup so langsam reagierte, rührte also daher, dass das Programm die genannte HTTP-Verbindung erwartete, aber nicht bekam – und den Verbindungsversuch in einer solchen Situation vermutlich mehrfach startete, bis es schließlich aufgab.
Es ergeben sich mehrere Fragen:
Frage 1: Wozu dient dieser Verbindungsversuch von phpMyAdmin ?
Vermutlich(!) zur Abfrage von Update-Informationen (neue Versionen, …). Siehe hierzu den Informationsbereich auf der ersten Seite nach dem Öffnen von phpMyAdmin. Dort wird dargestellt, welche Version man gerade im Einsatz und ob es eine neuere gibt. Aber wer weiß …. in diesen Zeiten …. Ich habe es jedenfalls nicht persönlich im Code überprüft.
Frage 2: Gibt es einen Parameter, um das abzustellen ? Oder muss man mit einem initial sehr langsamen phpMyAdmin hinter einer Firewall leben ?
Nein, muss man nicht – und ja, es gibt einen Parameter. Siehe :
http://wiki.phpmyadmin.net/pma/Config#VersionCheck
In meiner Situation half es demzufolge, in der Datei “config.inc.php” folgende Einstellung einzufügen:
$cfg[‘VersionCheck’] = false;
Das fand ich dann doch sehr beruhigend. Und es löste mein Problem – die http-Anfrage findet danach nicht mehr statt. Und phpMyAdmin läuft dann trotz restriktiver Firewall-Einstellungen performant.
Ich habe das Thema auch im phpMyAdmin-Bereich unter “Stackoverflow” angesprochen.
http://stackoverflow.com/questions/18766123/required-but-not-granted-http-access-to-216-34-181-97-slows-phpmyadmin-down
Wurde wirklich sehr schnell beantwortet. Das Verhalten wurde von einem interessierten Zeitgenossen bestätigt. Dort kam dann noch der Tipp, dass man die Abfrage auch über einen Proxy abarbeiten kann. Siehe
https:
//phpmyadmin.readthedocs.org/en/latest/config.html#cfg_VersionCheckProxyUrl
Danke hierfür an M. Delisle.
Abschließend bleiben folgende Fragen an die phpMyAdmin-Entwickler offen:
Könnte man das Thema mit dem Versionscheck nicht auch anders lösen? Wieso muss diese Abfrage überhaupt automatisiert ablaufen? Und wenn schon – warum nicht dezent und asynchron im Hintergrund (Ajax) mit Einstellungen, die den User nicht blockieren ?
Ich bin daher schon gespannt auf die nächste Version dieses wichtigen und nützlichen Tools.
