Hallo,
ich habe den NM auf einer NAS (Buffalo Terrastation 1TB) zentral in einem Ordner, auf den alle Kollegen Zugriff haben. In dem Ordner befindet sich sowohl das Programm als auch die Datei mn04. Das Netz ist ein 100 Mbit-Ethernet LAN. Wir haben vier Eingabegeräte, von den aus man den NM bedienen kann. Auf den vier Geräten hatte ich zu Beginn den NM installiert, damit die dll usw. vorhanden sind. Gestartet wird der NM allerdings durch eine Verknüpfung mit dem Programm auf der NAS.
Seit den letzten drei Updates kommt es mir so vor, als ob der NM immer langsamer auf Eingaben reagiert. Der Aufbau einer Maske und das Füllen mit Daten aud der DB dauert ewig, selbst wenn ich ganz allein im Netz bin! Besonders langsam ist er, wenn neue Daten aus der DBank geholt werden müssen. Selbst der Anmeldevorgang ist unerträglich. Oft weiß man nicht ob ein Programmabsturz erfolgt ist.
Muss ich auf den Clients auch etwas nachinstallieren?
Hast Du schon mal die ganzen Reparaturoptionen ausprobiert? Also "Datenbank komprimieren" oder "Datenbank reorganisieren" oder "Datenbank reparieren"...?
Das mit dem Reparieren habe ich jetzt probiert, kann aber kaum einen Unterschied feststellen. Das ganze wirkt als ob jemand die Handbremse angezogen hätte.
bei uns verzeichnen wir immer einen spürbaren Geschwindigkeitsverlust, wenn unser Schulleiter mit seinem leistungsschwachen Rechner als 'xs'-Benutzer im Notenmanager zugange ist. Dann kann man an allen anderen NM-Clients, obwohl diese Rechner wesentlich leistungsfähiger sind, im Notenmanager nur noch im Zeitlupentempo navigieren und Daten eingeben. Meldet sich der Chef als 'xs'-Benutzer aber ab, so 'flutscht' der NM wieder bei allen Clients. Ich nehme an, das der 'xs'-Benutzer, da der ja oft Ãœbersicht-Informationen zu mehreren Klassen holt, in der Access-Datenbank viele Sperren zu vielen Datensätzen in viele Tabellen produziert und so das Gesamtsystem verlangsamt.
Ich habe unserem Schulleiter mitgeteilt, dass er nur in dringenden Fällen und nur so lang wie nötig als 'xs'-Benutzer den NM nutzen soll. Vielleicht ist euer Chef/in als 'xs'-Benutzer/in oft im Notenmanager über einen langen Zeitraum angemeldet und bremst so unbewusst das NM-Gesamtsystem aus?
Hallo,
danke für die bisherigen Tipps, aber leider noch keine Lösung in Sicht. Dass der Schulleiter im NM mitliest, kommt relativ selten vor. Die Datei nmdaten04.mdb ist 8,66 MB groß, also auch keine Größe, die ein 100 Mbit-Netz vor entscheidende Probleme stellen sollte. Im übrigen sollte der gesamte Traffic im Netz bei insgesamt 9 möglichen Clients auch nicht das große Hindernis darstellen. Nachdem das Problem bei allen Clients auftaucht, kann es auch nicht an einzelnen Leitungen liegen. Die NAS hängt an einer Gigabit-Leitung direkt am Switch.
Rätsel, Rätsel.
Gruß
b.v.
Was habt ihr denn für eine Virenscanner-Lösung? Kann es sein, dass euer Virenscanner bei jedem Netzwerkzugriff auch die Dateien auf dem Netzwerklaufwerk scannt? Das würde dann bedeuten, dass bei jedem Datenbankzugriff auch die Datenbankdatei gescannt wird. Da der Notenmanager die Datenbankverbindung immer wieder abbricht wenn er keine Daten benötigt (ist notwendig für die Stabilität der Datenbank), wäre der Virenscanner dann im Dauereinsatz.
Hallo,
also der Virenscanner (Trend Micro Sytem) kann es eigentlich auch nicht sein. Ich habe es nämlich auch ohne Virenscanner ausprobiert und das Geschwindigkeitsproblem bleibt.
Tut mir leid, aber dann hab' ich auch keine Idee mehr.
Da der Notenmanager in der aktuellen Version vermutlich in jeder Schule in einem Netzwerk läuft, kann es nicht an der Programmversion selber liegen. Eine zunehmende Zugriffsdauer bei ansteigender Datenbankgröße ist zwar normal, liegt aber üblicherweise im erträglichen Bereich (auch unsere Datenbank liegt in der Größe 8-9 MB und es gibt keine Probleme).
Möglicherweise liegt es an einer Einstellung der Buffalo Terastation. Ich habe selber eine, greife bei Tests mit 2-3 Clients zu und kann da überhaupt keine Schwierigkeiten feststellen.
Mein bester Tipp bleibt der Virenscanner. Gibt es die Möglichkeit, dass du mit einem Rechner (Notebook), auf dem überhaupt kein Virenscanner installiert ist, mal auf die Terastation zugreifst? Bei abgeschaltetem Server? Falls ihr nämlich eine Netzwerklösung von TrendMicro habt funkt jener vielleicht auch dann dazwischen, wenn er auf dem lokalen Rechner deaktiviert ist.
Hallo,
wir haben eigentlich keine richtige Netzwerklösung, weil uns immer noch der Server fehlt. D.h. ich habe nicht nur die Datenbankdaten (nmdaten04) sondern auch das Programm auf der Terastation. Jeder User starte per Verknüpfung den NM von der Terrastation. Ich wollte mir damit die Notwendigkeit bei jedem Update dieses 10mal zu installieren sparen.
Ich habe heute versuchsweise den NM auf einem Rechner auf der lokalen Platte installiert und damit auf die Daten auf der Terastation zugegriffen. Voila! Die Geschwindigkeit ist wieder da!
Nachteil: jedes Update macht mich zum Installateur.
Gruß
b.v.
18.03.2009, 21:39 (Dieser Beitrag wurde zuletzt bearbeitet: 14.12.2009, 20:54 von NM-Himself.)
Antwort 1:
Damit bestätigt sich aber meine Vermutung, dass da ein Virenscanner beteiligt ist. Die Programmdatei ist ca. 10 MB groß. Selbst wenn mir mit einer Nettorate von nur 50 % rechnen (das wären schon WLAN-Bedingungen) sollte die Ãœbertragung 3 Sekunden (im schlimmsten Fall 5 Sekunden) dauern. Im gegensatz zur Datenbank ist das Programm aber eben eine EXE-Datei die beim Laden u. U. durch einen Echtzeitscan des Virenscanners durch muss.
Ich schreib das nur, weil wir (und andere Schulen) genau das gleiche Problem schon mit dem Norman-Virenscanner hatten. Nach einem automatischen Update des Virenscanners über nacht ging am nächsten morgen gar nichts mehr. Der Programmstart hat plötzlich über 2 Minuten gedauert. Die Ursache war damals, dass beim Scanner-Update die Option zum Scannen von Netzwerklaufwerken aktiviert wurde und Norman vor jedem Programmstart die EXE erst einmal über das Netzwerk gescannt hat. Nach deaktivieren dieser Option ging dann wieder alles ratzfatz.
Gruß
Stephan
Antwort 2:
Aber nicht verzweifeln, ich hab für alles eine Lösung. In deinem Fall ist das die neueste Version meines Tools LanUpdate.
Das Programm ist gerade erst fertig geworden, ich habe es bisher nur unter WinXP und nur mit Adminrechten getestet!
Systemvoraussetzungen LanUpdate ist mit VB2005 geschrieben (ist also ein "dotnet-Programme") und benötigt daher das .Net-Framework in der Version 2.0.50727 (wenn das Verzeichnis C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 vorhanden ist, passt alles). Dies sollte ab WinXP mit Servicepack 2 eigentlich der Fall sein.
Funktionsweise
Dem Programm werden (per Konfigurationsdatei, s. u.) zwei Informationen übergeben:
Ein Referenzverzeichnis
Das zu startende Hauptprogramm
Nach dem Programmstart vergleicht LanUpdate das eigene Verzeichnis mit dem Referenzverzeichnis. Dabei werden dann neuere Dateiversionen oder lokal fehlende Dateien vom Referenzverzeichnis in das LanUpdate-Verzeichnis kopiert. Anschließend startet LanUpdate automatisch das Hauptprogramm.
Bei zuküftigen Updates müssen also die neuen Dateien lediglich in das Referenzverzeichnis gelegt werden, LanUpdate sorgt dann dafür, dass auch die lokalen Verzeichnisse auf den aktuellen Stand gebracht werden.
Installation
Lege auf dem Server ein Referenzverzeichnis an (als Beispiel "\Notenmanager\Programmdateien"), das für alle Clients zugänglich ist (lesend). Es sollte sich NICHT um das Datenbankverzeichnis handeln, da sonst auch die Datenbank jedesmal in das lokale Verzeichnis kopiert wird.
In das Referenzverzeichnis kannst du zum Beispiel die Dateien aus der Update-Zip kopieren. Zusätzlich sollten die Dateien "waitbar.exe" und "DE_DE.jsp" hineinkopiert werden.
Lege auf jedem Rechner ein beliebiges, lokales Verzeichnis an (wg. Zugriffsrechten sollte es NICHT unter c:\Programme liegen).
Kopiere den Inhalt der angehängten Zip-Datei in dieses Verzeichnis (LanUpdate.exe, LanUpdate.conf, LanUpdate.exe.manifest, Notenmanager.ico).
Öffne LanUpdate.conf mit einem normalen Texteditor. Ändere die Einträge nach folgendem Schema ab: LookupPath = [Pfad zum Referenzverzeichnis]
FileToStart = nmanagersv.exe
also z. B. LookupPath = \\server\notenmanager\Programmdateien
FileToStart = nmanagersv.exe
Erstelle eine Verknüpfung zu LanUpdate.exe auf Desktop. Das Symbol solltest du auf das Notenmanager-Icon abändern und auch den Text in "Notenmanager" umbenennen. Die anderen Notenmanager-Verknüpfungen löschst du dann vom Desktop.
Beim ersten Programmstart von LanUpdate werden dann alle Dateien in das lokale Verzeichnis kopiert und anschließend der Notenmanager gestartet.
Für den normalen Benutzer ändert sich nicht viel. Er sieht ein Notenmanager-Symbol, macht seinen Doppelklick drauf und er Notenmanager startet. Je nach Netzwerkgeschwindigkeit sieht er höchstens mal kurz das LanUpdate-Programmfenster aufflackern.
Hallo,
ich haben das Problem jetzt wirklich gelöst:
Es war die Verzeichnisstruktur auf dem Netzlaufwerk. Ich hatte auf der Terra-Station einen Ordner Notenmanager und in diesem Ordner noch einmal einen Ordner Notenmanager. Sollte man nicht machen, ist mir beim installieren so "gelungen", weil ich noch einen Ratschlag aus dem Handbuch in den Ohren hatte, dass beim Abgleich der Daten mit WinSV das Verzeichnis des NM nicht das Root-Verzechnis eines Laufwerks sein sollte.
Jetzt hatte ich eine erneute Installation durchgeführt in einen nicht "gedoppelten" Ordner und siehe da! Darauf habe ich in der urspünglichen Installation die Ebene herausgenommen und schon flutscht der NM in vorher nicht gekannten Geschwindigkeiten.
Dank an alle, die mit Ratschlägen geholfen haben.
B.V.
jetzt ist das Problem endlich vom Eis.
Wir haben das .netFrame (2.5) installiert und die Datenbankdate in ein eigenes Verzeichnis im Root der NAS. Seitdem "flutscht" der NM von jedem Gerät im Netz aus.
Danke an alle, die mithalfen, v.a. ntürlich an den Programmiergott . Sein Tipp mit dem Programm LAN-Update zwang mich zum installieren des .netFrame-Programms.
Der Zwischenbericht kann kommen!
B. Vidoni
Kurze Rückfrage: meinst du das .Net Framework 2.0.5 oder die Version 3.5?
Bei letztere ist Vorsicht geboten: nach der Installation von Version 3.5 auf unserem Windows 2003 Server gab es massive Probleme. Unter anderem funktionierte der Remote-Zugriff nicht mehr und auch noch ein paar andere Dinge. Hat mich ne Zeit gekostet um herauszukriegen, das es am (immerhin microsoft-eigenem) .Net Framework lag. Nach der Deinstallation von Version 3.5 waren alle Probleme wieder behoben.
,
Sollte man nicht machen, ist mir beim installieren so "gelungen", weil ich noch einen Ratschlag aus dem Handbuch in den Ohren hatte, dass beim Abgleich der Daten mit WinSV das Verzeichnis des NM nicht das Root-Verzechnis eines Laufwerks sein sollte.
. Sein Tipp mit dem Programm LAN-Update zwang mich zum installieren des .netFrame-Programms.