13
1 Server Win2008R2 - ca. 10 Clients XP - SMB-Dateizugriff extrem verlangsamt - was tun?
Beim gleichzeitigen Zugriff auf dasselbe SMB-Share auf dem Server von vielen Clients kommt es zu extremen Verzögerungen.
Hallo zusammen,
ich habe folgende Netzwerkonfiguration:
1 Server:
Windows 2008 R2, Xeon, 2 SAS-Platten im RAID1, Gbit-Anbindung, 8GB RAM
7 bis 10 Clients:
Windows XP, Intel Core2Duo, 2GB RAM
Die Clients laufen meines Wissens nach alle unter XP, jedoch unter Umständen auch einige mit Win7 dabei (siehe unten)
Auf allen Client-PCs ist eine Software installiert, die als "Datenordner" einen SMB-Share auf dem Server nutzt, der wiederum per Netzlaufwerk auf allen Clients eingebunden ist.
Diese Software nutzt eine Art dateibasierte Datenbankstruktur. Es finden also viele I/O-Operationen statt, und jede dieser Operationen läuft letztendlich über das Netzwerk via SMB. Ein Wechsel der Software ist keine Option.
Die Problematik äußert sich wie folgt: Die Software ist auch bei nur einem aktiven Client schon nicht "schnell". Sobald viele Clients mit der Software arbeiten, kommt es zu extremen Verzögerungen, welche wohl aus dem Nachladen von Daten über SMB resultiert. Zum Teil ist für 15-20 Sekunden wirklich "Stillstand".
Die Daten, die geladen werden, sind von der Menge her eigentlich minimal. Es ist also nicht so, dass große Dateien umhergeschoben werden müssen. Die Netzwerkinfrastruktur sollte mit der Last problemlos klarkommen, und der Server wird dank der SAS-Platten auch nicht der Flaschenhals sein.
Meine erste Google-Suche hat ergeben, dass eine größere Menge Leute berichtet, dass genau dieser Effekt bei der Kombination Win XP / Win Server 2008 R2 auftritt. Hat hierzu jemand von euch Erfahrungswerte?
Aus unzuverlässiger Quelle habe ich gehört, dass auf manchen der Client-Rechner Win7 schon läuft und dort angeblich die gleichen Probleme bestehen. Kann ich erst am Wochenende testen.
Zusammengefasst liegt der Flaschenhals also zu 95% bei der SMB-Übertragung der Daten. Meine Frage an euch ist daher: Wie kann ich das ganze so optimieren, dass es auch beim gleichzeitigen Zugriff durch mehrere Clients läuft? Eine wirkliche Alternative für die Anbindung als Netzlaufwerk (und damit SMB) sehe ich nicht wegen der eingesetzten Software. Womöglich gibt es bekannte "Tweaks", die solche Probleme lösen können?
Danke für jede Hilfe!
ich habe folgende Netzwerkonfiguration:
1 Server:
Windows 2008 R2, Xeon, 2 SAS-Platten im RAID1, Gbit-Anbindung, 8GB RAM
7 bis 10 Clients:
Windows XP, Intel Core2Duo, 2GB RAM
Die Clients laufen meines Wissens nach alle unter XP, jedoch unter Umständen auch einige mit Win7 dabei (siehe unten)
Auf allen Client-PCs ist eine Software installiert, die als "Datenordner" einen SMB-Share auf dem Server nutzt, der wiederum per Netzlaufwerk auf allen Clients eingebunden ist.
Diese Software nutzt eine Art dateibasierte Datenbankstruktur. Es finden also viele I/O-Operationen statt, und jede dieser Operationen läuft letztendlich über das Netzwerk via SMB. Ein Wechsel der Software ist keine Option.
Die Problematik äußert sich wie folgt: Die Software ist auch bei nur einem aktiven Client schon nicht "schnell". Sobald viele Clients mit der Software arbeiten, kommt es zu extremen Verzögerungen, welche wohl aus dem Nachladen von Daten über SMB resultiert. Zum Teil ist für 15-20 Sekunden wirklich "Stillstand".
Die Daten, die geladen werden, sind von der Menge her eigentlich minimal. Es ist also nicht so, dass große Dateien umhergeschoben werden müssen. Die Netzwerkinfrastruktur sollte mit der Last problemlos klarkommen, und der Server wird dank der SAS-Platten auch nicht der Flaschenhals sein.
Meine erste Google-Suche hat ergeben, dass eine größere Menge Leute berichtet, dass genau dieser Effekt bei der Kombination Win XP / Win Server 2008 R2 auftritt. Hat hierzu jemand von euch Erfahrungswerte?
Aus unzuverlässiger Quelle habe ich gehört, dass auf manchen der Client-Rechner Win7 schon läuft und dort angeblich die gleichen Probleme bestehen. Kann ich erst am Wochenende testen.
Zusammengefasst liegt der Flaschenhals also zu 95% bei der SMB-Übertragung der Daten. Meine Frage an euch ist daher: Wie kann ich das ganze so optimieren, dass es auch beim gleichzeitigen Zugriff durch mehrere Clients läuft? Eine wirkliche Alternative für die Anbindung als Netzlaufwerk (und damit SMB) sehe ich nicht wegen der eingesetzten Software. Womöglich gibt es bekannte "Tweaks", die solche Probleme lösen können?
Danke für jede Hilfe!
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: 206397
Url: https://administrator.de/contentid/206397
Printed on: April 24, 2024 at 12:04 o'clock
13 Comments
Latest comment
Hallo,
und den Server dann via LAG (LACP) an den Switch anbinden.
RAID5 an einem neuen Raid Controller (Karte) mit zusätzlichen SAS Festplatten.
Alles zusammen sollte auf jeden Fall Deine Probleme lösen, man kann aber auch Stück für Stück an die
ganze Sache heran gehen und dann halt die letzten noch verbliebenen Schritte einsparen, wenn sich
ein Besserung gezeigt hat.
- Mehr RAM - 16 GB oder 24 GB bis hin zu 32 GB
- Dual oder Quad Port GB Server Adapter von Intel und ein LAG (LACP) anlegen
- Neuen oder zusätzlichen RAID Controller mit 4 weiteren SAS HDDs nur für die Verzeichnisse.
Gruß
Dobby
Windows 2008 R2, Xeon, 2 SAS-Platten im RAID1, Gbit-Anbindung, 8GB RAM
Wie sieht es mit 16 oder 24 GB RAM aus?Wie kann ich das ganze so optimieren, dass es auch beim gleichzeitigen Zugriff durch mehrere Clients läuft?
Eine Quad Port oder zwei Dual Port GB Netzwerkkarten (Serveradapter), am besten von Intel,und den Server dann via LAG (LACP) an den Switch anbinden.
Eine wirkliche Alternative für die Anbindung als Netzlaufwerk (und damit SMB) sehe ich nicht wegen der eingesetzten Software.
Ok, aber dann lass doch bitte auch nur das OS auf dem Raid1 und packe die Verzeichnisse auf einRAID5 an einem neuen Raid Controller (Karte) mit zusätzlichen SAS Festplatten.
Womöglich gibt es bekannte "Tweaks", die solche Probleme lösen können?
Ich hoffe doch einmal stark das Du auch Hardware Erweiterungen als "Tweak" anerkennst.Alles zusammen sollte auf jeden Fall Deine Probleme lösen, man kann aber auch Stück für Stück an die
ganze Sache heran gehen und dann halt die letzten noch verbliebenen Schritte einsparen, wenn sich
ein Besserung gezeigt hat.
- Mehr RAM - 16 GB oder 24 GB bis hin zu 32 GB
- Dual oder Quad Port GB Server Adapter von Intel und ein LAG (LACP) anlegen
- Neuen oder zusätzlichen RAID Controller mit 4 weiteren SAS HDDs nur für die Verzeichnisse.
Gruß
Dobby
Hallo,
vielen Dank erstmal für deine schnelle Antwort.
Ich weiß nicht, ob die von dir vorgeschlagenen Änderungen die Situation wirklich verbessern würden, denn weder ist die Netzwerkleitung am Server ausgelastet wird der RAM auch nur annähernd voll. Sorry, das habe ich im Startpost vermutlich nicht richtig klar gemacht.
Die Investition in ein zusätzliches RAID5 mit neuen SAS-Platten wäre denkbar. Jedoch kann ich mir nicht vorstellen, dass dies einen Unterschied ausmacht im Bereich "von 20 Sekunden Wartezeit vorher auf <1 Sekunde, wie man es erwarten würde". Das OS idlet bis auf diesen Netzwerkshare praktisch nur herum, das kann - meinem Verständnis nach - ja nicht viel Last auf dem SAS-Raid1 erzeugen. Die Investition läge hier ja direkt im Bereich von mindestens ca. 1500 Euro, was ohne konkrete Aussicht auf Erfolg natürlich eine Menge Geld ist.
Irgendetwas sagt mir, dass hier kein hardwaretechnisches Problem, sondern vielmehr ein Problem mit SMB vorliegt, evtl. zusätzlich aufgrund der Verwendung von XP i.V.m. Server 2008R2. Aber ich habe keine wirklich konkreten Anhaltspunkte und somit ist das nur Spekulation.
Das einzige, was Fakt ist, ist, dass diese SMB-Verbindung besonders bei mehreren aktiven Client-Rechnern eben extrem langsam wird.
Von einer externen Firma wurde vorgeschlagen, auf eine Terminalserver-Lösung zu migrieren. Es wäre mir aber natürlich lieber, wenn dieses Problem mit bestehender Hardware gelöst werden kann. Ich kann mir irgendwie nicht vorstellen, dass die Performance bei SMB und solch durchaus guter Hardware derart schlecht ist.
vielen Dank erstmal für deine schnelle Antwort.
Ich weiß nicht, ob die von dir vorgeschlagenen Änderungen die Situation wirklich verbessern würden, denn weder ist die Netzwerkleitung am Server ausgelastet wird der RAM auch nur annähernd voll. Sorry, das habe ich im Startpost vermutlich nicht richtig klar gemacht.
Die Investition in ein zusätzliches RAID5 mit neuen SAS-Platten wäre denkbar. Jedoch kann ich mir nicht vorstellen, dass dies einen Unterschied ausmacht im Bereich "von 20 Sekunden Wartezeit vorher auf <1 Sekunde, wie man es erwarten würde". Das OS idlet bis auf diesen Netzwerkshare praktisch nur herum, das kann - meinem Verständnis nach - ja nicht viel Last auf dem SAS-Raid1 erzeugen. Die Investition läge hier ja direkt im Bereich von mindestens ca. 1500 Euro, was ohne konkrete Aussicht auf Erfolg natürlich eine Menge Geld ist.
Irgendetwas sagt mir, dass hier kein hardwaretechnisches Problem, sondern vielmehr ein Problem mit SMB vorliegt, evtl. zusätzlich aufgrund der Verwendung von XP i.V.m. Server 2008R2. Aber ich habe keine wirklich konkreten Anhaltspunkte und somit ist das nur Spekulation.
Das einzige, was Fakt ist, ist, dass diese SMB-Verbindung besonders bei mehreren aktiven Client-Rechnern eben extrem langsam wird.
Von einer externen Firma wurde vorgeschlagen, auf eine Terminalserver-Lösung zu migrieren. Es wäre mir aber natürlich lieber, wenn dieses Problem mit bestehender Hardware gelöst werden kann. Ich kann mir irgendwie nicht vorstellen, dass die Performance bei SMB und solch durchaus guter Hardware derart schlecht ist.
Wenn deine Clients XP basierend sind hast du dessen TCP/IP Stack entsprechend angepasst und auf Ethernet optimiert indem du die TCP Windowsize entsprechend angepasst hast ?
http://www.heise.de/netze/artikel/TCP-IP-Tuning-221778.html
Das ist im SMB/CIFS Umfeld zwingend erforderlich !
Es wäre auch sehr sinnvoll einmal zu messen was dein Netzwerk an sich an Durchsatz hergibt, nur damit man hier mal eine verlässliche Vergleichsgröße zur Orientierung überhaupt hat.
Am besten misst du das mit dem kostenlosen NetIO:
http://www.ars.de/ars/ars.nsf/docs/netio
Wie das zu bewerkstelligen ist wird hier erklärt:
http://www.nwlab.net/art/netio/netio.html
Darauf achten das in deinem Server keinesfalls ein NIC mit Realtec Chipsatz werkelt solltest du auch.
Mit den Schritten kommst du schon mal weiter...
http://www.heise.de/netze/artikel/TCP-IP-Tuning-221778.html
Das ist im SMB/CIFS Umfeld zwingend erforderlich !
Es wäre auch sehr sinnvoll einmal zu messen was dein Netzwerk an sich an Durchsatz hergibt, nur damit man hier mal eine verlässliche Vergleichsgröße zur Orientierung überhaupt hat.
Am besten misst du das mit dem kostenlosen NetIO:
http://www.ars.de/ars/ars.nsf/docs/netio
Wie das zu bewerkstelligen ist wird hier erklärt:
http://www.nwlab.net/art/netio/netio.html
Darauf achten das in deinem Server keinesfalls ein NIC mit Realtec Chipsatz werkelt solltest du auch.
Mit den Schritten kommst du schon mal weiter...
1
Hallo aqui,
ich danke dir für diese Tipps, ich werde alles umsetzen (u.U. erst am Wochenende) und mich dann zurückmelden!
Natürlich bin ich bis dahin auch dankbar für _jeden_ weiteren Beitrag.
ich danke dir für diese Tipps, ich werde alles umsetzen (u.U. erst am Wochenende) und mich dann zurückmelden!
Natürlich bin ich bis dahin auch dankbar für _jeden_ weiteren Beitrag.
Hallo,
Da du leider keine genaueren Angaben zur Software machst: Wäre es vielleicht denkbar, dass es ein Problem mit der Software als solches ist? Möglicherweise gibt es da bestimmte Locks, die sich beim Zugriff auf die Daten gegenseitig blockieren, bis irgendein Client nachgibt (Dining Philosophers).
Du schreibst es sei schon mit einem einzelnen Client recht langsam. Auch wenn dieser Client der Server selbst (also lokaler Dateizugriff) ist?
Zitat von @Toastking:
Auf allen Client-PCs ist eine Software installiert, die als "Datenordner" einen SMB-Share auf dem Server nutzt, der
wiederum per Netzlaufwerk auf allen Clients eingebunden ist.
Diese Software nutzt eine Art dateibasierte Datenbankstruktur. Es finden also viele I/O-Operationen statt, und jede dieser
Operationen läuft letztendlich über das Netzwerk via SMB. Ein Wechsel der Software ist keine Option.
Auf allen Client-PCs ist eine Software installiert, die als "Datenordner" einen SMB-Share auf dem Server nutzt, der
wiederum per Netzlaufwerk auf allen Clients eingebunden ist.
Diese Software nutzt eine Art dateibasierte Datenbankstruktur. Es finden also viele I/O-Operationen statt, und jede dieser
Operationen läuft letztendlich über das Netzwerk via SMB. Ein Wechsel der Software ist keine Option.
Da du leider keine genaueren Angaben zur Software machst: Wäre es vielleicht denkbar, dass es ein Problem mit der Software als solches ist? Möglicherweise gibt es da bestimmte Locks, die sich beim Zugriff auf die Daten gegenseitig blockieren, bis irgendein Client nachgibt (Dining Philosophers).
Du schreibst es sei schon mit einem einzelnen Client recht langsam. Auch wenn dieser Client der Server selbst (also lokaler Dateizugriff) ist?
Laufen denn alle Beteiligten "Maschinen" (PCs, Switche & Server) mit 1 GBit/s FullDuplex oder
ist das alles ein Mischmasch aus verschiedenen Geschwindigkeiten?
Gruß
Dobby
P.S.
Ich meine jetzt nicht was die Maschinen laut Datenblatt können! Sondern was wirklich eingestellt ist!
ist das alles ein Mischmasch aus verschiedenen Geschwindigkeiten?
Gruß
Dobby
P.S.
Ich meine jetzt nicht was die Maschinen laut Datenblatt können! Sondern was wirklich eingestellt ist!
Zitat von @aqui:
Wenn deine Clients XP basierend sind hast du dessen TCP/IP Stack entsprechend angepasst und auf Ethernet optimiert indem du die
TCP Windowsize entsprechend angepasst hast ?
http://www.heise.de/netze/artikel/TCP-IP-Tuning-221778.html
Das ist im SMB/CIFS Umfeld zwingend erforderlich !
Wenn deine Clients XP basierend sind hast du dessen TCP/IP Stack entsprechend angepasst und auf Ethernet optimiert indem du die
TCP Windowsize entsprechend angepasst hast ?
http://www.heise.de/netze/artikel/TCP-IP-Tuning-221778.html
Das ist im SMB/CIFS Umfeld zwingend erforderlich !
Ich habe heute erfahren, dass ca. die Hälfte der Client-Rechner mit Windows 7 läuft. Also ca. 50/50 XP und Win7. Ist auf Win7-basierten Rechnern ebenfalls eine Verbesserung der Performance zu erwarten, wenn die TCP Windowsize angepasst wird, oder ist dies ein Schritt, welcher nur bei XP-Rechnern sinnvoll ist?
Zitat von @fnord2000:
Da du leider keine genaueren Angaben zur Software machst: Wäre es vielleicht denkbar, dass es ein Problem mit der Software
als solches ist? Möglicherweise gibt es da bestimmte Locks, die sich beim Zugriff auf die Daten gegenseitig blockieren, bis
irgendein Client nachgibt (Dining Philosophers).
Du schreibst es sei schon mit einem einzelnen Client recht langsam. Auch wenn dieser Client der Server selbst (also lokaler
Dateizugriff) ist?
Da du leider keine genaueren Angaben zur Software machst: Wäre es vielleicht denkbar, dass es ein Problem mit der Software
als solches ist? Möglicherweise gibt es da bestimmte Locks, die sich beim Zugriff auf die Daten gegenseitig blockieren, bis
irgendein Client nachgibt (Dining Philosophers).
Du schreibst es sei schon mit einem einzelnen Client recht langsam. Auch wenn dieser Client der Server selbst (also lokaler
Dateizugriff) ist?
Hallo,
das ist schon möglich. Der Hersteller der Software hat mir gegenüber die Aussage gemacht, dass eine Art dateibasiertes Datenbanksystem verwendet wird und daher eben eine sehr große Anzahl an I/O Operationen stattfindet. Lokal läuft das Programm aber angeblich problemlos und schnell, weshalb die zusätzliche Verzögerung nur aus dem Netzwerktransfer resultieren kann.
Daher wurde jetzt auch eine Lösung als Terminalserver angedacht, d.h. dass die Software auf dem Server läuft und per RDP auf die Clients gestreamt wird. Dieser Umstieg ist aber sehr teuer und meine Hoffnung ist, auch eine Besserung ohne diese Änderung erzielen zu können, da SMB meines Erachtens nach nicht so langsam sein darf.
@d.o.b.b.y: Die Switches und der Server sind def Gbit. Zu den Clients kann ich keine definitive Aussage machen, es wäre schon möglich, dass hier evtl. 100Mbit-Ports teilweise vorhanden sind. Diese Bandbreite sollte pro Client aber eigentlich mehr als ausreichen.
Mit welchem Tool könnte ich am besten mitloggen, wie groß die übertragene Netzwerkdatenmenge ist? Und am besten auch zusätzliche Informationen wie Dateizugriffe auf den SMB-Share? Gibt es da Standardtools?
Windows 7 passt die Windowsize automatisch an, denn es hat einen vollkommen neuen TCP/IP Stack. Da ist nichts zu machen.
Der üble Knackpunkt sind die XP Rechner ! Die musst du anfassen !
Sinnvoll ist natürlich auch eine gute Netzwerk Karten Hardware auf dem Server einzusetzen. Billige onboard Realtek Chipsätze usw. haben darauf natürlich gar nichts zu suchen. Das solltest du auch sicherstellen !
Und...natürlich den NetIO Test durchführen um beurteilen zu können was dein Netzwerk überhaupt für Transferraten hergibt.
Idealerweise machst du das zwischen deinem Server und einem Client. Noch idealerweise wenn der Client einmal XP und Win 7 ist.
Das NetIO ist eine kleine Programmdatei die in der Eingabeaufforderung gestartet wird ist also ganz einfach zu machen !
Die Werte wären sinnvoll zu wissen hier !
Der üble Knackpunkt sind die XP Rechner ! Die musst du anfassen !
Sinnvoll ist natürlich auch eine gute Netzwerk Karten Hardware auf dem Server einzusetzen. Billige onboard Realtek Chipsätze usw. haben darauf natürlich gar nichts zu suchen. Das solltest du auch sicherstellen !
Und...natürlich den NetIO Test durchführen um beurteilen zu können was dein Netzwerk überhaupt für Transferraten hergibt.
Idealerweise machst du das zwischen deinem Server und einem Client. Noch idealerweise wenn der Client einmal XP und Win 7 ist.
Das NetIO ist eine kleine Programmdatei die in der Eingabeaufforderung gestartet wird ist also ganz einfach zu machen !
Die Werte wären sinnvoll zu wissen hier !
Alles klar, ich werde das machen und dann hier berichten.
Denke mal, dass ich die Bedienung von NetIO hinbekommen werde, befinde mich gerade im Masterstudium Informatik
Aber da ist der Schwerpunkt eben eher softwareseitig, weshalb ich in dem Bereich, um den es hier geht, maximal gute Grundkenntnisse aufweise. Danke nochmals für deine Hilfe soweit!
Denke mal, dass ich die Bedienung von NetIO hinbekommen werde, befinde mich gerade im Masterstudium Informatik
Aber da ist der Schwerpunkt eben eher softwareseitig, weshalb ich in dem Bereich, um den es hier geht, maximal gute Grundkenntnisse aufweise. Danke nochmals für deine Hilfe soweit!
Hallo zusammen,
sorry, dass ich mich erst jetzt zurückmelde, war ein stressiges Wochenende. Also die Performancetests mit NetIO liefen sowohl auf den XP- als auch auf den Win7-Rechnern nahezu perfekt ab (jeweils 100-120MB pro Sekunde, je nach Blockgröße, aber nicht drunter).
Da diese extremen Verzögerungen ja nur auftreten, wenn mehrere Clients zugleich aktiv sind, kann ich mir das jetzt nur noch mit dem dateibasierten Datenhaltungssystem der Software erklären, sodass hier wohl kein lösbares Netzwerkproblem vorliegt. Die vorgeschlagene Terminalserver-Lösung ist also vermutlich gar nicht so schlecht, da diese Zugriffe lokal auf dem Server deutlich schneller ablaufen dürften. Oder hat jemand von euch noch einen alternativen Vorschlag?
Eine zusätzlichze Frage noch: Die Firma, von der der Vorschlag mit dem Terminalserver stammt, sieht ein Upgrade der Serverlizenz von 2008R2 Foundation auf 2008R2 Standard vor. Hierzu 2 Fragen:
1. Ist "Standard" für den Terminalbetrieb notwendig oder reicht womöglich Foundation?
2. Kann man anstelle eines kompletten Lizenz-Neukaufs auch die vorhandene Foundation-Lizenz auf Standard upgraden? Das wäre wirklich super, weil wirtschaftlich gesehen ist der Lizenz-Neukauf ja katastrophal, zumal die Foundation-Lizenz danach quasi "verworfen" und nicht mehr genutzt wird.
Danke nochmal!
sorry, dass ich mich erst jetzt zurückmelde, war ein stressiges Wochenende. Also die Performancetests mit NetIO liefen sowohl auf den XP- als auch auf den Win7-Rechnern nahezu perfekt ab (jeweils 100-120MB pro Sekunde, je nach Blockgröße, aber nicht drunter).
Da diese extremen Verzögerungen ja nur auftreten, wenn mehrere Clients zugleich aktiv sind, kann ich mir das jetzt nur noch mit dem dateibasierten Datenhaltungssystem der Software erklären, sodass hier wohl kein lösbares Netzwerkproblem vorliegt. Die vorgeschlagene Terminalserver-Lösung ist also vermutlich gar nicht so schlecht, da diese Zugriffe lokal auf dem Server deutlich schneller ablaufen dürften. Oder hat jemand von euch noch einen alternativen Vorschlag?
Eine zusätzlichze Frage noch: Die Firma, von der der Vorschlag mit dem Terminalserver stammt, sieht ein Upgrade der Serverlizenz von 2008R2 Foundation auf 2008R2 Standard vor. Hierzu 2 Fragen:
1. Ist "Standard" für den Terminalbetrieb notwendig oder reicht womöglich Foundation?
2. Kann man anstelle eines kompletten Lizenz-Neukaufs auch die vorhandene Foundation-Lizenz auf Standard upgraden? Das wäre wirklich super, weil wirtschaftlich gesehen ist der Lizenz-Neukauf ja katastrophal, zumal die Foundation-Lizenz danach quasi "verworfen" und nicht mehr genutzt wird.
Danke nochmal!
Zitat von @Toastking:
Da diese extremen Verzögerungen ja nur auftreten, wenn mehrere Clients zugleich aktiv sind, kann ich mir das jetzt nur noch
mit dem dateibasierten Datenhaltungssystem der Software erklären, sodass hier wohl kein lösbares Netzwerkproblem
vorliegt. Die vorgeschlagene Terminalserver-Lösung ist also vermutlich gar nicht so schlecht, da diese Zugriffe lokal auf dem
Server deutlich schneller ablaufen dürften. Oder hat jemand von euch noch einen alternativen Vorschlag?
Da diese extremen Verzögerungen ja nur auftreten, wenn mehrere Clients zugleich aktiv sind, kann ich mir das jetzt nur noch
mit dem dateibasierten Datenhaltungssystem der Software erklären, sodass hier wohl kein lösbares Netzwerkproblem
vorliegt. Die vorgeschlagene Terminalserver-Lösung ist also vermutlich gar nicht so schlecht, da diese Zugriffe lokal auf dem
Server deutlich schneller ablaufen dürften. Oder hat jemand von euch noch einen alternativen Vorschlag?
Keine Alternative, aber ich möchte nur noch mal auf meine ursprüngliche Anmerkung hinweisen, dass die Software sich möglicherweise selbst blockiert.
Daher würde ich empfehlen, dass du zuerst mal testest, ob sich die Software wirklich ausreichend schnell bedienen lässt, wenn alle Nutzer lokal darauf zugreifen.
Es wäre doch reichlich ärgerlich, wenn du Zeit und Geld in die Terminalserver-Lösung steckst, nur um dann festzustellen, dass sich keine Besserung eingestellt hat.
Ansonsten bliebe vielleicht lediglich, den Hersteller zu fragen, ob er in näherer Zukunft gedenkt die Datenbank auch auf einer "richtigen" Datenbank betreiben zu können.
Zitat von @fnord2000:
Keine Alternative, aber ich möchte nur noch mal auf meine ursprüngliche Anmerkung hinweisen, dass die Software sich
möglicherweise selbst blockiert.
Daher würde ich empfehlen, dass du zuerst mal testest, ob sich die Software wirklich ausreichend schnell bedienen lässt,
wenn alle Nutzer lokal darauf zugreifen.
Es wäre doch reichlich ärgerlich, wenn du Zeit und Geld in die Terminalserver-Lösung steckst, nur um dann
festzustellen, dass sich keine Besserung eingestellt hat.
Ansonsten bliebe vielleicht lediglich, den Hersteller zu fragen, ob er in näherer Zukunft gedenkt die Datenbank auch auf
einer "richtigen" Datenbank betreiben zu können.
Keine Alternative, aber ich möchte nur noch mal auf meine ursprüngliche Anmerkung hinweisen, dass die Software sich
möglicherweise selbst blockiert.
Daher würde ich empfehlen, dass du zuerst mal testest, ob sich die Software wirklich ausreichend schnell bedienen lässt,
wenn alle Nutzer lokal darauf zugreifen.
Es wäre doch reichlich ärgerlich, wenn du Zeit und Geld in die Terminalserver-Lösung steckst, nur um dann
festzustellen, dass sich keine Besserung eingestellt hat.
Ansonsten bliebe vielleicht lediglich, den Hersteller zu fragen, ob er in näherer Zukunft gedenkt die Datenbank auch auf
einer "richtigen" Datenbank betreiben zu können.
Es vorab zu testen, hatte ich geplant. Gegen Ende der Woche wollte ich mal zu einem Zeitpunkt hoher Auslastung die Software lokal auf dem Server starten. Müsste dann ja eigentlich problemlos funktionieren. Ich bin gespannt
Der Hersteller der Software hat mir mitgeteilt, dass an einer SQL-basierten Datenbanknutzung gearbeitet wird, dies aber noch einen unbestimmten Zeitraum dauern kann... Das ist nicht gerade ein wenig genutztes Softwareprodukt, manchmal wundert man sich schon, mit welcher Softwarequalität man sich am Markt durchsetzen kann.
