- √ - Shop auf Wiregate.de fast nicht erreichbar, wer hat noch Probleme? Belohnung!

[hannes loehr]

Noch ein Hinweis: Teils kommen die Inhalte referenziert ohne Domäne, teils mit vollem Pfad von http://www.wiregate.de/images/home_page/

Wenn man da nicht gleichzeitig auf dem Server irgendeine Debuginfo laufen hat, was Apache, CMS oder sonstiges dahinterliegende System macht, wenn der Browser wartet, ist die Fehleranalyse etwas beschwerlich.

[hannes loehr]

Ich habe gerade einmal meinen Avast Virenscanner deaktiviert. Ohne Schutz kommt die Seite gerade ganz normal.

An alle mit Verbindungsproblemen: Benutzt Ihr auch einen Avast?

Gruß
Hannes

[xachsewag]

Es ist hier deutlich zu erkennen, wie manche Files ewig zum laden brauchen andere ruck zuck übermittelt werden.

Avast habe ich hier nicht im Einsatz.

[hannes loehr]

Avast habe ich hier nicht im Einsatz.

Hast Du ansonsten einen Virenscanner am Laufen? Auf einem anderen Rechner mit Sophos Antivir lädt die Seite auch extrem zäh.

Auf einem Linux Mint 14 in einer VirtualBox kommt die Seite in 1,2 Sekunden.

[GLT]

Kein Avast an diesem System

[xachsewag]

Habe es auch auf einem System versucht das gar keinen Scanner hat, gleiches Problem. An meinem Handy habe ich ja auch die Probleme.

Evtl. müsste man sich den Traffic mal via Wireshark ansehen.

[StefanW]

Wir haben nun den Aufbau der Startseite verbessert.

Der Validator ist nun "green" und wir haben auch die Einbindung von CSS verändert.

Von uns aus sieht es immer noch gut aus. Wie funktioniert die Seite für Euch?


lg

Stefan

[xachsewag]

Bei mir ist es nach wie vor langsam/nicht darstellbar. Getestet auf drei Systemen.
Eine kurze Zeit ging es recht schnell, jetzt läd die Seite wieder ewig.

[XueSheng]

Mit leerem Browsercache dauert es ewig bis die Seite geladen ist. Nach dem ersten Laden geht es dann.

[MarcusF]

Mac OS X 10.8 mit Safari 6.1 lädt wiregate.de über Telekom VDSL25 sehr langsam. In der Debug-Konsole bekomme ich folgende Meldungen:

[Error] TypeError: 'null' is not an object (evaluating 'document.getElementById('tsensor_product').style')
	bild_wechsel_2 (index.php, line 9487)
[Error] Failed to load resource: Zeitüberschreitung bei der Anforderung. (boxes.css, line 0)
[Error] Failed to load resource: Zeitüberschreitung bei der Anforderung. (reset.css, line 0)
[Error] Failed to load resource: Zeitüberschreitung bei der Anforderung. (btn_mini_search.gif, line 0)
[Error] Failed to load resource: Zeitüberschreitung bei der Anforderung. (2013-09-17_Grafik_Webshop_Einfuehrung_Exsys_Produkte.png, line 0)
[Error] Failed to load resource: Zeitüberschreitung bei der Anforderung. (Reduziert_Versand_Fotolia_31764323_XS_346x346.jpg, line 0)

Nach einem Reload dauert es ebenfalls eine ziemliche Zeit, am längsten kaut er an index.php aber keine weiteren Fehlermeldungen.

Hoffe es hilft,
Marcus

[cava]

Hallo,

ich habe es jetzt auch mal probiert. Einmal mit Mac OS X 10.9, XP mit IE 8 und Win 7 mit IE 10. Es hat beim ersten Zugriff immer ewig gedauert.

Auf den Windows hab ich jeweils httpwatch mitlaufen lassen. Das Ergebnis war aber immer ein anderes. Mal haben die png von http://www.wiregate.de/images ewig zum laden gebraucht, mal war es ein Teil der css-Dateien.

Unter XP wird ein Zugriff auf http://:/ angezeigt, den ich unter Win 7 nicht sehe.

Teilweise sind auch Bilder nicht angekommen. Ich persönlich würde Netzwerkprobleme ausschließen und den Fehler beim Server suchen. Das macht es für den Aussenstehenden dann allerdings schwierig, den Fehler zu finden.

Gruß
Werner

[Bodo]

Hoi

Aktuell kein Problem bei mir.

[Astrafahrer]

Aktuell kein Problem bei mir.

Dem kann ich mich anschließen; Seite und Inhalte laden flüssig (DSL 5000 kbit/s; Chrome unter Mac OS).

[netzkind]

Davor gibt es einen Haufen Firewalls usw. [..]

Das alleine klingt schon nach einem Problem.

Meine Beobachtung: wenn man bei euch ein bisschen Last verursacht, knicken der Auslieferung die Beine weg.
Ich hab eben mit ApacheBench 100x (nacheinander, nicht parallel!) die print.css abgefragt, und währenddessen habe ich im Firebug schön beobachten könnten, dass die Wartezeit für einzelne Dateien (vor allem die drei großen Bilder der Startseite) auf fast 3 Sekunden gesprungen ist.

Es ist definitiv kein Browser-Problem, also keine Frage der HTML/JS/CSS-Syntax, da ApacheBench sich dafür nicht interessiert, und dennoch böse Auslieferungszeiten vermeldet:

mbp:~ julian$ ab -n 100 http://shop.wiregate.de/skin/frontend/elabnet/default/css/print.css
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking shop.wiregate.de (be patient).....done


Server Software:        Apache/2.2.16
Server Hostname:        shop.wiregate.de
Server Port:            80

Document Path:          /skin/frontend/elabnet/default/css/print.css
Document Length:        3841 bytes

Concurrency Level:      1
Time taken for tests:   170.120 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      409500 bytes
HTML transferred:       384100 bytes
Requests per second:    0.59 [#/sec] (mean)
Time per request:       1701.199 [ms] (mean)
Time per request:       1701.199 [ms] (mean, across all concurrent requests)
Transfer rate:          2.35 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      754 1661 1522.0   1670   15457
Processing:    38   40   1.8     39      50
Waiting:       33   35   1.8     34      45
Total:        792 1701 1521.9   1710   15496

Percentage of the requests served within a certain time (ms)
  50%   1710
  66%   1715
  75%   1782
  80%   2015
  90%   2220
  95%   2720
  98%   4032
  99%  15496
 100%  15496 (longest request)

Ihr habt also definitiv "in der Leitung" oder "auf der Maschine" ein Problem.

Ich schlage vor, ihr macht selbst einen Benchmark mit ab, und schaut parallel die Systemlast an, die Last auf den vorgeschalteten Firewalls, und die Logs der Firewalls.
Ein Traceroute meint auch, dass der letzte Hop einen Teil der ICMP-Pakete verschluckt, das sieht für mich dann nach einem Netzwerk-/Firewall-Problem aus:

traceroute to shop.wiregate.de (81.16.179.100), 64 hops max, 52 byte packets
 1  fritz.box (10.7.7.1)  2.715 ms  1.495 ms  1.380 ms
 2  lo0.hra-r-a-01.net-htp.de (81.14.248.172)  17.245 ms  16.660 ms  16.511 ms
 3  ae-2-0.hra-r-p-00.net-htp.de (81.14.249.18)  16.005 ms  15.633 ms  15.775 ms
 4  xe-1-2-0-0.hra-r-p-01.net-htp.de (81.14.249.31)  16.362 ms  15.535 ms  16.057 ms
 5  bbrt.hb-1-ge-4-0-0.ewe-ip-backbone.de (212.6.114.221)  65.145 ms  18.232 ms  17.471 ms
 6  bbrt.ffm-0-10ge-6-0-0.ewe-ip-backbone.de (212.6.114.14)  29.462 ms  28.955 ms  28.789 ms
 7  xe0-0-2.e3.mk.de (80.81.192.140)  29.239 ms  29.466 ms  29.152 ms
 8  vl4.ds3a.mk.de (85.220.183.22)  29.298 ms  29.734 ms  29.315 ms
 9  82.100.208.186 (82.100.208.186)  29.273 ms  30.080 ms  29.458 ms
10  * pop-ffm1-v04296-fa0-0-11.elabnet.de (81.16.176.6)  30.472 ms !X *
11  pop-ffm1-v04296-fa0-0-11.elabnet.de (81.16.176.6)  31.395 ms !X *  31.575 ms !X

(Nachtrag: während traceroute lief kein ab, meine Leitung war unbelastet)

Anbindung hier ist über einen lokalen Provider (htp) mit 8000/800 DSL.

Viel Spaß bei der Suche,
Julian

[cava]

Ich hab eben mit ApacheBench 100x (nacheinander, nicht parallel!) die print.css abgefragt, und währenddessen habe ich im Firebug schön beobachten könnten, dass die Wartezeit für einzelne Dateien (vor allem die drei großen Bilder der Startseite) auf fast 3 Sekunden gesprungen ist.

Hier ist mein Ergebnis von einem Hetzner vServer aus (1 paralleler Zugriff):

root@intrepid:/etc/bind# ab -n 100 http://shop.wiregate.de/skin/frontend/elabnet/default/css/print.css
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking shop.wiregate.de (be patient)...apr_socket_recv: Connection timed out (110)
Total of 11 requests completed

Und hier das Ergebnis von meinem MacPro über KDG (diesmal mit 20 parallelen Zugriffen):

enterprise:~ werner$ ab -n 100 -c 20 http://shop.wiregate.de/skin/frontend/elabnet/default/css/print.css
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking shop.wiregate.de (be patient)...apr_socket_recv: Operation timed out (60)
Total of 87 requests completed