ScriptBlogger

.. ist für den anderen ein Server, der nicht wie gewünscht funktioniert.

Wir haben bei Host Europe einen virtuellen Server, der in den letzten Monaten anstandslos seinen Dienst verrichtete. Wenn mal etwas klemmte, war immer zu starker Traffic schuld.

Das letzte Mal allerdings ließ sich Traffic als Störfaktor¹ ausschließen. Die Symptome waren wie folgt:

HTTP: Die Seiten benötigten zum Teil mehrere Sekunden (5-10) zum Laden

FTP: Verbindung zum Server war anfangs nur sehr zäh, später gar nicht möglich

Plesk: Verbindung war sehr, sehr zäh

Mail: Funktionierte ohne Probleme

Ein Neustart des Systems hat die Probleme nur kurzfristig gelöst. Host Europe hat dann "[...] einige Optimierungen am Wirtssystem durchgeführt.", was aber auch nichts gebracht hat.

Nächste Antwort von Host Europe:

Leider lassen sich solche Geschwindigkeitsschwankungen bei geteilten Systemen wie dem VPS nicht generell vermeiden. [...]

Ausfall von FTP ist keine Geschwindigkeitsschwankung. Und Ladezeiten von Plesk und HTTP von über zwei bis drei Sekunden sind weder akzeptabel noch normal. Host Europe macht da seine Systeme schlechter als sie tatsächlich sind. Der Server lief in den letzten Monaten anstandslos.

Ein Neustart am nächsten Tag hat die Probleme zunächst gelöst. Wir werden sehen, wie lange das anhält.

Update: Es gibt Anzeichen, dass das Problem möglicherweise bei Kabel Deutschland lag. Unser Server bei Domainfactory machte plötzlich ebenfalls Zicken. Nach dem Wechsel auf die Telekom-Leitung hatte sich dass allerdings erledigt. Sorry hiermit an den Support von Host Europe. ;-) Das ändert jedoch nichts an der Tatsache, dass der Support von Host Europe ernsthaft der Meinung ist, dass man Ladezeiten von drei bis fünf Sekunden für eine Web-Seite in Kauf nehmen muss.

¹) Prinzipiell gesehen sind zuviele Besucher ein Luxusproblem. Man kann eigentlich nie genug Traffic haben. ;-)

Aus einem unerfindlichen Grund ist bei Plesk nicht vorgesehen, dass man per FTP auf die Server-Log-Dateien (Access-Log, Error-Log) zugreifen kann. Das Verzeichnis ist zu sehen, aber der FTP-Benutzer hat keinen Zugriff darauf.

Zum Auswerten der Log-Dateien muss die von uns verwendete Software aber per FTP auf die Log-Dateien zugreifen. Kann aber nicht. Abhilfe schafft chown. Einfach per SSH einloggen und den Eigentümer der Verzeichnisse statistics und logs auf den FTP-Benutzer ändern und alles ist wieder gut. B-)

Als Anbieter von Scripts für den Massenmarkt bekommt man hautnah den jeweils aktuellen Trend in der Branche mit. Vor ein paar Jahren zum Beispiel haben viele Anbieter die PHP-Funktion popen() gesperrt. Also schwenkten wir um und nutzen in unseren Scripten seitdem ausschließlich mail() zum E-Mail-Versand.

Aktuell heißt die Mode Return-Path. Der Mail-Header Return-Path enthält die E-Mail-Adresse, an die im Fehlerfall die Rückmeldung (Bounce) gesendet wird. Immer mehr Webspace-Provider verlangen, dass von Scripten versandte E-Mails diesen Header beinhalten. Und manche Provider benachrichtigen sogar ihre Kunden darüber.

Eine Sache kam jedoch nie in Mode: Register_globals = Off. ;-)

So sähe für uns der ideale Managed Server aus:

• Externe Domains möglich
• Datenbank-Server auf derselben Maschine
• PHP, Python, Ruby
• Zugang zur Konsole per SSH
• Frei definierbare Cron Jobs
• Bedienbare Verwaltungsoberfläche
• Zuverlässigkeit

Nichts außergewöhnliches, möchte man meinen. Das sieht so mancher Anbieter jedoch anders.

Ständig produzieren die Server von Domainfactory und Domaingo - Webspace und Managed Server - folgende Fehlermeldung:

Notice: session_start(): ps_files_cleanup_dir: opendir(/tmp) failed: Permission denied (13)

Lösungsvorschlag vom Support: Den Speicherort für die Session-Dateien per php.ini ändern oder Notices per error_reporting ausblenden. Beides wird sicherlich funktionieren, löst aber die Ursache des Problems nicht. :-(

Domaingo schreibt heute in einem Newsletter an seine Kunden, dass es technische Einschränkungen beim E-Mail-System gab. Falls unsere Projekte betroffen waren, haben wir das allerdings gar nicht mitbekommen.

Von den Problemen abgesehen, die Kommunikation von Domaingo ist wirklich vorbildlich. Vorausgesetzt natürlich, die Angaben stimmen auch. ;-)

In dem Newsletter wird detailliert dargestellt, welche Funktion wann und warum nicht verfügbar war. Erfreulich auch, dass Klartext bezüglich der Ursache gesprochen wird, die "... nach aktuellem Kenntnisstand in den Bereich des menschlichen Versagens einzuordnen ist". Wenn sonst bei irgendeinem Anbieter Probleme auftreten, sind üblicherweise Hardware-Fehler, Software-Probleme oder Dritte schuld. ;-) Ausnahmen bestätigen die Regel.

Bleibt zu hoffen, dass die angekündigten strukturellen, organisatorischen und sonstigen Maßnahmen und Notfallplanänderungen auch umgesetzt werden.

Alles in Allem lässt sich jedoch sagen, dass Domaingo in der Vergangenheit immer ein verlässlicher und günstiger Webhoster war. Die Funktionsvielfalt und der Support sind gut bis sehr gut. Aufpassen muss man allerdings, wenn die Besucherzahlen der eigenen Website durch die Decke gehen. Domaingo hat da den Finger ganz fix am Ausschalter, um die eigenen Server vor Überlastung zu schützen.

Für 1&1 scheint das Versenden von E-Mails mittels PHP-Script eine Herausforderung darzustellen. Es wird Zeit, dass der Hoster diese endlich mal annimmt und die Probleme löst.

Bei E-Mails, die von unseren Projekten versandt werden, fehlt sporadisch der korrekte Absender. Stattdessen steht dort "CGI-Mailer". Unsere Kunden wiederum klagen über ernstere Probleme wie Timeouts beim Versenden von E-Mails. Das nervt nicht nur gewaltig, sondern kann unter Umständen auch Geld kosten.

Alternativ könnte man die E-Mails über einen anderen Server per SMTP versenden. Falls die Probleme anhalten, werden wir das sicherlich ausprobieren.