nicht angemeldet
Matthias Apsel
Der Martin
Der Martin
Der Martin
Der Martin
Der Martin
Der Martin
Der Martin
Der Martin
Der Martin
Hallo!
Ich habe ein Problem und weiß leider nicht weiter. :(
Wir betreiben einen Onlineshop. Die Warenkorb- und Ckeckoutseiten sind per SSL verschlüsselt. Genutzt wird ein Wildcard Zertifikat von Thawte.
Jetzt haben wir ab und zu Kunden, die unsere Warenkorbseite nicht aufrufen können. Die Kunden (mit denen wir in Kontakt treten konnten) hatten unterschiedliche Konstellationen hinsichtlich Ihrer Soft- und Hardware (Windows XP, Vista, 7, Mac OS X). Alle konnten via Firefox oder Internet Explorer (egal welche Version) _nicht_ auf unsere Warenkorbseite zugreifen. Entweder lädt die Seite extrem lange bis sie erscheint, oder es kommt am Ende eine Timeout Fehlermeldung. Allerdings ging es immer mit Google Chrome!!
Der Fehler ist durch uns leider nicht reproduzierbar. Auch haben wir viele Kunden, die bei uns dennoch bestellen.
Ich denke, dass hier weitaus mehr internetaffine User unterwegs sind, als in unserem Shop. Deshalb frage ich jetzt hier in die Runde, ob der ein oder andere bitte mal auf folgender Seite irgend ein Produkt in den Warenkorb legen kann und dann versucht den ersten Schritt zur Kasse zu gehen (Seite: Eingabe Adressdaten)? Bitte nicht den kompletten Bestelldurchgang durchführen.
Die URL lautet: http://shop.maennchen1.de
Ich weiß nicht ob das OK ist, aber ich würde mich selbstverständlich mit einem 10%-Gutschein unseres Shops für den entscheidenden Tipp erkenntlich zeigen. Sofern ich das hier darf und wir das Problem beheben können!
Om nah hoo pez nyeetz, Roger Rehnelt!
Deshalb frage ich jetzt hier in die Runde, ob der ein oder andere bitte mal auf folgender Seite irgend ein Produkt in den Warenkorb legen kann und dann versucht den ersten Schritt zur Kasse zu gehen (Seite: Eingabe Adressdaten)?
Ich hab schon Schwierigkeiten, das Formular auszufüllen.
Das Feld für den Namen ist weg. FF20, Win7
Matthias
Hallo,
Ich hab schon Schwierigkeiten, das Formular auszufüllen.
das Problem habe ich nicht, bei mir sieht alles normal und richtig aus (FF20, Linux Mint).
Das Feld für den Namen ist weg. FF20, Win7
In deinem Screenshot sieht es für mich so aus, als sei es nicht weg, sondern "nur" auf width:0 zusammengestaucht.
Oh, jetzt hab ich den skizzierten Effekt auch: Er tritt dann ein, wenn ein Pflichtfeld einmal focussiert war, und dann den Focus verliert, bevor etwas eingegeben wird - beispielsweise, weil man ein, zwei Felder weiter oben einen Fehler entdeckt hat und den erst korrigieren möchte.
Und tatsächlich, es hat per Direkt-Zuweisung an element.style width:0 bekommen. Witzigerweise funktioniert es trotzdem noch (Tab von einem Feld zum nächsten, blind tippen), aber so ein Bug darf IMO nicht bleiben.
Davon abgesehen ist mir aber nichts aufgefallen - keine lange Ladezeit, kein Timeout, kein Problem mit einem Zertifikat ...
Ciao,
Martin
Om nah hoo pez nyeetz, Der Martin!
Oh, jetzt hab ich den skizzierten Effekt auch: Er tritt dann ein, wenn ein Pflichtfeld einmal focussiert war, und dann den Focus verliert, bevor etwas eingegeben wird - beispielsweise, weil man ein, zwei Felder weiter oben einen Fehler entdeckt hat und den erst korrigieren möchte.
Auch wenn auf weiter klickt und nicht alle Pflichtfelder ausgefüllt hat, werden alle "angemahnten" Felder auf Nullbreite gebracht. Der Vergleich der E-Mail-Adressen kann imho auch schon (zusätzlich!) vor dem Absenden erfolgen.
Matthias
Moin!
Om nah hoo pez nyeetz, Roger Rehnelt!
Deshalb frage ich jetzt hier in die Runde, ob der ein oder andere bitte mal auf folgender Seite irgend ein Produkt in den Warenkorb legen kann und dann versucht den ersten Schritt zur Kasse zu gehen (Seite: Eingabe Adressdaten)?
Ich hab schon Schwierigkeiten, das Formular auszufüllen.
Das Feld für den Namen ist weg. FF20, Win7
Kann ich bestätigen, auch den Grund des Effekts. Browser: Opera 12
- Sven Rautenberg
Hallo!
Kann ich bestätigen, auch den Grund des Effekts. Browser: Opera 12
Meinst du den https Fehler, oder den CSS Fehler?
Letzteres wird zeitnah behoben. Aber wenn ihr schon auf dieser Seite seit, dann konntet ihr sie auch aufrufen und mein Problem (so wie ich) nicht reproduzieren :(
Aber wenn ihr schon auf dieser Seite seit, dann konntet ihr sie auch aufrufen und mein Problem (so wie ich) nicht reproduzieren :(
Jein. Denn der Abruf des Warenkorbs (nur des eigentlichen Skripts ohne den Payload wie CSS, JS, PICS hat aber schon auffällig lang gedauert. (fast 1 Sekunde)
Das braucht sich nur um ein "Geringes" vervielfachen, dann bricht der Browser ab. Das würde auch den Effekt erklären, dass das der Fehler nicht ohne weiteres verifizierbar ist. Sucht das PHP-Skript also auch nach Performancebremsen ab.microtime(true) ist dafür gut geeignet.
Womöglich ist es keine gute Idee, einen Shop in Wordpress einzubauen und dann noch Module wie PIWIK zu benutzen. Aber die Kunden werden nach dem ersten Schritt (Wordpress) natürlich auch das tun.
Hallo!
Jein. Denn der Abruf des Warenkorbs (nur des eigentlichen Skripts ohne den Payload wie CSS, JS, PICS hat aber schon auffällig lang gedauert. (fast 1 Sekunde)
Es geht hauptsächlich um Timeout-Meldungen, wie oben beschrieben. Also um Zeiten jenseits von 30 Sekunden, in denen gewartet wurde. Wir hatten geduldige Kunden dabei, die meinten, dass nach 5 Minuten die Seite erst aufgebaut wurde.
Es geht hauptsächlich um Timeout-Meldungen, wie oben beschrieben. Also um Zeiten jenseits von 30 Sekunden, in denen gewartet wurde. Wir hatten geduldige Kunden dabei, die meinten, dass nach 5 Minuten die Seite erst aufgebaut wurde.
Tja. Meine Glaskugel glänzt jetzt zwar, weil ich die ziemlich lange polieren musste um das rauszufinden - aber ich fürchte von hier an kann ich nichts mehr tun.
Ich kenne den PHP-Quellcode nicht. Zudem weiß ich ja nicht, ob das Problem mit dem derzeitigen großflächigen Angriff zusammenhängt und also nicht mehr auftritt, wenn meine Lösung (die längst nicht nur meine ist) angewendet wird. Die bremst die Angreifer nämlich schon früh und sehr performant aus.
Jörg Reinholz
Ich kenne den PHP-Quellcode nicht. Zudem weiß ich ja nicht, ob das Problem mit dem derzeitigen großflächigen Angriff zusammenhängt und also nicht mehr auftritt,
Unser Problem hat mit PHP und WordPress nichts zu tun. Das Problem tritt nur auf, wenn eine Seite via SSL aufgerufen wird. (Wir haben das selbe Phänomen auf einem anderen Server mit exakt dem selben Zertifikat.)
Deaktiviere ich den "SSL-Zwang" für die Warenkorbseite (so dass sie auch via http aufgerufen werden kann), klappt alles.
Hi,
Es geht hauptsächlich um Timeout-Meldungen, wie oben beschrieben. Also um Zeiten jenseits von 30 Sekunden, in denen gewartet wurde. Wir hatten geduldige Kunden dabei, die meinten, dass nach 5 Minuten die Seite erst aufgebaut wurde.
das müssen dann wohl Opera-Nutzer gewesen sein, denn Opera ist der einzige Browser, den ich als so hartnäckig kenne. Firefox bricht üblicherweise nach 30s ab, Internet Explorer nach meiner Erfahrung nach 60s. Opera wartet dagegen eine gefühlte Ewigkeit (auf jeden Fall weit über 5min), wenn der Webserver nicht gleich antwortet.
Wie Chrome sich da verhält, weiß ich nicht.
Aber etwas anderes möchte ich noch kritisch anmerken: Wenn ich bei einem Produkt auf "in den Warenkorb" klicke, erfolgt keine sichtbare Reaktion! Das ist ungewöhnlich.
Zwar sieht man, wenn man wieder nach oben scrollt, dass der Warenkorb nun einen Artikel enthält, aber zunächst kommt man in Versuchung, zwei- oder dreimal zu klicken, weil sich scheinbar nichts tut.
Ciao,
Martin
Om nah hoo pez nyeetz, Der Martin!
Aber etwas anderes möchte ich noch kritisch anmerken: Wenn ich bei einem Produkt auf "in den Warenkorb" klicke, erfolgt keine sichtbare Reaktion! Das ist ungewöhnlich.
Man würde sie auch sehen, wenn man die Seite so verkleinert, dass das Warenkorb-Info-Element zu sehen ist. position fixed, wäre eine Möglichkeit oder href="#" wenn man was in den Warenkorb legt, wobei letzteres auch zu Unmut führen kann, wenn man dann wieder nach unten scrollen muss, nur um weiter einzukaufen.
Zwar sieht man, wenn man wieder nach oben scrollt, dass der Warenkorb nun einen Artikel enthält, aber zunächst kommt man in Versuchung, zwei- oder dreimal zu klicken, weil sich scheinbar nichts tut.
ack.
Matthias
Das klingt gut. Danke für die Vorschläge!
Meiner Lösung bin ich aber leider immer noch nicht weiter. Ich hoffe, es melden sich noch mehr Leute, die einfach mal testen können, so wie angefragt.
Hallo,
Denn der Abruf des Warenkorbs (nur des eigentlichen Skripts ohne den Payload wie CSS, JS, PICS hat aber schon auffällig lang gedauert. (fast 1 Sekunde)
das nennst du auffällig lang? Das ist für mich eine durchaus übliche Reaktionszeit, die beim Verbindungsaufbau zu fast jedem Webserver anfällt (außer im eigenen LAN). Beim Aufbau einer SSL-Verbindung bin ich auch einmalig auftretende Verzögerungen von 3..5s gewöhnt.
Ciao,
Martin
das nennst du auffällig lang? Das ist für mich eine durchaus übliche Reaktionszeit, die beim Verbindungsaufbau zu fast jedem Webserver anfällt (außer im eigenen LAN). Beim Aufbau einer SSL-Verbindung bin ich auch einmalig auftretende Verzögerungen von 3..5s gewöhnt.
fastix.org (dahinter steckt mein CMS mit einer kleinen, aber ziemlich brutalen Optimierung) braucht ca. 150 ...180 Millisekunden für eine Seite (ohne nachzuladende Dateien).
Ich glaube manchmal darin bin ich ziemlich gut :)
Jörg Reinholz
Hallo,
das nennst du auffällig lang? Das ist für mich eine durchaus übliche Reaktionszeit, die beim Verbindungsaufbau zu fast jedem Webserver anfällt (außer im eigenen LAN). Beim Aufbau einer SSL-Verbindung bin ich auch einmalig auftretende Verzögerungen von 3..5s gewöhnt.
fastix.org (dahinter steckt mein CMS mit einer kleinen, aber ziemlich brutalen Optimierung) braucht ca. 150 ...180 Millisekunden für eine Seite (ohne nachzuladende Dateien).
Firebug meldet bei mehreren aufeinanderfolgenden Versuchen zwischen 336ms (bester Wert beim ersten Versuch) und 1.33s (schlechtester Wert) für http://www.fastix.org/, wovon zwischen 40 und 60ms auf den DNS-Lookup entfallen. Daran anschließend nochmal weitere 150..200ms für die Folgerequests (Stylesheets, Scripts, Bilder), die allerdings alle brav mit 304 beantwortet werden.
Ich glaube manchmal darin bin ich ziemlich gut :)
Kann schon sein. Aber die Netzwerk-Infrastruktur von meiner DSL-Anschlussdose bis zu deinem Server hast du nicht unter Kontrolle. Ich auch nicht. Und dort entstehen diese Verzögerungen - oder in meiner Fritzbüx, das kann ich auch nicht ausschließen.
Ciao,
Martin
Firebug meldet bei mehreren aufeinanderfolgenden Versuchen zwischen 336ms (bester Wert beim ersten Versuch) und 1.33s (schlechtester Wert) für http://www.fastix.org/, wovon zwischen 40 und 60ms auf den DNS-Lookup entfallen.
Heilige Schlepp...(ganz schlechtes Französisch wurde zensiert)! Da stimmt aber was nicht.
Solche Werte bekomme ich nur hin, wenn ich vom Lappi aus über WLAN und dann noch via VPN oder Proxy (squid->Privoxy) im Züricher Rechenzentrum ins Web gehe. Ich habs grad noch mal mit (Harcore-[F5]-ing) versucht: schnellster von 10 Versuchen: 102 ms, langsamster 170ms.
Ich hänge hier an einem DSL von Alice/Telefonica mit 6 statt der versprochenen 16 MBit/s, aber fastpath. fastix.org (81.28.232.70) ist auf einem massive shared server.
Jörg Reinholz
Hallo,
Firebug meldet bei mehreren aufeinanderfolgenden Versuchen zwischen 336ms (bester Wert beim ersten Versuch) und 1.33s (schlechtester Wert) für http://www.fastix.org/, wovon zwischen 40 und 60ms auf den DNS-Lookup entfallen.
Heilige Schlepp...(ganz schlechtes Französisch wurde zensiert)! Da stimmt aber was nicht.
möglich, aber das entzieht sich meinem Einfluss.
Ich hänge hier an einem DSL von Alice/Telefonica mit 6 statt der versprochenen 16 MBit/s, aber fastpath. fastix.org (81.28.232.70) ist auf einem massive shared server.
Und ich habe hier DSL von 1&1 mit 6Mbit laut Vertrag, aber 7.5Mbit laut DSL-Info der Fritzbüx. Das kommt daher, dass 1&1 mir vor längerer Zeit mal ein Upgrade auf 16Mbit für nur 5EU$ mehr im Monat angeboten hat, ich das Angebot angenommen habe und 1&1 dann zwei Tage später zurückgerudert ist: In meinem Anschlussgebiet seien 16Mbit gar nicht zuverlässig möglich. Man bedaure blah blah blah ... Und kulanterweise haben sie mir dann die Bitrate am DSLAM auf 7.5Mbit hochgeschraubt, ohne an den Vertragsbedingungen etwas zu ändern.
Der Datendurchsatz ist auch gut und passt: Etwa 730..750kB/sec, wenn der Server am anderen Ende der Verbindung so schnell liefert. Was aber eher die Ausnahme ist - diese Geschwindigkeit erreiche ich zwar regelmäßig bei Systemupdates vom Repo-Server meiner Linux-Distro, aber sonst kaum irgendwo.
Die sehr unterschiedlichen Reaktionszeiten sind aber vermutlich kein Problem der Bandbreite, sondern eher ein Problem der Router auf der Strecke zwischen Client und Server. Ein traceroute auf fastix.org verrät mir übrigens, dass der Request über insgesamt 16 Hops geht (und zwar über die Ballungsräume Stuttgart, Frankfurt, Düsseldorf und Berlin), und pro Hop im Mittel zwischen 50 und 70ms Delay anfallen, vereinzelt auch mal bis fast 100ms.
Ciao,
Martin
Ein traceroute auf fastix.org verrät mir übrigens, dass der Request über insgesamt 16 Hops geht (und zwar über die Ballungsräume Stuttgart, Frankfurt, Düsseldorf und Berlin), und pro Hop im Mittel zwischen 50 und 70ms Delay anfallen, vereinzelt auch mal bis fast 100ms.
Hier mal der Vergleich:
1 192.168.1.1 (192.168.1.1) 1.132ms 0.458ms 0.376ms [=78.49.230.153]
2 213.191.64.109 (213.191.64.109) 15.905ms 16.880ms 15.668ms
3 213.191.91.100 (213.191.91.100) 15.490ms 15.382ms 15.869ms
4 213.191.91.113 (213.191.91.113) 15.235ms 15.506ms 15.577ms
5 80.81.203.20 (80.81.203.20) 22.615ms 22.582ms 22.483ms
6 93.92.131.65 (93.92.131.65) 28.318ms 27.883ms 27.259ms
7 93.92.131.110 (93.92.131.110) 29.048ms 28.606ms 28.509ms
8 93.92.134.70 (93.92.134.70) 28.552ms 28.652ms 28.713ms
9 81.28.232.70 (81.28.232.70) 29.755ms 28.645ms 28.516ms
Nr. 1 ist so "langsam" weil noch eine Belkin-Box (Für schnelles WLAN mit den Lappies und Gigabit-Netz) als Switch davor hängt.
Befehl: ping -R -c 3 78.49.230.153
PING 78.49.230.153 78.49.230.153 56(124) bytes of data.
64 bytes from 78.49.230.153: icmp_seq=1 ttl=54 time=103 ms
RR: 81.28.232.70
93.92.134.70
93.92.131.110
93.92.131.65
193.178.185.69
213.191.64.109
78.49.230.153
78.49.230.153
213.191.90.77
64 bytes from 78.49.230.153: icmp_seq=2 ttl=54 time=34.8 ms (same route)
64 bytes from 78.49.230.153: icmp_seq=3 ttl=54 time=84.5 ms (same route)
--- 78.49.230.153 ping statistics ---
rtt min/avg/max/mdev = 34.850/74.132/103.002/28.782 ms
Jörg Reinholz
Hallo,
Ein traceroute auf fastix.org verrät mir übrigens, dass der Request über insgesamt 16 Hops geht (und zwar über die Ballungsräume Stuttgart, Frankfurt, Düsseldorf und Berlin), und pro Hop im Mittel zwischen 50 und 70ms Delay anfallen, vereinzelt auch mal bis fast 100ms.
Hier mal der Vergleich:
1 192.168.1.1 (192.168.1.1) 1.132ms 0.458ms 0.376ms [=78.49.230.153]
2 213.191.64.109 (213.191.64.109) 15.905ms 16.880ms 15.668ms
3 213.191.91.100 (213.191.91.100) 15.490ms 15.382ms 15.869ms
4 213.191.91.113 (213.191.91.113) 15.235ms 15.506ms 15.577ms
5 80.81.203.20 (80.81.203.20) 22.615ms 22.582ms 22.483ms
6 93.92.131.65 (93.92.131.65) 28.318ms 27.883ms 27.259ms
7 93.92.131.110 (93.92.131.110) 29.048ms 28.606ms 28.509ms
8 93.92.134.70 (93.92.134.70) 28.552ms 28.652ms 28.713ms
9 81.28.232.70 (81.28.232.70) 29.755ms 28.645ms 28.516ms
wow, wie geht das? Hast du das Internet für dich allein gemietet?
Nr. 1 ist so "langsam" weil noch eine Belkin-Box (Für schnelles WLAN mit den Lappies und Gigabit-Netz) als Switch davor hängt.
Langsam? Bei mir ist die erste Teilstrecke (also die zur Fritzbüx, verkabelt, 100Mbit) mit rund 5ms mit Abstand die schnellste.
Befehl: ping -R -c 3 78.49.230.153
Liefert bei mir zwischen 80 und 180ms (gerundet) auf fastix.org. Was ist das für eine IP, die du da als Beispiel verwendest? Wenn ich die nehme, liege ich zwischen 110 und 200ms.
Du hast eindeutig ein besseres Internet. ;-)
Ciao,
Martin
Nr. 1 ist so "langsam" weil noch eine Belkin-Box (Für schnelles WLAN mit den Lappies und Gigabit-Netz) als Switch davor hängt.
Langsam? Bei mir ist die erste Teilstrecke (also die zur Fritzbüx, verkabelt, 100Mbit) mit rund 5ms mit Abstand die schnellste.
Da sind aber nur Werte von ca. 1ms akzeptabel. Ich glaube nicht, dass Linux oder Windows da eine Rolle spielt.
Kabeltausch? Die Fritzdinger gehen eigentlich gut.
Was ist das für eine IP, die du da als Beispiel verwendest? Wenn ich die nehme, liege ich zwischen 110 und 200ms.
Das war vom Webserver nach Hause. Klar, dann ist zweimal DSL dazwischen, das bremst natürlich.
Rufe http://www.fastix.org/netztools/ auf, dann bekommst Du Deine IP automatisch eingefügt, nur in Ausnahmefällen (z.B. wenn der X-Forward-For-Header am Squid herauskonfiguriert wurde) die eines Proxys.
Jörg Reinholz
Hallo Jörg,
Nr. 1 ist so "langsam" weil noch eine Belkin-Box (Für schnelles WLAN mit den Lappies und Gigabit-Netz) als Switch davor hängt.
Langsam? Bei mir ist die erste Teilstrecke (also die zur Fritzbüx, verkabelt, 100Mbit) mit rund 5ms mit Abstand die schnellste.
Da sind aber nur Werte von ca. 1ms akzeptabel. Ich glaube nicht, dass Linux oder Windows da eine Rolle spielt.
hmm, auch da schwanken die Werte wie Lottozahlen im Bereich von unter 1ms bis rund 8ms. Und zwar von verschiedenen Linux-Büchsen aus. Windows liefert da keine brauchbare Aussage, hier lautet die Angabe nur <10ms. Zwischen PC und der Fritzbüx ist nur noch ein Gigabit-Switch.
Kabeltausch? Die Fritzdinger gehen eigentlich gut.
Die Kabel sollten in Ordnung sein, wenn ich da ansonsten gute 50..60MB/s übertragen kann - natürlich nicht über die Fritzbüx ins Internet, aber über den Switch zu einem anderen lokalen PC. Das Kabel vom Switch zur Fritzbüx ist das gleiche, nur kürzer; das von der Box zur DSL-Anschlussdose ist das von AVM mitgelieferte für den reinen DSL-Anschluss (also ohne Y-Verzweigung, Splitter und POTS/ISDN).
Wie gesagt: Die Übertragungsrate ist gemessen am theoretischen Maximalwert sehr gut. Es geht nur um die Reaktionszeiten trotz physisch einwandfreier Verbindung.
Ich vermute, dass ich einfach an einem Einwahlknoten mit suboptimaler Verbindung zur restlichen Welt hänge.
Ciao,
Martin
Hallo Martin!
Ich vermute, dass ich einfach an einem Einwahlknoten mit suboptimaler Verbindung zur restlichen Welt hänge.
Ja, da scheint der Fall zu sein. Pings auf deutsche Server sollten ohne fastpath 50ms brauchen. Kannst ja versuchen osn.de anzupingen, die stehen in Nürnberg. Das ist für Dich rund 500 km kürzer als bis zu Variomedia in Berlin. (Ja, das macht was aus. In Kupfer beträgt die "Lichtgeschwindigkeit" nur 60% und in Glasfaser auch nur 70-80% der "Lichtgeschwindigkeit" im Vakuum.)
Aber trotzdem machen mir die 5ms bis zu Deinem Router Bauchschmerzen. Ich habe von meinen ältesten Läppi aus mit WLAN(!) zum Access-Point ca. 2..3ms zum Router 3..4ms, per Kabel wie gesagt 1ms. Irgendwas stimmt da nicht.
Hallo,
Ich vermute, dass ich einfach an einem Einwahlknoten mit suboptimaler Verbindung zur restlichen Welt hänge.
Ja, da scheint der Fall zu sein.
und ich habe durch weitere teils wahllose Versuche herausgefunden, dass die wirklich großen Delays (50ms und mehr) vor allem an den Knoten auftreten, die zu arcor-ip.net (jetzt 1&1) gehören - egal welche Hosts ich letztendlich anpinge oder trace. Sobald ich mal aus dem alten Arcor-Netz raus bin, werden die Antwortzeiten deutlich kürzer (25..30ms pro Hop vs. 50..100ms innerhalb des Arcor-Netzes).
Pings auf deutsche Server sollten ohne fastpath 50ms brauchen.
Ich habe keine Ahnung, was "fastpath" sein mag.
Kannst ja versuchen osn.de anzupingen, die stehen in Nürnberg.
Da habe ich nahezu konstant etwa 32..35ms normale Ping-Antwortzeit (also ping ohne -R). Mit dem Switch -R habe ich bei diesem Host "100% packet loss". Ohne den Switch -R habe ich allerdings auch auf fastix.org Ping-Antwortzeiten von 40..45ms. Kann es sein, dass ping -R bzw. traceroute versuchen, für jede unterwegs ermittelte IP-Adresse per Reverse-DNS-Lookup den Hostnamen zu ermitteln, und dass dadurch die langen Delays entstehen? Ich vermute das fast, denn traceroute zeigt mir ja auch für die Zwischenstationen teilweise Hostnamen an. Die müssen ja irgendwo herkommen.
Aber trotzdem machen mir die 5ms bis zu Deinem Router Bauchschmerzen. Ich habe von meinen ältesten Läppi aus mit WLAN(!) zum Access-Point ca. 2..3ms zum Router 3..4ms, per Kabel wie gesagt 1ms. Irgendwas stimmt da nicht.
Arrgh ... wie ich diese blöde Wortschöpfung "Läppi" hasse!
Ein einfaches ping zum Router liefert mir auch Antwortzeiten um 1ms, meistens knapp drunter. Nur als Hop innerhalb einer traceroute-Kette schwankt die Zeit für diesen Hop sehr stark. Mir ist nicht wirklich klar, was ich davon halten soll.
So long,
Martin
Hi,
Da habe ich nahezu konstant etwa 32..35ms normale Ping-Antwortzeit (also ping ohne -R). Mit dem Switch -R habe ich bei diesem Host "100% packet loss". Ohne den Switch -R habe ich allerdings auch auf fastix.org Ping-Antwortzeiten von 40..45ms. Kann es sein, dass ping -R bzw. traceroute versuchen, für jede unterwegs ermittelte IP-Adresse per Reverse-DNS-Lookup den Hostnamen zu ermitteln, und dass dadurch die langen Delays entstehen? Ich vermute das fast, denn traceroute zeigt mir ja auch für die Zwischenstationen teilweise Hostnamen an. Die müssen ja irgendwo herkommen.
nochmal etwas übersichtlicher:
ping <hostname> oder ping <ip-adresse>
Liefert mir bei den meisten Hosts Antwortzeiten deutlich unter 100ms, meist sogar unter 50ms.
ping -R <hostname> oder ping -R <ip-adresse> oder traceroute <hostname>
Gibt mir zwar detaillierte Angaben über den Weg des Pakets, aber rund 30..100ms pro Hop. DNS-Lookup? Und ping -R versagt bei manchen Zielen komplett, egal ob ich Hostnamen oder IP-Adresse angebe. Das verstehe ich überhaupt nicht.
Aber trotzdem machen mir die 5ms bis zu Deinem Router Bauchschmerzen.
Auch hier wäre ein Reverse-DNS-Lookup, wenn er denn stattfindet, eine plausible Erklärung für die Verzögerung. Denn mein DNS braucht ja auch eine endliche Zeit, bis er den festgelegten Hostnamen für 192.168.123.254 hergibt. Und 5..10ms für so einen Lookup wäre ja gar nicht so schlecht.
Ciao,
Martin
Kann es sein, dass ping -R bzw. traceroute versuchen, für jede unterwegs ermittelte IP-Adresse per Reverse-DNS-Lookup den Hostnamen zu ermitteln, und dass dadurch die langen Delays entstehen?
Womöglich. traceroute macht bei mir@home keine DNS-Lookups. Ping -R dagegen schon. Und siehe da: Ping -R braucht (allerdings nur rund knapp 0.2ms) länger - denn ich habe einen lokalen DNS auf dem Haupt-Rechner am laufen.
Hi,
Kann es sein, dass ping -R bzw. traceroute versuchen, für jede unterwegs ermittelte IP-Adresse per Reverse-DNS-Lookup den Hostnamen zu ermitteln, und dass dadurch die langen Delays entstehen?
Womöglich. traceroute macht bei mir@home keine DNS-Lookups. Ping -R dagegen schon. Und siehe da: Ping -R braucht (allerdings nur rund knapp 0.2ms) länger - denn ich habe einen lokalen DNS auf dem Haupt-Rechner am laufen.
ich habe meinen zwar auch "lokal", aber eben nur lokal im LAN, auf einer anderen Maschine. Und der löst natürlich auch nur Hostnamen bzw. IPs aus dem lokalen LAN selbst auf, alles andere gibt er "nach draußen" weiter.
Also war das Ganze hier zwar sehr interessant; ich habe aber wohl Phantome gesucht, die durch den Einsatz von Diagnosetools überhaupt erst auftauchen, nicht aber im normalen Alltag.
Bleibt festzuhalten, was ich eigentlich schon vorher wusste: Ping-Antwortzeiten liegen in einem durchaus akzeptablen Rahmen, aber bis ich von einem Server draußen in der weiten Welt eine HTTP-Antwort bekomme, dauert es trotzdem gelegentlich über eine Sekunde. Und warum das so ist, liegt immer noch völlig im Dunkeln.
Ciao,
Martin
Hallo,
Das braucht sich nur um ein "Geringes" vervielfachen, dann bricht der Browser ab. Das würde auch den Effekt erklären, dass das der Fehler nicht ohne weiteres verifizierbar ist. Sucht das PHP-Skript also auch nach Performancebremsen ab.microtime(true) ist dafür gut geeignet.
Das ist ja in etwa wie "echo" fuer's "debuggen".. brr.
http://www.xdebug.org/docs/profiler
MfG
Christopher
Das Feld für den Namen ist weg. FF20, Win7
Bestätigt: FF20, Win7, Ubuntu 12.10
Bestätigt: Chromium, Ubuntu 12.10
Bestätigt: Opera 12.15, Ubuntu 12.10
Das Problem betrifft ALLE PFLICHTFELDER. Nach Fokusverlust ohne vorherige Eingabe werden die auf Länge 0 gesetzt.
Könnte mit diesem Problem zusammenhängen.
Hallo!
Ich habe ein Problem und weiß leider nicht weiter. :(
Ja. Man muss es erst mal einkreisen:
GET /themes/m1shoptheme/js/ajax.js?ver=3.5.1 HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: */*
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Referer: https://shop.maennchen1.de/warenkorb/
Connection: keep-alive
...
wird als Aborted gemeldet.
Das passiert beim Aufruf des Warenkorbs gleich zweimal:
2. Anfrage:
GET /themes/m1shoptheme/js/ajax.js?ver=3.5.1 HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: */*
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Referer: https://shop.maennchen1.de/warenkorb/
Connection: keep-alive
Installiert doch mal eines der gängigen Tools, mit denen Ihr den HTTP-Verkehr überwachen könnt. Ich habe Firebug genommen.
Zu Chrome: Ich glaube, der hat die ajax.js sozusagen eingebaut und kennt also die darin enthalten Funktionen sozusagen selbst. Andere Browser scheitern dann natürlich bei deren Aufruf.
Hallo!
Installiert doch mal eines der gängigen Tools, mit denen Ihr den HTTP-Verkehr überwachen könnt. Ich habe Firebug genommen.
Danke für den obigen Vorschlag. Auch wenn die Anfrage des Browsers evtl. fehlerhaft ist, wieso lässt sich dann die Seite von 95% aller Kunden aufrufen und vom Rest nicht?
