FoxViper hat geschrieben:
hi,
das sehe ich nicht so,
die meiste zeit warte ich auf "vlan.302.er1.fe13....." IP "...26"
da ist die Antwort von "IP...17.2" immer noch im Rahmen.
es ist entscheidend an welcher stelle der Route mein Paket ein long Request-Reply hat, es ist nicht immer das Ziel, deshalb muss man den Aufbau der Route semantisch betrachten.
Punkt1: es hat 0 Aussagekraft wenn die Antwortzeiten auf einem der Router länger sind als am Ende, da auch die nachfolgenden Pakete diesen Router passieren und da offensichtlich schnell genug weitergeleitet werden um am Ende wieder eine niedrigere Antwortzeit zu erzeugen. Warum das dann bei einem Router mal länger dauert kann an allem möglichen liegen. z.B. daran, dass Router konstruiert werden Pakete möglichst schnell von einem Interface zu einem anderen zu schieben. Beim Beantworten einer ICMP Nachricht muss allerdings die CPU ran, die vielleicht grad besseres zu tun hat und sowas ganz hinten anstehen muss.
Punkt2: ICMP kann und hat sicher andere Prioritäten als ein TCP Paket auf Port 80. Du kannst diese Zeiten also gar nich als Referenz hernehmen.
Ich mein klar, wenn du über alle beteiligten Komponenten verfügen kannst und ein Flaschenhals suchen musst, dann mag sowas ganz hilfreich sein. Es steht dir auch frei ebenfalls solche Grafiken anzufertigen um Netzengpässe zu Spitzenzeiten nachzuweisen. Nichtsdestotrotz haben wir bereits auf Seite 1 Netzwerkprobleme weitestgehend ausgeschlossen.
Das kann prinzipiell auch jeder für sich selbst tun. Wenns mal wieder länger dauert unten in die Statusleiste schauen. Steht da Verbinden mit... dann hat der Webserver die Verbindungsanfrage noch nicht mal beantwortet, was das leichteste aller Aufgaben sein sollte. Also hakts wahrscheinlich irgendwo auf dem Weg dorthin (oder beim Webserver selbst). Steht da Warten auf... dann steht die Verbindung schon und der Webbrowser wartet auf die Antwort des Servers. Es kann dann zwar auch Netzwerkprobleme geben, aber wenn das Verbinden mit so schnell verschwindet, dass man es kaum sieht und Warten auf ewig stehen bleibt, dann darf man schon mal auf den Webserver oder irgendein nachgelagertes System schliessen. Hat am Ende aber genausoviel Beweiskraft wie ein traceroute
FoxViper hat geschrieben:
und siehe
http://oss.oetiker.ch/ <- darauf basiert "Munin", steht da ja auch
http://munin.projects.linpro.no/, also es ist ein MRTG
komische Logik. Nur weil RRDTool und MRTG vom gleichen Menschen stammen ist alles was RRDTool nutzt gleichzeitig MRTG? MRTG nutzt RRDTool nichtmal (ausser man verwendet
mrtg-rrd ). Und wenn wir gerade dabei sind, MRTG 3, sollte es irgendwann rauskommen, wird Munin recht ähnlich sein und ebenfalls auf RRDTool setzen. Aber selbst dann ist Munin nicht MRTG, genauso wenig wie phpBB ein vBulletin ist nur weil beide ihre Daten in einer MySQL Datenbank ablegen können (dazu noch ein paar Funktionen um schöne Grafiken zu malen und fertig ist RRDTool)
FoxViper hat geschrieben:
letztendlich geht es aber um die "Werbung" und da stimme ich voll zu, es ist lästig
in der Tat.
Anmelden
Registrieren
FAQ
Suche
Kalender
Karte
.
.
---- TELEKOM
Und wenn die liebe Telekom mal endlich den RAM freischaltet dürfte ich irgendwo bei 5-6000 rumflitzen, da die Dämpfungswerte eigentlich recht gut sind.
