Beiträge von ApuxIT

Ich kann mich nicht daran erinnern, dass mir das Neuanlegen über das Kundeninterface für die Inklusiv-Externen in Rechnung gestellt wurde. Ich denke diese Gebühr bezieht sich nur auf Bestellungen über das Supportsystem. Die Einstellungen für die Externen bekommt man beim anlegen über das Interface angezeigt. Vor einer Änderungen würde ich das TTL für alle Einträge min. 48 Stunden vorher auf 1-2 Stunden stellen (maximum), damit die Downtime minimiert wird falls etwas nicht gleich läuft.

Wende dich ansonsten mal an den Support unter Verweis auf diesen Beitrag. Ich war bisher zu faul einen Bugreport zu schicken, da es ja bei mir nach erneutem Anlegen lief. Nur um sicherzugehen: wir reden hier von RELAY_ACCESS_DENIED Fehlern, oder? Was ich nicht verstehe, wenn dich dieser Bug betrifft, warum es manchmal durch geht und manchmal nicht. Eigtl. sollte der Fehler immer oder gar nicht kommen. Versuch mal die Bedingungen näher abzugrenzen (z.b. von host A nach host B scheitert es immer).

Gute Abend,
zunächst einmal möchte ich mich für die Aktivierung der Option bedanken! Diese ist zwar nirgends in den Tarifbeschreibungen enthalten, allerdings war diese Option bei mehreren meiner NC-Webspaces aktiviert.

Zunächst eine Richtigstellung meinerseits zu der erhöhten Ladezeit in den Abenstunden. Ich habe das Freitag und Samstag mal im Detail beobachtet und Sie scheinen Recht zu haben das dies nicht vom Hostsystem selbst ausgeht. Zunächst einmal gibt ein JS zur Conversionverfolgung von Google-Servern, welches die "gefühlte Ladezeit" massiv beeinflusst hat. Darüber hinaus laden in den Abendstunden größere Ressourcen (>150kb~) langsamer, was jedoch der eigentlichen Übertragung zugeschrieben wird und somit irgendwo auf der gesamten Strecke verursacht wird. Das würde ich damit nicht mehr dem Hostsystem zuordnen und muss meine Aussage von weiter oben revidieren *peinlich*. Ich beziehe mich hierbei auf das Ausliefern von statischen Dateien, da alles gecached wird.
Entschuldigen Sie bitte, dass ich für diese Verzögerungen zunächst das Hostsystem für verantwortlich gehalten habe.

Feedback zu Keep-Alive:
Darüber hinaus habe ich mich mit ausführlich mit der Performanz des Keep-Alives beschäftigt. Zunächst muss ich hierzu sagen, das die Webseite mit ca. 30 Ressourcen relativ wenig lädt und die Effekte bei mehr Ressourcen größer sein dürften. Ich stelle im Mittel auf Desktopgeräten eine gesteigerte Ladezeit von ca. 30-40ms fest was im konkreten Fall jedoch spürbar ist (kein partitielles Rendering sichtbar). Das hängt aber auch davon ab ob der Browser mittels preConnecting die Verbindungszeiten bereits selbst minimiert oder nicht. Ähnliche Effekte könnten jedoch auch durch Verwendung von Domain Sharding (http://www.domain.tld+static.domain.tld als CNAME) erzielt werden bei niedrigerer Last für den Host was sich jedoch mit Keep-Alive in die Quere käme. Einen weitaus wichtigeren Effekt auf die gefühlte Performanz hat das Keep-Alive jedoch auch: zuvor kam es vereinzelt vor, das Requests ziemlich genau 1,2 oder 3 Sekunden für das Connecting benötigten. Gefühlt trat das eher beim zügigen Durchklicken auf und ich vermute irgendeine Limitierung durch den Apache, die stark Spürbar sind. Ich hänge hiervon einen Screen an und konnte das auch auf anderen Hostsystemen ihres Unternehmens feststellen. Mit Keep-Alive treten diese Verzögerungen nie auf. Seltsamerweise betraft es häufig (aber nicht immer) die zuletzt geladenen Ressourcen (siehe Anhang). Das fiel nicht nur beim testen auf sondern auch bei Kunden die das als Feedback zurück gaben.
Die Effekte waren größer, wenn man von weiter entfernten Rechnern aus misst (z.B. Ost-/Südeuropa).

Ein zweiter und mein eigentlicher Grund für den Wunsch Keep-Alive aktivieren zu können liegt jedoch im Mobilbereich. Hier ist jeder gesparte Roundtrip und jede gesparte CPU-Last Gold wert und gefühlt gibt es da einen Unterschied im Bereich von 2-300ms (kann ich nicht messen, da Throttling etc. keinen echten Mobilbrowser simuliert und das Löschen des Caches umständlich ist). Bei Folgeaufrufen ist der Effekt weniger stark da alles aus dem Cache kommt. Kurzum: ich bin schon von Keep-Alive überzeugt und wenn es ein Option geben würde, dies bei der Bestellung zu einem Aufpreis von vlt. 1€ für einen kleinen Auftritt mit weniger als 150 Besucher/Tag zu aktivieren, würde ich das immer mitbuchen. Ich kann aber absolut nachvollziehen, das ab einer gewissen Besucherzahl eine solche Option zuviel Zeit blockiert.

Grüße aus der Eifel
M. Schmidt

Ich hatte genau die gleichen Probleme mit dem Relay Access Denied bei einer externen Domain auf exakt dem gleichen Mailserver. Die Konfiguration der externen Domains scheint nicht immer korrekt abzulaufen.
Gelöst wurde das ganze schließlich nur durch das löschen und neu anlegen der externen Domain. Das Problem war das der Mailserver sich nicht für Zuständig hielt obwohl die DNS Records korrekt waren und der TTL der alten Konfiguration längst abgelaufen war. Bestätigen lies sich diese Vermutung durch das Abschicken einer Mail über den neuen Server. Diese landete nämlich zielsicher auf dem alten Mailserver.

Vielleicht hilft dir das ja weiter, dass ein erneutes Anlegen der externen Domains die Probleme bei mir beseitigt hat.

~M. Schmidt

Ich habe eine Antwort vom Support erhalten. Scheinbar wurde auf dem Host das Keep-Alive Feature deaktiviert, was ich sehr schade finde. Es unterscheidet doch gerade den Qualitätshoster vom 0815 Massenanbieter, dass solch wichtige Einstellungen in Business-Tarifen aktivierbar sind und der Host auch entsprechende Kapazitäten hat. Scheinbar ist der Host aber ohnehin an seiner Grenze, was sich an 1-200ms längeren Ladezeiten zwischen 19-21 Uhr bemerkbar macht. Da lässt sich nichts machen, oder? Auf anderen Webspace-Paketen in ihrem Unternehmen ist Keep-Alive aktiviert und bringt spürbar bessere Ladegeschwindigkeiten.

Guten Abend,
es ist weder eine Bandbreitenbeschränkung eingestellt noch sind die Verbindungen beschränkt. Ein schnelles phpinfo() ergibt u.a. für das Modul apache2handler:

User/Groupapache(48)/48
Max RequestsPer Child: 4000 - Keep Alive: off - Max Per Connection: 100TimeoutsConnection: 60 - Keep-Alive: 15

War es falsch den CGI Modus auszustellen? In der .htaccess Datei kann ich übrigens nur

Header set Connection Keep-Alive

setzen alles andere resultiert in 500 Internal server error's. Vielleicht mache ich ja aber auch nur einen Fehler bei der Konfiguration, da ich das ehrlich gesagt noch nie manuell aktivieren musste. Der Browser macht keine Keep-Alive Verbindungen, baut also jedes mal neu auf (wegen des ,close - welches ich nicht wegbekomme).

Es handelt sich im übrigen um einen Expert-Tarif, bei dem so etwas doch eigentlich möglich sein sollte? Oder ist der Tarif diesbezüglich beschränkt?

Vielen Dank & schöne Grüße,
M. Schmidt

Guten Tag,
nachdem mir aufgefallen war das meine Seiten nach einem Umzug zu Netcup spürbar länger laden (6-700ms ohne Cache, bei anderen Hostern ca. 400ms), bin ich mal auf Ursachensuche gegangen. Dabei fiel mir auf, das Keep-Alive deaktiviert war, was sich natürlich beim Verbindungsaufbau für 30 HTTP-Ressourcen bemerkbar macht. Meine Frage daher: lässt sich Keep-Alive aktivieren, wenn ja wie? Ich hatte den Webspace von CGI auf das PHP-Apache Modul umgestellt und in der .htaccess die entsprechenden Header hinzugefügt, ohne Erfolg. Der Server sendet dann ein "Connection: keep-alive, close".

Grüße aus der Eifel,
Manuel Schmidt

Die Migration auf ein neues IMAP Konto ist im Thunderbird per Drag&Drop (alte Mails Markieren, in neuen Posteingang ziehen) möglich. Kostet nichts, außer etwas Zeit bei großen Emailkonten.

Grüße,
Manuel Schmidt