6
Interpretation von Zeitüberschreitung der Anforderung
Hallo,
ich arbeite in einer Firma, die eine Software für Kliniken und Krankenhäuser entwickelt und Vertreibt. Hierbei liegen die Programmdateien meist zusammen mit einer SQL-Datenbank auf einem Server und die Clients starten das Programm direkt vom Server. der Zugriff erfolgt entweder über UNC-Pfade oder Netzlaufwerke.
Nun zu meinem Problem:
Bei manchen Kunden stürzt diese Anwendung unreproduzierbar ab, bzw bleibt hängen. Da dieses Verhalten weder auf bestimmte Abläufe im Workflow zurückzuführen ist, noch bei einer Lokalen Installation bemerkbar ist, fiel unser Verdacht auf das Netzwerk.
Um dieses zu überprüfen, hab ich unter anderen ein Script geschrieben, dass den Server vom Client aus jede Sekunde einmal pingt und das Ergebniss mitlogt. Als Ergebniss ergab sich nun, dass der Server an einem Tag von ca. 20.000 Mal 19 mal nicht geantwortet hat, also eine Zeitüberschreitung der Anforderung aufgetreten ist, an einem anderen Tag 209 mal.
Nun meine Frage: Wie ist eine Zeitüberschreitung der Anforderung zu interpretieren?
Handelt es sich hierbei um eine wirkliche "phsysikalische" Trennung zwischen Server und Client? Also kann es sein das der Client in dieser Zeit keine Verbindung zum Server mehr hat. Oder ist ein Ping nicht wirklich aussagekräftig, da es sich ja nur um eine Echoanfrage handelt..
Hat evtl jemand ähnliche Erfahrungen gemacht wie Ich und hat evtl noch ein paar tips wie ein Netzwerk korrekt zu überprüfen ist? Also es geht jetzt nicht direkt um Geschwindigkeit, sondern um die reine Verfügbarkeit des Servers und der Freigaben.
Über zahlreiche Antworten fürde ich mich freuen
Grüße
b2kButt
ich arbeite in einer Firma, die eine Software für Kliniken und Krankenhäuser entwickelt und Vertreibt. Hierbei liegen die Programmdateien meist zusammen mit einer SQL-Datenbank auf einem Server und die Clients starten das Programm direkt vom Server. der Zugriff erfolgt entweder über UNC-Pfade oder Netzlaufwerke.
Nun zu meinem Problem:
Bei manchen Kunden stürzt diese Anwendung unreproduzierbar ab, bzw bleibt hängen. Da dieses Verhalten weder auf bestimmte Abläufe im Workflow zurückzuführen ist, noch bei einer Lokalen Installation bemerkbar ist, fiel unser Verdacht auf das Netzwerk.
Um dieses zu überprüfen, hab ich unter anderen ein Script geschrieben, dass den Server vom Client aus jede Sekunde einmal pingt und das Ergebniss mitlogt. Als Ergebniss ergab sich nun, dass der Server an einem Tag von ca. 20.000 Mal 19 mal nicht geantwortet hat, also eine Zeitüberschreitung der Anforderung aufgetreten ist, an einem anderen Tag 209 mal.
Nun meine Frage: Wie ist eine Zeitüberschreitung der Anforderung zu interpretieren?
Handelt es sich hierbei um eine wirkliche "phsysikalische" Trennung zwischen Server und Client? Also kann es sein das der Client in dieser Zeit keine Verbindung zum Server mehr hat. Oder ist ein Ping nicht wirklich aussagekräftig, da es sich ja nur um eine Echoanfrage handelt..
Hat evtl jemand ähnliche Erfahrungen gemacht wie Ich und hat evtl noch ein paar tips wie ein Netzwerk korrekt zu überprüfen ist? Also es geht jetzt nicht direkt um Geschwindigkeit, sondern um die reine Verfügbarkeit des Servers und der Freigaben.
Über zahlreiche Antworten fürde ich mich freuen
Grüße
b2kButt
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 160325
Url: https://administrator.de/forum/interpretation-von-zeitueberschreitung-der-anforderung-160325.html
Ausgedruckt am: 23.12.2024 um 17:12 Uhr
6 Kommentare
Neuester Kommentar
moin,
... tcp/ip ein Protokoll ist, wo Verluste einkalkuliert sind.
Oder ist ein Ping nicht wirklich aussagekräftig, da.....
... tcp/ip ein Protokoll ist, wo Verluste einkalkuliert sind.
Da dieses Verhalten weder auf bestimmte Abläufe im Workflow zurückzuführen sind noch bei einer Lokalen Installation bemerkbar.
- das mit den Servergespeicherten Programmen hat man früher mal gemacht, als es nur Dumme Clients und kleine geschlossene Netze gab,
- Heute macht man das nicht mehr. (Außer es handelt sich um einen kompletten Terminalserver mit DB hinten dran)
- Um dieses zu überprüfen, hab ich unter anderen ein Script geschrieben, dass den Server vom Client aus jede Sekunde einmal ....
- warum schaut Ihr nicht auf die Protokolle der Switche?
Über zahlreiche Antworten fürde ich mich freuen
Pauchal global zu Kristallkugellastig und zuviel könnte, statt das und nur das ist es,,,,Gruß
Hallo,
das Datenpakete (also z.B. pings, aber auch Nutzdaten) in Netzwerken mal verloren gehen ist durchaus normal. Daher setzt man Protkolle ein, die dann für eine Übertragungswiederholung sorgen (TCP).
Weiterhin lassen Antwortzeiten von Pings keine zuverlässigen (positiven) Rückschlüsse auf Übertragung von Nutzdaten zu. Will heißen: Ping geht auch auf der Wasserleitung. Und nur weil ein Ping im Netzwerk geht, heißt das noch lange nicht, dass auch z.B. Zugriffe auf Dateifreigaben hinreichend funktionieren.
Aber wenn ihr die Software entwickelt, sollte es ja hoffentlich für euch kein Problem sein, den Netzwerkstack zu überwachen und somit Netzwerkprobleme zumindest mal identifizieren zu können.
Dem "Heute macht man das nicht mehr" von Timo kann ich mich vollständig anschließen.
Gruß
Filipp
das Datenpakete (also z.B. pings, aber auch Nutzdaten) in Netzwerken mal verloren gehen ist durchaus normal. Daher setzt man Protkolle ein, die dann für eine Übertragungswiederholung sorgen (TCP).
Weiterhin lassen Antwortzeiten von Pings keine zuverlässigen (positiven) Rückschlüsse auf Übertragung von Nutzdaten zu. Will heißen: Ping geht auch auf der Wasserleitung. Und nur weil ein Ping im Netzwerk geht, heißt das noch lange nicht, dass auch z.B. Zugriffe auf Dateifreigaben hinreichend funktionieren.
Aber wenn ihr die Software entwickelt, sollte es ja hoffentlich für euch kein Problem sein, den Netzwerkstack zu überwachen und somit Netzwerkprobleme zumindest mal identifizieren zu können.
Dem "Heute macht man das nicht mehr" von Timo kann ich mich vollständig anschließen.
Gruß
Filipp
Hallo,
ich habe viel mit Software bei Zahnärzten zu tun sowie allgemein mit Softwareentwicklung im Windows Umfeld.
Zum einen verwenden die meisten Programme aus diesem Segment eine Dateibasierte-P2P-Datenbank. Auch das Programm kommt vom Netzwerklaufwerk.
Lokal gibt es nur eine INI-Date mit ID und ein Icon.
Der Trend geht erfreulicherweise aber zum lokalen Client mit SQL-Server.
Alle diese Programm sind extrem empfindlich was das Netzwerk angeht.
Das Programm Da....ft z.B.: Man befindet sich in der neutrallen Patientenauswahlmaske und macht gar nichts. Die Software macht augenscheinlich auch nichts.
Nun zieht man das Netzwerkkabel raus, wartet kurz und steckt es wieder ein. Man wartet wieder und prüft ob das Netzwerklaufwerk wieder funktioniert und klickt dann irgendwas in der Software an.
Es erscheint sofort ein "Dialog" mit der Meldung, dass das Netzwerk nicht zu verfügung steht und es weiter probiert wird. Aber das Programm kommt nie zurück.
Dieses Verhalten ist "normal" für EXE-Programme die von einem Netzwerklaufwerk gestartet wurden. Aufgrund von Cache-Verhalten will Windows immer mal wieder was aus der Datei lesen. Wenn das nicht geht, liefern die verschiedensten Routinen unmögliche Fehler zurück. Das alles abzufangen ist sehr aufwendig.
Man verwendet dann meist ein Catch-All um überhaupt auf die Spur zu kommen. Und um ein Protokoll zu führen um den Nachweis der eigenen "Unschuld" zu führen.
Viel einfacher ist es wenn die Software lokal läuft, da müssen nur die Datenabrufe entsprechend abgesichert werden.
Der Aufwand ist auch gar nicht so groß.
Aber alle Programme umzustellen steht wohl nicht zur Diskussion. Wobei man anders das Problem nur eingrenzen kann aber nie loswird.
Viel Erfolg
Stefan
ich habe viel mit Software bei Zahnärzten zu tun sowie allgemein mit Softwareentwicklung im Windows Umfeld.
Zum einen verwenden die meisten Programme aus diesem Segment eine Dateibasierte-P2P-Datenbank. Auch das Programm kommt vom Netzwerklaufwerk.
Lokal gibt es nur eine INI-Date mit ID und ein Icon.
Der Trend geht erfreulicherweise aber zum lokalen Client mit SQL-Server.
Alle diese Programm sind extrem empfindlich was das Netzwerk angeht.
Das Programm Da....ft z.B.: Man befindet sich in der neutrallen Patientenauswahlmaske und macht gar nichts. Die Software macht augenscheinlich auch nichts.
Nun zieht man das Netzwerkkabel raus, wartet kurz und steckt es wieder ein. Man wartet wieder und prüft ob das Netzwerklaufwerk wieder funktioniert und klickt dann irgendwas in der Software an.
Es erscheint sofort ein "Dialog" mit der Meldung, dass das Netzwerk nicht zu verfügung steht und es weiter probiert wird. Aber das Programm kommt nie zurück.
Dieses Verhalten ist "normal" für EXE-Programme die von einem Netzwerklaufwerk gestartet wurden. Aufgrund von Cache-Verhalten will Windows immer mal wieder was aus der Datei lesen. Wenn das nicht geht, liefern die verschiedensten Routinen unmögliche Fehler zurück. Das alles abzufangen ist sehr aufwendig.
Man verwendet dann meist ein Catch-All um überhaupt auf die Spur zu kommen. Und um ein Protokoll zu führen um den Nachweis der eigenen "Unschuld" zu führen.
Viel einfacher ist es wenn die Software lokal läuft, da müssen nur die Datenabrufe entsprechend abgesichert werden.
Der Aufwand ist auch gar nicht so groß.
Aber alle Programme umzustellen steht wohl nicht zur Diskussion. Wobei man anders das Problem nur eingrenzen kann aber nie loswird.
Viel Erfolg
Stefan
Hallo,
erstmal Danke für die ganzen Antworten. Jetzt weis ich schon einmal dass einzelne Zeitüberschreitungen ingorierbar sind.
Wie wäre es zu interpetieren wenn die Ausfälle mehrfach hintereinder auftreten? Also fünf mal in folge oder so.
@timobeil: Die Herschaft über die Infrastruktur obliegt der EDV der jeweiligen Kliniken. Und nachdem wir zuerst einmal in der "Bringschuld" sind, was eine instabile Anwendung betrifft, muss ich der EDV was vorlegen mit dem ich das Begründen kann, dass ich die Protokolle der switche einsehen will.
@StefanKittel: Was verstehst du unter einem Catch-All? Ich kenne das nur von Email, bzw Domainweiterleitungen.
Welchen Weg würdet ihr den gehen um ein Netzwerk zu überprüfen? Mit spezieller Software? Oder gibt es auch "Simple" Methoden mit denen sich überprüfen lässt ob Netzwerktechnisch etwas im argen liegt oder alles in Ordnung ist?
gruß
b2kbutt
erstmal Danke für die ganzen Antworten. Jetzt weis ich schon einmal dass einzelne Zeitüberschreitungen ingorierbar sind.
Wie wäre es zu interpetieren wenn die Ausfälle mehrfach hintereinder auftreten? Also fünf mal in folge oder so.
@timobeil: Die Herschaft über die Infrastruktur obliegt der EDV der jeweiligen Kliniken. Und nachdem wir zuerst einmal in der "Bringschuld" sind, was eine instabile Anwendung betrifft, muss ich der EDV was vorlegen mit dem ich das Begründen kann, dass ich die Protokolle der switche einsehen will.
@StefanKittel: Was verstehst du unter einem Catch-All? Ich kenne das nur von Email, bzw Domainweiterleitungen.
Welchen Weg würdet ihr den gehen um ein Netzwerk zu überprüfen? Mit spezieller Software? Oder gibt es auch "Simple" Methoden mit denen sich überprüfen lässt ob Netzwerktechnisch etwas im argen liegt oder alles in Ordnung ist?
gruß
b2kbutt
Zitat von @b2kbutt:
@StefanKittel: Was verstehst du unter einem Catch-All? Ich kenne das nur von Email, bzw Domainweiterleitungen.
Beim programmieren gibt es try und catch. Da wird ein Block ausgeführt und im Fehlerfall spring er zu einer Routinen.@StefanKittel: Was verstehst du unter einem Catch-All? Ich kenne das nur von Email, bzw Domainweiterleitungen.
Man kann damit sehr einfach die Funktion von Routinen überprüfen.
Ergebniss für Dich wäre: Fehler 0x05 im Block schnübel01.
Welchen Weg würdet ihr den gehen um ein Netzwerk zu überprüfen? Mit spezieller Software? Oder gibt es auch "Simple" Methoden mit denen sich überprüfen lässt ob Netzwerktechnisch etwas im argen liegt oder alles in Ordnung ist?
Das ist immer sehr aufwendig. Erstmal das Netzwerk messen (lassen). Dann gibt es spezielle Netzwerksniffer (wie auch Etherall) und Du brauchst Jemand der die Datenmenge auswerten kann.Stefan
Moin,
Das Netzwerk (via sniffen) testen lassen gehört zu den letzten Schritten.
Gerade bei Ärzten mit Patentendaten ist das ein warmes Eisen.
Das Log vom Switch - wenn er managebar ist - dagegen sagt nur Port Bla Problem x Port Blub Problem y und x collisions und so was.
Jeder gute Itler, der in seinem Laden die Probleme lösen will rückt so ein Log freiwillig raus.
Das einzigste, was an den Daten "vertraulich" ist - ist die Tatsache, das man mit dem Log Konfigurationsfehler in dem Bereich eindeutig finden kann.
Im Gegensatz zu einem Sniff, denn da sind die Daten auf dem Präsentierteller und erst wenn alles andere ausgeschlossen wurde, würde ich einen Sniff beantragen.
Gruß
Das Netzwerk (via sniffen) testen lassen gehört zu den letzten Schritten.
Gerade bei Ärzten mit Patentendaten ist das ein warmes Eisen.
Das Log vom Switch - wenn er managebar ist - dagegen sagt nur Port Bla Problem x Port Blub Problem y und x collisions und so was.
Jeder gute Itler, der in seinem Laden die Probleme lösen will rückt so ein Log freiwillig raus.
Das einzigste, was an den Daten "vertraulich" ist - ist die Tatsache, das man mit dem Log Konfigurationsfehler in dem Bereich eindeutig finden kann.
Im Gegensatz zu einem Sniff, denn da sind die Daten auf dem Präsentierteller und erst wenn alles andere ausgeschlossen wurde, würde ich einen Sniff beantragen.
Gruß
