10
Netzwerk Probleme analysieren
Hallo zusammen,
bei uns im Hause gibt es einen Mitarbeiter der behauptet das sein Rechnungsprogramm zu langsam laufen würde.
Seine Vermutung ist das Netzwerk. Er meint es wäre zu langsam.
Wenn ich allerdings einen Ping von seinem PC zum Server starte, erhalte ich eine Antwort Zeit von <1ms ( 1GB Netzwerk )
Ich würde ihn gerne vom Gegenteil überzeugen...
Mit welchem Programm könnte ich dem Mitarbeiten überzeugen am besten Graphisch?
Ich könnte natürlich mit Wireshark ein ICMP Protokoll zwischen seinem PC und den Server mitschneiden, aber da erhalte ich ja auch nix anderes als die Antwortzeiten. Oder habe ich irgendwie noch eine andere Möglichkeit mit Wireshark den Traffic auf zu zeichnen?
Es handelt sich um das Programm Auftrax ( Paradox ) die Daten liegen auf dem Server!
Wenn er z.B die Lagertabelle durchsucht, braucht das Programm einige Zeit bis es ein Ergebnis ausspuckt.
Ich könnte natürlich mit Wireshark ein ICMP Protokoll zwischen seinem PC und den Server mitschneiden, aber da erhalte ich ja auch nix anderes als die Antwortzeiten. Oder habe ich irgendwie noch eine andere Möglichkeit mit Wireshark den Traffic auf zu zeichnen?
Es handelt sich um das Programm Auftrax ( Paradox ) die Daten liegen auf dem Server!
Wenn er z.B die Lagertabelle durchsucht, braucht das Programm einige Zeit bis es ein Ergebnis ausspuckt.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 194096
Url: https://administrator.de/contentid/194096
Printed on: April 19, 2024 at 15:04 o'clock
10 Comments
Latest comment
Das macht man mit den kostenlosen Tools NetIO oder iPerf !
Damit kannst du die Durchsatzperformance bei unterschiedlichen Paketgrößen sauber messen und das auch noch unabhängig von irgendwelchem Protokolloverhead.
Wie man das bedient kannst du hier nachlesen:
http://www.nwlab.net/art/netio/netio.html
bzw.
http://www.nwlab.net/know-how/JPerf/
Damit kannst du ihm in 3 Minuten zeigen das es das netzwerk NICHT ist.
(Ggf. aber vorher erstmal für dich allein testen falls es das Netzwerk wider Erwarten dann doch ist
)
Damit kannst du die Durchsatzperformance bei unterschiedlichen Paketgrößen sauber messen und das auch noch unabhängig von irgendwelchem Protokolloverhead.
Wie man das bedient kannst du hier nachlesen:
http://www.nwlab.net/art/netio/netio.html
bzw.
http://www.nwlab.net/know-how/JPerf/
Damit kannst du ihm in 3 Minuten zeigen das es das netzwerk NICHT ist.
(Ggf. aber vorher erstmal für dich allein testen falls es das Netzwerk wider Erwarten dann doch ist
)
Moin,
Um einen Engpaß festzustellen, kann Du im ersten Anlauf mal den taskmanager mitlaufen lassen und in den Reitern Leistung und Netzwerk schauen, ob da irgendetwas auffälliges ist.
Anonsten gibt es noch unert zubehör die Systemüberwachung, wo Du Dir gezielt Plattenzugriffe, CPU-Nutzung u.a. anzeigen lassen kannst.
Um die Reine Übertragungsrate zu messen, gibt es, wie aqui schon erwähnte, u.a. netio und iperf.
Aber bei DBs auf dem Server gibt es ziemlich viele Schrauben an denen man drehen kann. Insbeondere der Plattenio auf dem Server ist meist der kritische Punkt.
lks
Um einen Engpaß festzustellen, kann Du im ersten Anlauf mal den taskmanager mitlaufen lassen und in den Reitern Leistung und Netzwerk schauen, ob da irgendetwas auffälliges ist.
Anonsten gibt es noch unert zubehör die Systemüberwachung, wo Du Dir gezielt Plattenzugriffe, CPU-Nutzung u.a. anzeigen lassen kannst.
Um die Reine Übertragungsrate zu messen, gibt es, wie aqui schon erwähnte, u.a. netio und iperf.
Aber bei DBs auf dem Server gibt es ziemlich viele Schrauben an denen man drehen kann. Insbeondere der Plattenio auf dem Server ist meist der kritische Punkt.
lks
Moin.
Selbst wenn die Benchmarks gute Werte zeigen, sagt dass nichts über die Anwendung aus. Genauer: hat ein Mitarbeiter beispielsweise riesige Arbeitsdaten erzeugt, reicht evtl. nicht mal ein GBit-Netzwerk (wegen Transferrate ODER Latenz).
Die Herangehensweise ist also fragwürdig. Mit dem Benchmark kannst Du ihm zeigen, dass das Netzwerk läuft, wie ein GBit laufen sollte, jedoch schließt Du damit nicht aus, dass das Nw. der Flaschenhals ist.
Sinnvoller wäre, mit anderen Rechnern gleichen Setups zu vergleichen, oder ist er der Einzige mit dieser Software?
Selbst wenn die Benchmarks gute Werte zeigen, sagt dass nichts über die Anwendung aus. Genauer: hat ein Mitarbeiter beispielsweise riesige Arbeitsdaten erzeugt, reicht evtl. nicht mal ein GBit-Netzwerk (wegen Transferrate ODER Latenz).
Die Herangehensweise ist also fragwürdig. Mit dem Benchmark kannst Du ihm zeigen, dass das Netzwerk läuft, wie ein GBit laufen sollte, jedoch schließt Du damit nicht aus, dass das Nw. der Flaschenhals ist.
Sinnvoller wäre, mit anderen Rechnern gleichen Setups zu vergleichen, oder ist er der Einzige mit dieser Software?
Danke erstmal,
ich habe gerade eine Messung zwischen Server und Client vorgenommen
Das Programm ist insgesamt noch auf 3 weiteren AP`s installiert. Auch dort ist das Programm bei einigen Aktionen lange am arbeiten. Aber eigentlich immer nur dann, wenn es halt auf die Lagerdateien zugreift. Wenn man dann den Taskmanager startet, sieht man das die CPU Auslastung auch extrem hoch geht und außerdem steht dann unter Anwendung das dass Programm keine Rückmeldung mehr liefert!
Das Programm ist mittlerweile 12 Jahre alt und ich wüsste ehrlich gesagt auch nicht woran ich da rumschrauben soll.
ich habe gerade eine Messung zwischen Server und Client vorgenommen
Das Programm ist insgesamt noch auf 3 weiteren AP`s installiert. Auch dort ist das Programm bei einigen Aktionen lange am arbeiten. Aber eigentlich immer nur dann, wenn es halt auf die Lagerdateien zugreift. Wenn man dann den Taskmanager startet, sieht man das die CPU Auslastung auch extrem hoch geht und außerdem steht dann unter Anwendung das dass Programm keine Rückmeldung mehr liefert!
Das Programm ist mittlerweile 12 Jahre alt und ich wüsste ehrlich gesagt auch nicht woran ich da rumschrauben soll.
Zitat von @obliterator:
Das Programm ist mittlerweile 12 Jahre alt und ich wüsste ehrlich gesagt auch nicht woran ich da rumschrauben soll.
Das Programm ist mittlerweile 12 Jahre alt und ich wüsste ehrlich gesagt auch nicht woran ich da rumschrauben soll.
Einen Server mit ordentlich Rumms (=CPU-Power) mit SSD aufsetzen und die Leute mit RDP drauf arbeiten lassen. Erschlägt die meisten Probleme mit legacy-Datenbankanwendungen.
lks
Das hört sich nicht nach einem Netzwerk- sondern einem Serverproblem an.
Die Geschwindigkeit ist ja hoch und sobald der Client einen großen Job an den server schickt (Sortieren) dann dauert das eben.
Also da muss man sich vermutlich um das Programm selbst kümmern.
Eine Wireshark Aufzeichnung würde dir nur zeigen, dass die individuellen ANtwortzeiten "quasi" ok sind, aber es immer wieder zu Fehlermeldungen im TCP-Protokoll kommt. Das ist ein Prozeß im TCP-Protokoll, der den Clients etwas erzählt um ihn davon abzuhalten selbst komplett ins timeout zu kommen. (Sehr vereinfacht erzählt)
Gruß
Netman
Die Geschwindigkeit ist ja hoch und sobald der Client einen großen Job an den server schickt (Sortieren) dann dauert das eben.
Also da muss man sich vermutlich um das Programm selbst kümmern.
Eine Wireshark Aufzeichnung würde dir nur zeigen, dass die individuellen ANtwortzeiten "quasi" ok sind, aber es immer wieder zu Fehlermeldungen im TCP-Protokoll kommt. Das ist ein Prozeß im TCP-Protokoll, der den Clients etwas erzählt um ihn davon abzuhalten selbst komplett ins timeout zu kommen. (Sehr vereinfacht erzählt)
Gruß
Netman
Wenn man es ganz genau nehmen will ist es bei dem Programm auch eher so, dass der Datenbestand auf dem Server liegt und an den Clients die Paradox Datenbank installiert wird. Diese holt sich die passenden Informationen vom Server.
Wenn man natürlich nun die Paradox Datenbank auf einem Terminalserver installieren würde und dort die passenden Dateien ebenfalls wären, dann wäre das mit sicherheit schneller... da wirst du Recht haben Lochkartenstanzer
Wenn man natürlich nun die Paradox Datenbank auf einem Terminalserver installieren würde und dort die passenden Dateien ebenfalls wären, dann wäre das mit sicherheit schneller... da wirst du Recht haben Lochkartenstanzer
Zitat von @obliterator:
Wenn man es ganz genau nehmen will ist es bei dem Programm auch eher so, dass der Datenbestand auf dem Server liegt und an den
Clients die Paradox Datenbank installiert wird. Diese holt sich die passenden Informationen vom Server.
Wenn man es ganz genau nehmen will ist es bei dem Programm auch eher so, dass der Datenbestand auf dem Server liegt und an den
Clients die Paradox Datenbank installiert wird. Diese holt sich die passenden Informationen vom Server.
Deswegen mein hinweis auf den Plattenio auf dem Server.
Wenn man natürlich nun die Paradox Datenbank auf einem Terminalserver installieren würde und dort die passenden Dateien
ebenfalls wären, dann wäre das mit sicherheit schneller... da wirst du Recht haben Lochkartenstanzer
ebenfalls wären, dann wäre das mit sicherheit schneller... da wirst du Recht haben Lochkartenstanzer
Auf die Art habe ich schon manche "alten" DB-Anwendugnen beschleunigt. Der Engpass ist meist durch Platten/SSDs mit höherer IOPS zu beheben.
lks
Servus,
Schon mal an den Virenscanner gedacht?
Sind da Ausnahmen für die DB Files auf dem Server definiert?
Nur so als weitere Quelle, warum es langsam sein könnte.
Zitat von @obliterator:
Wenn man es ganz genau nehmen will ist es bei dem Programm auch eher so, dass der Datenbestand auf dem Server liegt und an den
Clients die Paradox Datenbank installiert wird. Diese holt sich die passenden Informationen vom Server.
Wenn man natürlich nun die Paradox Datenbank auf einem Terminalserver installieren würde und dort die passenden Dateien
ebenfalls wären, dann wäre das mit sicherheit schneller... da wirst du Recht haben Lochkartenstanzer
Wenn man es ganz genau nehmen will ist es bei dem Programm auch eher so, dass der Datenbestand auf dem Server liegt und an den
Clients die Paradox Datenbank installiert wird. Diese holt sich die passenden Informationen vom Server.
Wenn man natürlich nun die Paradox Datenbank auf einem Terminalserver installieren würde und dort die passenden Dateien
ebenfalls wären, dann wäre das mit sicherheit schneller... da wirst du Recht haben Lochkartenstanzer
Schon mal an den Virenscanner gedacht?
Sind da Ausnahmen für die DB Files auf dem Server definiert?
Nur so als weitere Quelle, warum es langsam sein könnte.
Ich werde die Anwendung gleich auf unserem Test Terminalserver installieren, werde die Dateien aber denoch erstmal auf dem Datenserver lassen. Mal schauen ob dadurch der Zugriff eventuell schon besser wird.
Bzgl. Virenscanner - ja die DB Files sind vom Scan ausgeschlossen. Allerdings müsste ich Clientseitig das nochmal überprüfen!
Bzgl. Virenscanner - ja die DB Files sind vom Scan ausgeschlossen. Allerdings müsste ich Clientseitig das nochmal überprüfen!
