NAS Geschwindigkeitsproblem

[Daniel]

So weit ich weiss, setzt man NAS vor allem als Backup und für grosse Media-Dateien ein.
Dafür verwende ich es jedenfalls (v.a. ersteres). Ich wäre nie auf die Idee gekommen, damit einen Netzwerkserver zu ersetzen.
Aber vielleicht irre ich mich und sehe nicht die Einsatzmöglichkeiten.

[brandelh]

Ein kleiner Betrieb ohne speziellen Server-Admin ist mit einem NAS gut bedient, so sehe ich das.

[ramses]

Hi

bist du dir wirklich sicher dass es nicht vom Antivirus Programm kommt? Hast du dieses mal komplett dekativiert und dann getestet? (Ausnahmen nutzen bei einigen Produkten nichts)

Cu Carlo

[Rudolf]

Hallo,
es ist eine kleine Firma mit ein paar Workstations, da ist so ein NAS sicher eine gute Alternative zu einem eigenen Server. Falls die Tests auf einem anderen NAS Server nichts neues bringen, werde ich dem Kunden mal empfehlen den Antivirus komplett zu disablen, es war ja auch mein erster Gedanke. Aber angeblich wurde vom Netzwerkbetreuer (ist ein Profi) alles berücksichtigt.
Grüsse
Rudolf

[brandelh]

Aber angeblich wurde vom Netzwerkbetreuer (ist ein Profi) alles berücksichtigt.

Ein Mensch der alles kann ... kann er denn wissen, was dein Programm braucht

[Rudolf]

Hallo,
auf www.ct-pen.com/download/speed.zip ist das Testprogramm inkl. Source, jetzt bin ich aber wirklich gespannt
Grüsse
Rudolf

[brandelh]

Hi,

so wie ich das sehe ist dies hier das Auswertungsprogramm, eine Speicherung der Durchschnittswerte ist nicht vorgesehen.
Ich sehe die Arrays an und sehe nach ob es länger als 1 Sekunde dauert:

Code: Alles auswählen

FUNCTION Main()
******************************************************************
local x,cTmp
private aTime := {}
for x := 1 to 100
     cTmp := dccc_iniread(APPINI,"DESKTOP","SCREEN")
next x
dc_arrayview(aTime)
return .t.

Es wird 100 x der gleiche Schlüssel gelesen, wobei die dccc_ ... Funktion 4 Werte speichert: VOR TxtOpen, NACH TxtOpen, NACH Suche, NACH CLOSE.
Ich weiß jetzt nicht, wie effizient DC_TxtLine() hier arbeitet, aber die Funktion ist recht umfangreich und auf jeden Fall besser durch eine API Funktion zu ersetzten,
da diese intern in C und sicher auch optimiert arbeitet.

Hier nun meine Ergebnisse - jeweils für den gesamten Durchlauf - (EXE und DLL liegen im Verzeichnis mit INI) :
DS411slim - 2 x 1000 GB 2.5" Festplatten im Raid1 Verbund, keine Verschlüsselung, GigaBit-Anschluß
Terra Station Pro - 1 oder 2 GB Hauptspeicher, 4x 250 GB im Raid 5, keine Verschlüsselung, GigaBit-Anschluß
Server - Windows XP Pro - SP3, 2 GB Hauptspeicher, 320 GB 2.5" Platte (Atom Doppelkern Netbox ...)

Code: Alles auswählen

Rechner 1: XP-SP3, Amd X2 Prozessor, 2 GB Ram, GigaBit Netzwerk, 3 Com Switch., keine Änderungen am Virenscanner.
Lokal auf D:                  unter 1 Sek. - OK
\\NAS\...\          =>        Keine Ergebnisse auf UNC Pfad. Scheint nicht zu funktionieren ohne Laufwerksbuchstabe.
DS411slim auf N:              2 Sekunden -> zwischen Schritt 2 und Schritt 3 wird jeweils 0.02 bis 0.03 Sekunden benötigt.
Terra Station Pro auf O:      2 Sekunden -> zwischen Schritt 2 und Schritt 3 wird jeweils 0.02 bis 0.03 Sekunden benötigt.
Server auf P:                 etwas unter 2 Sekunden -> zwischen Schritt 2 und Schritt 3 wird jeweils 0.01 bis 0.02 Sekunden benötigt.

Nun der Härtetest. Vom Rechner wird die D: Platte per robocopy (ähnlich XCOPY) gleichzeitig auf beide NAS kopiert.
Beide Prozessoren haben nun jeweils 40 bis 50% Systemlast, Netzwerklast bei 10% - robocopy nutzt also die Bandbreite des PC nicht voll aus.
Das DS411slim hat einen Resourcenmonitor, 40% CPU Last - bei zwei Rechnern wäre diese etwa 60% geteilt durch die Anzahl der PC (alle teilen sich den Wert).

Trotz dieser Belastung wird der gesamte Einlesevorgang in 7 bis 9 Sekunden erledigt.

Insgesamt kein Grund zum Jammern. Heute Abend werde ich im Heimnetz noch testen.
Und die API Version liefere ich auch noch nach

[Rudolf]

Hallo Hubert,
vielen Dank für den detaillierten Test, bei mir lokal dauert der ganze Testdurchlauf 0,05 Sekunden, also deutlich weniger. Habe einen Laptop im Netzwerk und lese das INI File auch von dort, da dauert es 1 Sekunde. Zwar doppelt so lange, aber immer noch wesentlich schneller. Beim Kunden dauert das Lesen von 100 Einträgen über 12 Sekunden, also 12 mal so lange.
Bin mal gespannt auf die API Funktionen bei Dir was bringen.
Grüsse
Rudolf

[brandelh]

Hallo,

hier ist meine Umsetzung (fertig.cmd kompiliert, einmal mit API: TEST_API.PRG, einmal mit meiner alten Funktion mit MemoRead()):

HB_speed.zip

(3.97 KiB) 211-mal heruntergeladen

Aktuell läuft noch der Belastungstest, daher die Werte unter Last, die ohne Last dürften dann wesentlich niedriger liegen
Ich habe mehrfach die EXE gestartet um zu sehen ob Unterschiede bei der Last zu Änderungen führen, das kommt vor ist aber eher selten.

N: API und ALT benötigen zwischen 1 Sekunde und 2 Sekunden.
O: API 1 bis 3, ALT 2 bis 4 Sekunden. Ausreißer bis 6 Sekunden.
P: unter 1 Sekunde
lokal unter 0.10 Sekunden

wie gesagt, trotz zwei Kopiervorgängen im Hintergrund die etwa 1 Stunde benötigen.

[Rudolf]

Hallo Hubert,
danke für das Testprogramm, was bedeutet N, O und P ? Ich hab es mal hier lokal und mit Laptop getestet:

Test lokal
mit dc_iniread() 0,06 Sek.
mit API 0,04 Sek.
HB_ALT 0,02 Sek.


Test netzwerklaufwerk laptop:
mit dc_iniread() 0,10 Sek.
mit API 0,06 Sek.
HB_ALT 2,15 Sek.

Grüße
Rudolf

[brandelh]

N; o: und P: sind die weiter oben erwähnten Laufwerksbuchstaben.

Die ALT Funktion mit memoread dürfte immer dann Vorteile haben, wenn viele Lesezugriffe erfolgen.
Allerdings hat die Funktion ein prinzipielles Problem mit Parametern die Blanks enthalten und nicht durch die alte SETINI Funktion geschrieben wurden.
Diese ersetz die Blanks in Pfaden oder Druckernamen beim Speichern in chr(255) und wandelt diese beim Lesen zurück.

Die API Funktion ruft die Windows API auf und müsste immer sauber funktionieren !

[Herbert]

Hubert, genial, wie du hier mithilfst. Ganz "öffentlich" hier: Danke!

Und zeigt auch auf, dass nciht für alles eine Klasse herhalten muss, sondern ganz normale Funktionen mehr als genügen.

[brandelh]

Hi,

wenn die LAST weg ist, liefern beide Funktionen sehr ähnliche Ergebnisse, wobei der erste Aufruf von der API Funktion immer etwas länger dauert,
danach bleibt er im Cache (vermutlich) ... lokal bleibt es bei unter 0.05 Sekunden, auf dem "XP-Server" bleibt es bei 0.3 Sekunden egal wie man abfragt.
Auf den NAS Geräten ist die API mit durchschnittlich 0.5 Sekunden schneller als die "Alte" mit 0.8 Sekunden.

Lokal kann man offensichtlich machen was man will, aber gerade wenn die Netzwerkbremsen wirken ist halt der Aufruf der API Funktionen,
die in C/C++ geschrieben sind, wesentlich schneller als in Xbase++ Code nach dem Inhalt zu suchen.
Sicherer ist es auch, denn in meinen API Funktionen prüfe ich nach Ansi/OEM etc. und man kann auch gleich den Rückgabedatentyp festlegen

[Rudolf]

Hallo,
dem kann ich mich nur anschließen, vielen Dank! alleine könnte ich das nie so testen.
Habe noch eine letzte Bitte, habe das Testprogramm nochmal auf meinen Server geladen, jetzt kann man im test.ini das INI File ändern. Wäre noch interessant wie viel langsamer Rogers Funktionen im Vergleich zu den anderen sind. Dann kann ich dem Kunden gegenüber besser argumentieren, da es ein direkter Vergleich zwischen verschiedenen NAS ist.
Grüsse
Rudolf

[brandelh]

Hallo,

so nun der Test zu Hause 3 GHZ X2 Athlon, Win 7 Ultimate, gigabit Netz, NAS = Synology DS411slim (2 x 1TB 2.5" WD Platten), lokal 750 GB WD 2.5"

Speicherort, Zeit mit deiner Test.EXE ; Meine API ; Meine Alte ... in Sekunden.

lokal 0,07 ; 0,03 ; 0,02 (erster API Aufruf 0.04)
UNC-NAS geht nicht ; 0,57 ; 0,77
NAS auf S: 3,14 ; 0,57 ; 0,77
PC2 auf S: 0,09 ; 0,04 ; 0,02 ( X4 Phenom mit je 3 GHZ, 12 GB - Windows 7 Home Premium)

offensichtlich ist ein PC schneller, aber mit den API Funktionen ist alles OK.
PS: EXE, Express DLL und INI im gleichen Verzeichnis.

[Rudolf]

Hallo Hubert,
vielen Dank ! der Test ist schon sehr anschaulich. Sieht aus als ob NAS grundsätzlich bei Textfiles einiges langsamer ist, ich befürchte die Ursache werden wir nie genau rausfinden. Beim Kunden hat das Lesen der 100 Einträge 12 Sek. gedauert, also 4 mal so lange wie bei Dir, da kann was nicht stimmen. Auch wenn die dc_ini Funktionen ein wenig langsamer als die API Funktionen sind, aber sie können nicht die Ursache für das Problem beim Kunden sein, und diese Erkenntnis ist mir am wichtigsten.
Nochmals vielen Dank
Grüße
Rudolf

[brandelh]

Ich würde auf die API umstellen UND der Kunde muss prüfen warum es bei ihm diese Verzögerung gibt.
Eine Möglichkeit sind Virenscanner, eine andere die komplette Verschlüsselung der Platten.
Wie geschrieben, hat dein Kunde ein TOP NAS, dieses müsste selbst bei Verschlüsselung deutlich schneller sein als meines.
Mit der Hardware eines Atom (Doppelkern ?) müsste das NAS loker an die Werte meines kleinen Büro-Servers kommen.

Ich würde zunächst das NAS direkt mit einem Computer verbinden und die Werte testen.
Wenn OK, dann einzelne Netzwerkstrecken überbrücken etc.
Natürlich muss man auch sehen, was der sonst noch zu tun hat.
Wenn z.B. ein Netzwerkdrucker angeschlosssen ist und da pausenlos Briefe mit Bildern gedruckt würden, würde allein
das schon das Netz belasten.
Wie schnell kopiert er eigentlich eine große Datei (Windows 7 zeigt das unter erweitert an, ansonsten stoppen und Byte / Sekunden teilen).
Was macht er mit mehreren kleineren ?

[Rudolf]

Hallo Hubert,
danke für die Infos, ich habe für den Netzwerkbetreuer jetzt ein kleines Testprogramm gemacht damit er auch auf anderen NAS die Geschwindigkeit testen kann. Er hat die Performance mit Wireshark geprüft und teileweise bis zu 1.5 Sekunden für das Lesens eines Eintrags im INI File gemessen. Ich glaube das ist wo weit daneben, dass es nicht mit einfachen Einstellungen behoben werden kann. Da muss was anderes dran Schuld sein, mal schauen was seine Tests an Erkenntnissen bringen.
Grüsse
Rudolf