Performance mit Windows Server 2016
Moderator: Moderatoren
- Koverhage
- Der Entwickler von "Deep Thought"
- Beiträge: 2471
- Registriert: Fr, 23. Dez 2005 8:00
- Wohnort: Aalen
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Performance mit Windows Server 2016
Ein Kunde hat auf Windows Server 2016 umgestellt und hat seitdem extreme
Performance Probleme mit unserer Anwendung. Kennt jemand von Euch die Schalter
die man setzen kann/sollte/muss, damit es mit akzeptabler Geschwindigkeit läuft ?
Performance Probleme mit unserer Anwendung. Kennt jemand von Euch die Schalter
die man setzen kann/sollte/muss, damit es mit akzeptabler Geschwindigkeit läuft ?
Gruß
Klaus
Klaus
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: Performance mit Windows Server 2016
Hallo Klaus !
https://www.administrator.de/frage/foxp ... 89333.html
- SMB2-Protokoll (Danke Tom):
Zum deaktivieren: Ausführen von smb2-infocache.msi
- Für Windows 8 clients:
Disable "Secure Negotiate" on the client. You can disable the Secure Negotiate option by using PowerShell on a Windows Server 2012 or Windows 8 client. To do this, run the following command:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" RequireSecureNegotiate -Value 0 -Force
und vor allem das hier ist beim 2016er neu dazu gekommen:
- Disable fair sharing of the disk
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk\EnableFairShare] auf 0 setzen.
- Disable fair sharing of the CPU:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Quota System\EnableCPUQuota auf 0 setzen.
- Disable fair sharing of the network:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\NetFS\EnableFairShare auf 0 setzen.
- Digitally Sign Communications immer abschalten wenn der Server der Domain-Controller ist:
Sie können diese Einstellungen im Group Policy Editor auf dem Windows 2012 R2-Server ändern. Dafür öffnen Sie den Group Policy Editor und klicken mit der rechten Maustaste auf Default Domain Controller Policy. Wechseln Sie zu Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options und setzen Sie die Einstellungen Domain member: Digitally encrypt or sign secure channel data (always) und Microsoft network server: Digitally sign communications (always) auf Disabled.
Wurde auf der 2016er DEVCON von Rainer Becker zusammengestellt und vorgetragen.
Bitte hier lesen:Ein Kunde hat auf Windows Server 2016 umgestellt und hat seitdem extreme
Performance Probleme mit unserer Anwendung.
https://www.administrator.de/frage/foxp ... 89333.html
- SMB2-Protokoll (Danke Tom):
Zum deaktivieren: Ausführen von smb2-infocache.msi
- Für Windows 8 clients:
Disable "Secure Negotiate" on the client. You can disable the Secure Negotiate option by using PowerShell on a Windows Server 2012 or Windows 8 client. To do this, run the following command:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" RequireSecureNegotiate -Value 0 -Force
und vor allem das hier ist beim 2016er neu dazu gekommen:
- Disable fair sharing of the disk
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk\EnableFairShare] auf 0 setzen.
- Disable fair sharing of the CPU:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Quota System\EnableCPUQuota auf 0 setzen.
- Disable fair sharing of the network:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\NetFS\EnableFairShare auf 0 setzen.
- Digitally Sign Communications immer abschalten wenn der Server der Domain-Controller ist:
Sie können diese Einstellungen im Group Policy Editor auf dem Windows 2012 R2-Server ändern. Dafür öffnen Sie den Group Policy Editor und klicken mit der rechten Maustaste auf Default Domain Controller Policy. Wechseln Sie zu Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options und setzen Sie die Einstellungen Domain member: Digitally encrypt or sign secure channel data (always) und Microsoft network server: Digitally sign communications (always) auf Disabled.
Wurde auf der 2016er DEVCON von Rainer Becker zusammengestellt und vorgetragen.
Zuletzt geändert von HaPe am Mi, 01. Feb 2017 16:19, insgesamt 1-mal geändert.
--
Hans-Peter
Hans-Peter
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 105 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Performance mit Windows Server 2016
smb2-infocache.msi hat nichts mit Oplocks zu tun. Es schaltet das Caching von Datei-Metadaten ab.
Herzlich,
Tom
Tom
Re: Performance mit Windows Server 2016
Hallo Klaus
was war das bei dem Kunden vorher für ein Server-Betriebssystem auf dem Dein Programm fehlerfrei lief?(Du schreibst es wurde auf 2016 umgestellt).
Zuletzt geändert von DelUser01 am Do, 02. Feb 2017 3:53, insgesamt 1-mal geändert.
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Performance mit Windows Server 2016
hi,
sind die SMB3 Registry Einträge notwendig für Xbase ( alle Versionen ) ?
Windows 7 kennt kein SMB3 welche mit Windows 8.x und Srv2012 eingeführt würde.
wenn ich auf ein SMB3 unterstütztes Laufwerk zugreifen will geht das nicht mit Windows 7
andererseit passiert es, wenn unter Windows 8.x SMB3 aktive ist, das man nicht
auf SMB2 / CFS share zugreifen kann ohne die Fehlermeldung :
wie ich ja immer sage: vergesst NET USE und den Lanmanager mit SMB1 ab Vista/Srv2008
---
---
SMB3 wurde IMHO eingeführt für die Sharepoint Produkte um gemeinsam an Office Produkten arbeiten zu können. wenn man im Netzwerk gemeinsam an einer Excel Tabelle arbeiten wollte ging das vorher nicht ... man bekam nur eine "Kopie"
man musste also für "diese" Produkte ein neues SMB3 einführen was IMHO nur von den Produkten benutzt wird. dazu gehört der Exchange Server und natürlich der MSSQL Server ...
und "das" ist nun IMHO das Xbase (alle Versionen) Problem denn für Xbase benötige ich einen "File" Server. ein Server wo SQL läuft wird anders optimiert als ein "File" Server der, wie auch ein NAS, mit CFS / SMB1-SMB2 arbeitet.
---
bei dem Kunden von Klaus denke ich nicht das es SMB3 Probleme sind.
allerdings sind die Informationen viel zu gering als das man irgendwas aussagen könnte.
Frage : sind alle "Hausaufgaben" gemacht worden ?
es gibt nicht "einen Schalter" den man umlegen könnte damit Cl*pper Code unter Xbase++ mit SMB2 läuft.
DOS Programme in der CMD Box mögen ja mit Laufwerksbuchstaben und NET USE über Lanmanager SMB1 funktionieren, aber 32bit Programme arbeiten mit dem vom OS() "bevorzugten" Code wo SMB2 vorgesehen ist. das "umschalten" zwischen SMB1 und SMB2 ist nun das Problem beim Server.
---
die Alaska SMB2 Patch ist für Lanmanworkstation, also gegen lokale Problem die auftretenen wenn der lokale Cache nicht "Bescheid" weiss. Informationen im Netzwerk gibt es über "freigegebene" Ordner.
seit Windows Vista läuft auf dem Client PC auch der "Server".
wenn man wie empfohlen auf "full-UNC" Path umstellt muss man ja auch lokale Ordner "freigeben" um als User (!!!) auf die Dateien per "full-UNC" zuzugreifen.
der Alaska SMB2 Patch ist deshalb IMHO mehr Faulheit des User denn denn lokale Cache abzuschalten ist eine "VW" Lösung die sich irgendwann rächt.
sind die SMB3 Registry Einträge notwendig für Xbase ( alle Versionen ) ?
Windows 7 kennt kein SMB3 welche mit Windows 8.x und Srv2012 eingeführt würde.
wenn ich auf ein SMB3 unterstütztes Laufwerk zugreifen will geht das nicht mit Windows 7
andererseit passiert es, wenn unter Windows 8.x SMB3 aktive ist, das man nicht
auf SMB2 / CFS share zugreifen kann ohne die Fehlermeldung :
in diesem Fall muss man dann "RequireSecureNegotiate" abschalten.SMB connections fail with error “Invalid Signature”
das "disable" ist dabei NICHT "wörtlich" gemeint. vielmehr soll man keine Programm/Dienste verwenden welche die UDP Ports 135-139 und SMB1 benutzen sondern die SMB2 Ports z.B 445"It is recommended that SMB1 is disabled if all clients in your environments are SMB2 capable"
wie ich ja immer sage: vergesst NET USE und den Lanmanager mit SMB1 ab Vista/Srv2008
---
... hm ... ist das nicht für Remote Desktop ?"EnableFairShare"
"EnableCPUQuota"
---
SMB3 wurde IMHO eingeführt für die Sharepoint Produkte um gemeinsam an Office Produkten arbeiten zu können. wenn man im Netzwerk gemeinsam an einer Excel Tabelle arbeiten wollte ging das vorher nicht ... man bekam nur eine "Kopie"
man musste also für "diese" Produkte ein neues SMB3 einführen was IMHO nur von den Produkten benutzt wird. dazu gehört der Exchange Server und natürlich der MSSQL Server ...
und "das" ist nun IMHO das Xbase (alle Versionen) Problem denn für Xbase benötige ich einen "File" Server. ein Server wo SQL läuft wird anders optimiert als ein "File" Server der, wie auch ein NAS, mit CFS / SMB1-SMB2 arbeitet.
---
bei dem Kunden von Klaus denke ich nicht das es SMB3 Probleme sind.
allerdings sind die Informationen viel zu gering als das man irgendwas aussagen könnte.
Frage : sind alle "Hausaufgaben" gemacht worden ?
es gibt nicht "einen Schalter" den man umlegen könnte damit Cl*pper Code unter Xbase++ mit SMB2 läuft.
DOS Programme in der CMD Box mögen ja mit Laufwerksbuchstaben und NET USE über Lanmanager SMB1 funktionieren, aber 32bit Programme arbeiten mit dem vom OS() "bevorzugten" Code wo SMB2 vorgesehen ist. das "umschalten" zwischen SMB1 und SMB2 ist nun das Problem beim Server.
---
die Alaska SMB2 Patch ist für Lanmanworkstation, also gegen lokale Problem die auftretenen wenn der lokale Cache nicht "Bescheid" weiss. Informationen im Netzwerk gibt es über "freigegebene" Ordner.
seit Windows Vista läuft auf dem Client PC auch der "Server".
wenn man wie empfohlen auf "full-UNC" Path umstellt muss man ja auch lokale Ordner "freigeben" um als User (!!!) auf die Dateien per "full-UNC" zuzugreifen.
der Alaska SMB2 Patch ist deshalb IMHO mehr Faulheit des User denn denn lokale Cache abzuschalten ist eine "VW" Lösung die sich irgendwann rächt.
gruss by OHR
Jimmy
Jimmy
- Koverhage
- Der Entwickler von "Deep Thought"
- Beiträge: 2471
- Registriert: Fr, 23. Dez 2005 8:00
- Wohnort: Aalen
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Performance mit Windows Server 2016
Roland,
denke mal Server 2008 oder 2012 muss mich abfragen.
denke mal Server 2008 oder 2012 muss mich abfragen.
Gruß
Klaus
Klaus
- Koverhage
- Der Entwickler von "Deep Thought"
- Beiträge: 2471
- Registriert: Fr, 23. Dez 2005 8:00
- Wohnort: Aalen
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Performance mit Windows Server 2016
Jimmy,
ich benutze keine DOS Programme.
Wir als Software Hersteller können doch nur Hinweise geben was eingestellt werden muss/sollte.
Tatsache ist und bleibt: Diese Probleme gibt es meines Wissens in der Form nur bei Xbase++ Programmen!
ich benutze keine DOS Programme.
Welchen User meinst Du damit ? Der normale Anwender hat die Kenntnis darüber nicht und meisten auch nicht die Rechte.der Alaska SMB2 Patch ist deshalb IMHO mehr Faulheit des User denn denn lokale Cache abzuschalten ist eine "VW" Lösung die sich irgendwann rächt.
Wir als Software Hersteller können doch nur Hinweise geben was eingestellt werden muss/sollte.
Tatsache ist und bleibt: Diese Probleme gibt es meines Wissens in der Form nur bei Xbase++ Programmen!
Gruß
Klaus
Klaus
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Performance mit Windows Server 2016
Hallo Klaus
Die Probleme tauchen auf sobald Windows Verzeichnisinhalte und auch Dateien lokal speichert und so u.U. dem Anwender-Programm Angaben/Daten liefert die sich auf dem Server schon lange geändert haben.
Leider schlägt Windows immer mehr den Weg zu eigenen Cloud Lösungen ein und wird immer mehr in dieser Richtung optimiert, die kleinen Anbieter/Programme bleiben mit Ihren Anforderungen leider immer öfter als Kollateralschaden auf der Strecke. Da du dich bei neuen Versionen nicht mehr auf Jahre lang gültige Annahmen/Funktionsweisen verlassen kannst.
Wenn du IT Entscheidungsträger bist, bietet sich eine sehr Performate und auch günstige Alternative zum Windows Server an: FreeBSD ........
Cu Carlo
da muss ich dir aber aus eigener Erfahrung wiedersprechen!! Dem ist nicht so.Diese Probleme gibt es meines Wissens in der Form nur bei Xbase++ Programmen!
Die Probleme tauchen auf sobald Windows Verzeichnisinhalte und auch Dateien lokal speichert und so u.U. dem Anwender-Programm Angaben/Daten liefert die sich auf dem Server schon lange geändert haben.
Leider schlägt Windows immer mehr den Weg zu eigenen Cloud Lösungen ein und wird immer mehr in dieser Richtung optimiert, die kleinen Anbieter/Programme bleiben mit Ihren Anforderungen leider immer öfter als Kollateralschaden auf der Strecke. Da du dich bei neuen Versionen nicht mehr auf Jahre lang gültige Annahmen/Funktionsweisen verlassen kannst.
Wenn du IT Entscheidungsträger bist, bietet sich eine sehr Performate und auch günstige Alternative zum Windows Server an: FreeBSD ........
Cu Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: Performance mit Windows Server 2016
Hallo Jimmy !
Es wurde berichtet, dass durch FairShare und CPUQuota sich die Performance der Datenübertragung reduziert wenn es sich um "große Mengen" von Daten handelt.
Der Sinn den $MS in diesem Vorgehen sieht ist die gerechte Verteilung der Ressourcen.
Das bedeutet, dass nicht ein Client beim Öffnen einer großen Tabelle für alle anderen den Netzwerkverkehr ausbremst.
Bei filebassierten Systemen wie Xbase, VFP, Access wirkt sich das natürlich entsprechend aus, bei SQL-Server macht es weniger aus weil diese Systeme ja genau davon "leben" nur wenige Daten übers Netz zu ziehen.
Hier was zum nachlesen:
http://www.gerjon.com/citrix/xenappxend ... databases/
Das weiß ich nicht.ist das nicht für Remote Desktop ?"EnableFairShare"
"EnableCPUQuota"
Es wurde berichtet, dass durch FairShare und CPUQuota sich die Performance der Datenübertragung reduziert wenn es sich um "große Mengen" von Daten handelt.
Der Sinn den $MS in diesem Vorgehen sieht ist die gerechte Verteilung der Ressourcen.
Das bedeutet, dass nicht ein Client beim Öffnen einer großen Tabelle für alle anderen den Netzwerkverkehr ausbremst.
Bei filebassierten Systemen wie Xbase, VFP, Access wirkt sich das natürlich entsprechend aus, bei SQL-Server macht es weniger aus weil diese Systeme ja genau davon "leben" nur wenige Daten übers Netz zu ziehen.
Hier was zum nachlesen:
http://www.gerjon.com/citrix/xenappxend ... databases/
--
Hans-Peter
Hans-Peter
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Performance mit Windows Server 2016
Eine geshared geöffnete DBF dürfte eigentlich keine "große Datei" sein, da ja immer nur 512 Byte buffer genutzt werden und beim Sperren sogar nur Bytes gesetzt werden.
Hier ist es eher die Anzahl der Zugriffe und die offenen filehandles die Last verursachen - insbesondere wenn man ohne Index sucht und die ganze Datei durch muss.
Aus diesem Grunde, könnte ein "faires Zugreifen" Vorteile bringen, allerdings weiß der Xbase++ Treiber davon nichts, genauso wenig wie er mit den anderen neuen share Methoden umgehen kann,
sonst bräuchten wir keine solchen Tricks um die neuen Caches abzustellen, zumindest sagt das Jimmy immer - ich bin kein MS Server Experte.
Ich bin mir aber sicher, dass die Probleme die mit Server 2008 kamen nicht weniger sondern mehr werden, solange man "legacy file based" Datenbankprogramme nutzt.
M$ sieht das (wie auch Foxpro oder MS Access) als veraltet an und kümmert sich wenig darum hier schnelle und sichere gesharte Dateien zu haben,
"nutzt MsSQL Server" lautet schon seit Jahren der Tenor, ob es uns oder Alaska gefällt interessiert M$ nicht.
Aber laut der Dokumentation von SQLite sind auch die anderen Dateisysteme (Linux basiert) nicht (viel) besser, dort steht eindeutig, dass keines fehlerfrei arbeitet und daher SQLite nicht geshared im Netzwerk verwendet werden soll.
Hier ist es eher die Anzahl der Zugriffe und die offenen filehandles die Last verursachen - insbesondere wenn man ohne Index sucht und die ganze Datei durch muss.
Aus diesem Grunde, könnte ein "faires Zugreifen" Vorteile bringen, allerdings weiß der Xbase++ Treiber davon nichts, genauso wenig wie er mit den anderen neuen share Methoden umgehen kann,
sonst bräuchten wir keine solchen Tricks um die neuen Caches abzustellen, zumindest sagt das Jimmy immer - ich bin kein MS Server Experte.
Ich bin mir aber sicher, dass die Probleme die mit Server 2008 kamen nicht weniger sondern mehr werden, solange man "legacy file based" Datenbankprogramme nutzt.
M$ sieht das (wie auch Foxpro oder MS Access) als veraltet an und kümmert sich wenig darum hier schnelle und sichere gesharte Dateien zu haben,
"nutzt MsSQL Server" lautet schon seit Jahren der Tenor, ob es uns oder Alaska gefällt interessiert M$ nicht.
Aber laut der Dokumentation von SQLite sind auch die anderen Dateisysteme (Linux basiert) nicht (viel) besser, dort steht eindeutig, dass keines fehlerfrei arbeitet und daher SQLite nicht geshared im Netzwerk verwendet werden soll.
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Performance mit Windows Server 2016
Als Lösung für DBF Dateien bietet sich noch ADS an. Dieser löst die Netzwerk-Probleme mit DBF/NTX Dateien.
Cu Carlo
Da es M$ nicht interessiert hilft: FreeBSD ....Ich bin mir aber sicher, dass die Probleme die mit Server 2008 kamen nicht weniger sondern mehr werden, solange man "legacy file based" Datenbankprogramme nutzt.
M$ sieht das (wie auch Foxpro oder MS Access) als veraltet an und kümmert sich wenig darum hier schnelle und sichere gesharte Dateien zu haben,
"nutzt MsSQL Server" lautet schon seit Jahren der Tenor, ob es uns oder Alaska gefällt interessiert M$ nicht.
Cu Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: Performance mit Windows Server 2016
Hallo Zusammen !
Ich habe gerade mit CommView (Netzwerk-Sniffer) ein paar Tests gemacht.
Dabei habe ich meinen Desktop mit dem Notebook verbunden (Beides W10 X64).
Folgendes habe ich (mit VFP) für eine DBF mit 150 MB, CDX mit 12 MB und FPF mit 10 MB festgestellt:
- USE auf Tabelle => es rauschen gleich mal 0,9 MB in 590 SMPOverTCP-Paketen mit 1506 Bytes übers Netz. Man kann die Daten darin sehen.
- Bei einem anschließenden BROWSE sind es beim SKIPen je Seite mit 48 angezeigten Datensätzen (ergibt 21648 Bytes) 15 SMPOverTCP-Pakete mit 1506 Bytes => 22590 Bytes.
Anmerkung: Die 1506 Bytes ist die MTU-Size des Netzwerk-Karten-Treibers (1492) + 14 Bytes .
Für mich ergibt sich daraus, dass beim Öffnen einer Tabelle nicht unwesentlich Daten übers Netz rauschen.
Wenn ein Programm dann zb. beim Starten gleich mal alle Tabellen öffnet, dann ist das nicht gerade eine unerhebliche Datenmenge.
Ich habe gerade mit CommView (Netzwerk-Sniffer) ein paar Tests gemacht.
Dabei habe ich meinen Desktop mit dem Notebook verbunden (Beides W10 X64).
Folgendes habe ich (mit VFP) für eine DBF mit 150 MB, CDX mit 12 MB und FPF mit 10 MB festgestellt:
- USE auf Tabelle => es rauschen gleich mal 0,9 MB in 590 SMPOverTCP-Paketen mit 1506 Bytes übers Netz. Man kann die Daten darin sehen.
- Bei einem anschließenden BROWSE sind es beim SKIPen je Seite mit 48 angezeigten Datensätzen (ergibt 21648 Bytes) 15 SMPOverTCP-Pakete mit 1506 Bytes => 22590 Bytes.
Anmerkung: Die 1506 Bytes ist die MTU-Size des Netzwerk-Karten-Treibers (1492) + 14 Bytes .
Für mich ergibt sich daraus, dass beim Öffnen einer Tabelle nicht unwesentlich Daten übers Netz rauschen.
Wenn ein Programm dann zb. beim Starten gleich mal alle Tabellen öffnet, dann ist das nicht gerade eine unerhebliche Datenmenge.
--
Hans-Peter
Hans-Peter
Re: Performance mit Windows Server 2016
Hallo Klaus
einen Server mit MS Server 2016 habe ich jetzt erst für einen Kunden bestellt.
Kann mich aber erinnern, dass ich beim Wechsel von Server 2003 auf 2008 Probleme hatte. Mit und ohne ADS.
Einer der Gründe für die Probleme war, dass ich den Zugriff auf die Netzwerklaufwerke noch nicht auf UNC umgestellt hatte. Meine Programme hatten u.a. Probleme mit der Aktualisierung von Verzeichnissen in welche gerade neue Dateien geschrieben wurden. Die Dateien waren einfach nicht da - manchmal erst nach Minuten. Damals hatte ich auch mit SMB und anderen Dingen herumprobiert - an manchen Plätzen hatte es geholfen.
Viele Arbeitsplätze hatten noch XP - nach dem Upgrade fast aller PCs auf Win 7 - inzwischen Win 10 gab es keine derartigen Probleme mehr. Musste also schon lange nicht mehr wegen meiner Xbase++-Programme an den Systemeinstellungen der Server oder PCs in der Registry usw. rumschrauben.
Hoffentlich ändert sich das nicht wieder mit Server 2016...
einen Server mit MS Server 2016 habe ich jetzt erst für einen Kunden bestellt.
Kann mich aber erinnern, dass ich beim Wechsel von Server 2003 auf 2008 Probleme hatte. Mit und ohne ADS.
Einer der Gründe für die Probleme war, dass ich den Zugriff auf die Netzwerklaufwerke noch nicht auf UNC umgestellt hatte. Meine Programme hatten u.a. Probleme mit der Aktualisierung von Verzeichnissen in welche gerade neue Dateien geschrieben wurden. Die Dateien waren einfach nicht da - manchmal erst nach Minuten. Damals hatte ich auch mit SMB und anderen Dingen herumprobiert - an manchen Plätzen hatte es geholfen.
Viele Arbeitsplätze hatten noch XP - nach dem Upgrade fast aller PCs auf Win 7 - inzwischen Win 10 gab es keine derartigen Probleme mehr. Musste also schon lange nicht mehr wegen meiner Xbase++-Programme an den Systemeinstellungen der Server oder PCs in der Registry usw. rumschrauben.
Hoffentlich ändert sich das nicht wieder mit Server 2016...
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Performance mit Windows Server 2016
Auf jeden Fall ist es hilfreich, die Netz-Laufwerke nicht einem Laufwerksbuchstaben zuzuordnen sondern die Dateien mit UNC zu öffnen.
1. Laut Jimmy gibt es dann viele "alte Probleme" nicht mehr, obwohl bei mir die SMB2 Einstellungen dennoch nötig wurden !
2. Kann keiner mehr einfach mit dem Explorer auf dem Netzwerklaufwerk herum stochern.
1. Laut Jimmy gibt es dann viele "alte Probleme" nicht mehr, obwohl bei mir die SMB2 Einstellungen dennoch nötig wurden !
2. Kann keiner mehr einfach mit dem Explorer auf dem Netzwerklaufwerk herum stochern.
Gruß
Hubert
Hubert
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: Performance mit Windows Server 2016
Hallo Zusammen !
Nochmals weiter getestet:
Verbindung per UNC:
- USE => 525 Pakete mit 741850 Bytes
Notebook neu gestartet
Verbindung per LW-Buchstaben:
- USE => 525 Pakete mit 710761 Bytes
Protokoll war SMBOverTCP, dazwischen Pakete mit SMB:2 R READ
Start-Port 445 Microsoft-DS SMB-Freigaben, Ziel-Port 55784
Nochmals weiter getestet:
Verbindung per UNC:
- USE => 525 Pakete mit 741850 Bytes
Notebook neu gestartet
Verbindung per LW-Buchstaben:
- USE => 525 Pakete mit 710761 Bytes
Protokoll war SMBOverTCP, dazwischen Pakete mit SMB:2 R READ
Start-Port 445 Microsoft-DS SMB-Freigaben, Ziel-Port 55784
--
Hans-Peter
Hans-Peter
- Koverhage
- Der Entwickler von "Deep Thought"
- Beiträge: 2471
- Registriert: Fr, 23. Dez 2005 8:00
- Wohnort: Aalen
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Performance mit Windows Server 2016
Hallo Hubert,
Ich verwende das Alaska Sample XMGVIEW.PRG, mit einem zugewiesenen LW-Buchstaben funktioniert es, ohne nicht die Anwendung hängt sich auf.
Ansonsten gibt es meines Wissens in der Anwendung keine Probleme wenn mit UNC gearbeitet wird.
Die Kunden rufen immer dann an, wenn das Programm im IMGVIEW Modul hängt.
Dateien zu kopieren.
Aber, wer Interesse hat mein angepasstes IMGVIEW zu ändern, damit es mit UNC Laufwerken funktioniert, kann mir eine PN schicken
(bitte mit Vergütungswünsche ). Ich schicke dann den Quellcode.
Kannst Du das belegen ?Auf jeden Fall ist es hilfreich, die Netz-Laufwerke nicht einem Laufwerksbuchstaben zuzuordnen sondern die Dateien mit UNC zu öffnen.
Ich verwende das Alaska Sample XMGVIEW.PRG, mit einem zugewiesenen LW-Buchstaben funktioniert es, ohne nicht die Anwendung hängt sich auf.
Ansonsten gibt es meines Wissens in der Anwendung keine Probleme wenn mit UNC gearbeitet wird.
Die Kunden rufen immer dann an, wenn das Programm im IMGVIEW Modul hängt.
Hilft auch nicht, da ich keine Dateien direkt auf ein Android Handy/Tablet senden kann. Also muss der Anwender das Laufwerk öffnen können, um dieKann keiner mehr einfach mit dem Explorer auf dem Netzwerklaufwerk herum stochern.
Dateien zu kopieren.
Aber, wer Interesse hat mein angepasstes IMGVIEW zu ändern, damit es mit UNC Laufwerken funktioniert, kann mir eine PN schicken
(bitte mit Vergütungswünsche ). Ich schicke dann den Quellcode.
Gruß
Klaus
Klaus
Re: Performance mit Windows Server 2016
Hallo Klaus
Ich verwende eine Umschlüsselungs-Tabelle (per INI) welche dazu diehnt, die beim jeweiligen Kunden verwendeten Namen der Netzwerklaufwerke anzupassen. Bsp.:
APP_DriveMap = K => \\FS1\VERWALTUNG
APP_DriveMap = L => \\FS2\DOKUMENTE
usw.
ADS_Host = FS1
ADS_IP = 172.2.5.11
Damit ersetze/bereinige ich vor jedem USE den Pfad im Dateinamen. Da ich (fast) alle USE zentral über ein Modul steuere war die Umstellung nicht aufwendig.
Für ADS wird dann noch zusätzlich der Server-Name (im Bsp. FS1) durch die IP-Adresse ersetzt.
K:\XB\FIBU123.DBF => \\FS1\VERWALTUNG\XB\FIBU123.DBF => \\172.2.5.11\VERWALTUNG\XB\FIBU123.DBF
Damit kann ich und der User weiterhin Laufwerksbuchstaben verwenden und ich musste nicht alle INI-Dateien der Benutzer ändern.
Der Hinweis, Netzlaufwerke besser auf UNC zu ändern kam bei mir damals vom Alaska-Support welchen ich wegen der Programmprobleme kontaktiert hatte.Kannst Du das belegen ?
Ich verwende eine Umschlüsselungs-Tabelle (per INI) welche dazu diehnt, die beim jeweiligen Kunden verwendeten Namen der Netzwerklaufwerke anzupassen. Bsp.:
APP_DriveMap = K => \\FS1\VERWALTUNG
APP_DriveMap = L => \\FS2\DOKUMENTE
usw.
ADS_Host = FS1
ADS_IP = 172.2.5.11
Damit ersetze/bereinige ich vor jedem USE den Pfad im Dateinamen. Da ich (fast) alle USE zentral über ein Modul steuere war die Umstellung nicht aufwendig.
Für ADS wird dann noch zusätzlich der Server-Name (im Bsp. FS1) durch die IP-Adresse ersetzt.
K:\XB\FIBU123.DBF => \\FS1\VERWALTUNG\XB\FIBU123.DBF => \\172.2.5.11\VERWALTUNG\XB\FIBU123.DBF
Damit kann ich und der User weiterhin Laufwerksbuchstaben verwenden und ich musste nicht alle INI-Dateien der Benutzer ändern.
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2950
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 14 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Performance mit Windows Server 2016
Um eventuellen Verbindungsproblemen zum ADS zu begegnen, würde ich noch den Port hinter die IP-Adresse setzen:
\\172.2.5.11:6262\VERWALTUNG\XB\FIBU123.DBF
Viele Grüße
Wolfgang
Wolfgang
Re: Performance mit Windows Server 2016
Hallo Wolfgang
den Port verwende ich bisher nur im "connection string".
Wusste gar nicht dass man den Port zusätzlich auch in den Dateipfad packen kann. Man lernt nie aus...
den Port verwende ich bisher nur im "connection string".
Wusste gar nicht dass man den Port zusätzlich auch in den Dateipfad packen kann. Man lernt nie aus...
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: Performance mit Windows Server 2016
Da hätte ich noch eine Verständnisfrage zum ADS:
Der ADS verwaltet die DBF-Tabellen doch selbst wie ein SQL-Server?
Wozu muß man beim Vorhandensein einer Connection noch einen kompletten Pfad angeben?
Reicht da der Tabellen-Name (wie beim MS-SQL) nicht aus?
Der ADS verwaltet die DBF-Tabellen doch selbst wie ein SQL-Server?
Wozu muß man beim Vorhandensein einer Connection noch einen kompletten Pfad angeben?
Reicht da der Tabellen-Name (wie beim MS-SQL) nicht aus?
--
Hans-Peter
Hans-Peter
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Performance mit Windows Server 2016
hast du beim Kunden ein Problem oder wir ?Koverhage hat geschrieben:Kannst Du das belegen ?
wir können dir nur mitteilen wie wir das Problem angegangen sind und was bei uns geholfen hat.
einen "alle_Probleme_Aus_Schalter" gibt es nicht denn das ist eben von vielen anderen Faktoren abhängig.
meistens traten die (neuen) Probleme bei Umstieg auf eine neue Windows OS() Version auf wo man handeln musste.
nur einen neuen M$ Server kauft reicht IMHO nicht, es müssen auch die Workstationen das entsprechende OS() haben.
---
bei Windows NT wurden wir mit SMB1 konfrontiert was sich auf unsere Cl*pper Programme auswirkte wenn die DBF auf dem NT Server lagen. was vielleicht weniger Leute mitbekommen haben war wie sich die damaligen Word / Excel Dateien auf einem Novell Server verhielten.
es ist so das Microsoft nicht nur den Server weiter entwickelt sondern auch ihre Client Produkte und "die" benötigen Erweiterungen.
die Word / Excel Dateien benötigten (!) den Windows NT SMB1 Mechanismus welchen der Novell Server damals nicht kannte -> langes warten.
aber auch die Linux Welt, wo es ja CFS gab, brauchte einige Zeit bis man das Windows SMB1 Format voll unterstützt hat.
dito. war die Entwicklung mit SMB2 den die aktuellen Linux Distributionen inzwischen unterstützen. mit SMB3x wird es wohl noch ein wenig dauern.
all diese Änderungen wirken sich natürlich auch "irgendwie" auf unsere Programme aus so das diese ständig angepasst werden müssen.
ich versuche solche Problem schon während der "beta" Phase eines neuen M$ Produkt zu erkennen und kann dann "zu dem Zeitpunkt" meine Fragen stellen.
obwohl es heisst das Internet vergisst nichts ist es oft schwierig nach Jahren etwas wieder zu finden.
die gilt besonders für MSDN Beiträge deren Links ins nichts bei M$ führen.
hier im Forum wirst du solche Beiträge zum SMB2 von mir noch finden.
auch Demos (Source) habe ich gemacht womit du es selbst testen kannst.
UNC Path Zugriff hat man nur auf freigegebene Ordner !!!Koverhage hat geschrieben:Ich verwende das Alaska Sample XMGVIEW.PRG, mit einem zugewiesenen LW-Buchstaben funktioniert es, ohne nicht die Anwendung hängt sich auf.
em, äh ... sind wir noch beim selben Thema ?Koverhage hat geschrieben:Hilft auch nicht, da ich keine Dateien direkt auf ein Android Handy/Tablet senden kann. Also muss der Anwender das Laufwerk öffnen können, um die Dateien zu kopieren.
wenn nein bitte neuen Thread aufmachen.
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Performance mit Windows Server 2016
das "umschreiben" von Laufwerksbuchstaben auf UNC Path betraf bei mir nur die SETUP.DBFbrandelh hat geschrieben:Auf jeden Fall ist es hilfreich, die Netz-Laufwerke nicht einem Laufwerksbuchstaben zuzuordnen sondern die Dateien mit UNC zu öffnen.
meine DBF und Index Dateien werden schon seit Jahren alle in der NET_USE() Functionen geöffnet
wie schon gesagt kann sich das unterschiedlich stark auswirken.brandelh hat geschrieben:1. Laut Jimmy gibt es dann viele "alte Probleme" nicht mehr, obwohl bei mir die SMB2 Einstellungen dennoch nötig wurden !
Power User reizen ein System eher aus und stossen eher an solche (Timeing) Problem.
ob die 3 x SMB2 Einstellungen von Alaska überhaupt das Problem von Klaus sind hat er uns ja noch gar nicht mitgeteilt
... vielleicht ist er ja erst am Anfang der Geschichte.
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Performance mit Windows Server 2016
interessant ...HaPe hat geschrieben:Ich habe gerade mit CommView (Netzwerk-Sniffer) ein paar Tests gemacht.
...
Folgendes habe ich (mit VFP) für eine DBF mit 150 MB, CDX mit 12 MB und FPF mit 10 MB festgestellt:
könntest du es bitte auch mal mit einer Xbase++ App versuchen ... und wenn du hast mit DBU.EXE oder einer anderen Cl*pper App als Vergleich.
gruss by OHR
Jimmy
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Performance mit Windows Server 2016
Wenn du z.B. ein lokales Programm auf Laufwerksbuchstaben programmierst, bist du abhängig von der lokalen Belegung ...Koverhage hat geschrieben:Hallo Hubert,Kannst Du das belegen ?Auf jeden Fall ist es hilfreich, die Netz-Laufwerke nicht einem Laufwerksbuchstaben zuzuordnen sondern die Dateien mit UNC zu öffnen.
ein USB Laufwerk dazu und der Buchstabe könnte weg sein, oder auch viele Freigaben und die 26 Buchstaben werden eng.
Als ich noch im Benutzerservice war hatten wir recht schnell Probleme mit der Verwendung fixer Laufwerkszuordnungen.
Ansonsten habe ich das irgendwo gelesen und Jimmy hat es oft erklärt.
Du kannst natürlich für Austauschzwecke ein Laufwerksbuchstabe mit einem eigenen Verzeichnis verwenden.Koverhage hat geschrieben:Hilft auch nicht, da ich keine Dateien direkt auf ein Android Handy/Tablet senden kann.Kann keiner mehr einfach mit dem Explorer auf dem Netzwerklaufwerk herum stochern.
Also muss der Anwender das Laufwerk öffnen können, um die Dateien zu kopieren.
Keinesfalls ist es sinnvoll, dass jeder normale Anwender mit dem Explorer auf das Anwendungs- / Datenverzeichnis Zugriff hat.
solche Probleme treten meist auf, wenn im Programm versucht wird den kompletten Pfad zu erzeugen.Koverhage hat geschrieben: Ich verwende das Alaska Sample XMGVIEW.PRG, mit einem zugewiesenen LW-Buchstaben funktioniert es, ohne nicht die Anwendung hängt sich auf.
Ansonsten gibt es meines Wissens in der Anwendung keine Probleme wenn mit UNC gearbeitet wird.
Die Kunden rufen immer dann an, wenn das Programm im IMGVIEW Modul hängt.
Aber, wer Interesse hat mein angepasstes IMGVIEW zu ändern, damit es mit UNC Laufwerken funktioniert, kann mir eine PN schicken
(bitte mit Vergütungswünsche ). Ich schicke dann den Quellcode.
Die meisten Programme verwenden dann die Laufwerksbuchstabensyntax und vergessen UNC.
Gruß
Hubert
Hubert
- Herbert
- Der Entwickler von "Deep Thought"
- Beiträge: 1991
- Registriert: Do, 14. Aug 2008 0:22
- Wohnort: Gmunden am Traunsee, Österreich
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Performance mit Windows Server 2016
Hubert, das kann kein Grund sein... Auch UNC- wechseln mal, Kunden haben hin und wieder Ideen oder wechseln irgendwann mal einen Server aus.brandelh hat geschrieben: Wenn du z.B. ein lokales Programm auf Laufwerksbuchstaben programmierst, bist du abhängig von der lokalen Belegung ...
ein USB Laufwerk dazu und der Buchstabe könnte weg sein, oder auch viele Freigaben und die 26 Buchstaben werden eng.
Als ich noch im Benutzerservice war hatten wir recht schnell Probleme mit der Verwendung fixer Laufwerkszuordnungen.
Auf die Performance wird das keinen bedeutenden Einfluss haben.
Wichtig für solche Dinge ist einzig, die Pfad-Definitionen irgendwo im Programm für berechtigte Personen festlegbar zu machen.
Grüsse Herbert
Immer in Bewegung...
Immer in Bewegung...