Office: (Office 2010) Performanceprobleme mit Terminalserver

Hallo zusammen,

ich benutze Access 2010 unter Terminalserver 2008 R2.

Seit der Umstellung auf Terminalserver habe ich extreme Geschwindigkeitsprobleme mit Access.

Ich habe ein Testprogramm erstellt:
FE lieft auf dem Terminalserver und das BE auf einem Windows 2003 Server.

Das Testprogramm soll 10.000 Datensätze im BE anlegen.

Folgende Testzeiten kommen dann heraus:

FE wird auf Terminalserver ausgeführt:
1. BE nicht durch 2 Benutzer geöffnet 2 Sekunden
2. BE durch 2 Benutzer geöffent 90 Sekunden

wenn ich das gleiche auf vom Windows 2003 Server aus mache und
die BE vom Terminalserver aus als zweiter Benutzer öffne, bleibt in beiden Fällen die Zeit etwa bei 2 Sekunden.

Warum geht unter Terminalserver die Performance so in die Knie?

Ich habe schon den Virenscanner desaktiviert, das Ergebnis blieb aber unverändert.

Hat jemand Erfahrung mit Terminalserver und Access und eine Lösung für dieses Problem?

Danke!

Grüße

:)

 

Hallo
hast Du die allgemeinen Massnahmen zur Performace Verbeserung * schon durch geführt?
*= wie z.b Tabelen Inexieren
oder und Tabelen permanent Verknüpfen und,und
könntest evtl. in meiner Doc s. Fuss Zeile unten Rechts
ab Seite 60 5.2 Performance VerbesserungLesen

 

Hallo,

vielen Dank für die schnelle Rückantwort.

Ja hab ich gemacht.

Das Problem tritt auch nur unter Terminalserver auf.

Ich hänge im Testprogramm nur Datensätze in einer Tabelle an.

Ich habe auch im Internet schon viele gleiche Meldungen gelesen als ich jetzt auf der Suche war. Allerdings keine Lösung oder Ursache gefunden.

Grüße
Thomas

 

Oh ja, Access und TS 2008 R2 mögen sich nicht sonderlich.
Problem deiner Anwendung kannst du IMHO ausschließen, da es ja unter einem anderen OS mit gleichem Access läuft.

Hatten hier einiges an Stress mit der Sage Office Line, welche auf Access 2007 und nun 2010 basiert.

Folgende Punkte haben bei uns geholen:

1. Cache erhöhen / Max Buffer Size

Registryeditor öffnen, folgenden Key ansteuern:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Access Connectivity Engine\Engines

Je nach Versionsnummer deines Access kann hinter dem Office auch 10, 12 usw. stehen - einfach das korrekte auswählen.

Dann unter Engines bei Jet 2.x, 3.x den Wert unter "MaxBufferSize" auf 16384 (Dezimal) setzen. Habe bei uns auch unter ACE den Wert so gesetzt (war vorher 0), aber Jet ist die Hauptengine.

Danach ist ein Neustart erforderlich. Die Änderung sorgt dafür, das die DB Schnittstelle ordentlich Zwischenspeichern kann und einen massiven Geschwindigkeitsvorteil bringt (ist zu 90% der Hauptgrund bei langsamer GEschwindigkeit bei 2k8R2 oder auch Win7)

2. DEP Ausstellen für Access:
Win2k8 R2 hat damals die Datenausführungsverhinderung eingeführt, mit welcher Programme nicht mehr in geschütze Bereiche schreiben können. Problem bei Access 2007 war aber, das dieses eben doch solche Bereiche geschrieben hat. Folge waren nicht nachvollziehbare Abstürze der Anwendung usw.

Fehlerfindung war auch schwierig, da hier die CPU den Prozess killt, bevor WIndows überhaupt aktiv werden kann und somit auch kein oder zumindest kein Sinnvolles Ereignisprotokoll erstellt wird.

Keine Ahnung ob dies bei dir zutrifft, aber einen Versuch ist es wert.

Zum Beheben:
Systemsteuerung > System > Erweitert > "Leistung" > Einstellungen > Reiter Datenausführungsverhinderung > "DAP für alle Programme mit ausnahme der Ausgewählten einschalten" markieren und die Access.exe hinzufügen. Danach ein Neustart. Solltet ihr HyperV einsetzen, DAP via Registry auf HyperVHOst deaktivieren (gab da später bei uns Probleme) - google am besten nach einer Anleitung.

3. Energieverwaltung auf Höchstleistung setzen

Hört sich seltsam an, ich weis. Hatte hier mit HyperV 2008 und 2012 Probleme, welche sich damit beheben liesen. Vielleicht auch bei dir sinnvoll, egal ob du Virtualisierst oder nicht. Am besten mal ausprobieren.

Sollte das alles nichts helfen, kann es noch 2-3 Sachen geben (die wir auch geändert haben), welche die PRobleme hervorrufen können. Nenne die dann bei Bedarf gerne auch noch *Smilie

Hoffe das dir etwas davon aber schon hilft.

 

Hallo,
vielen Dank für Deine Hilfe.
Ich werde das heute noch mit der IT durchtesten.
Grüße
Thomas

 

Hi,
der IT-Mann hat Urlaub :-(
Test und Antwort folgt am Montag.
Nochmals Danke!
Gruß
Thomas

 

Hallo,

konnte heute doch testen.
Leider hat sich mit der MaxBufferSize Einstellung nichts geändert.

Das Problem mit Abstürzen hatten wir nicht.

Das Enegiemanagment ist gar nicht aktiviert auf dem Server.

Hast Du noch einen Tip den wir probieren können?

Danke!
Gruß
Thomas

 

Argh, sry, nicht gesehen *Smilie

Kontrolliert nochmal die Einträge in der Registry und setzt wirklich bei allen Office Versionen unter HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\XX\ bei den Engines mit ACE und JET den Key mit den MaxBuffers. Für den unwahrscheinlichen Fall das ihr Access x64 verwendet, wäre der Key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\XX\...

Wichtig ist danach vor allem der Neustart - ohne diesen wird es nichts.

Auch das mit den Energieeinstellung solltest du nochmal kontrollieren. Wenn ihr virtualisiert (mit HyperV), dann auf dem Host und dem Gast in der Systemsteuerung > Energieoptionen > Höchstleistung auswählen. Gerade HyperV hat da ein paar Probleme, damit wäre das zumindest mal als Quelle ausgeschaltet.

Solltest du die Dateien auf einem Netzwerklaufwerk haben, dann kopier diese mal lokal auf den TS und probier es nochmal aus. Bei SMB hat sich zwischen 2003 (XP Basis) und 2008 RC2 (Win 7 Basis) VIEL geändert *Smilie

 

Was ist denn da drunter zu verstehen?
Ds BE sollte doch in der produktiven Umgebung - wenn überhaupt - nur zu Wartungszwecken direkt geöffnet werden. Und ALLE Benutzer sollten jede(r) mit eigenem FE auf das BE zugreifen.

 

Hallo,

das ist NICHT im produktiven Einsatz sondern nur eine TestFE.mdb und eine TestBE.mdb.

FE Benutzer 1 öffnet die Tabelle im BE
FE Benutzer 2 öffnet die Tabelle im BE
oder
FE Benutzer 1 öffnet DB über OpenDatabase
FE Benutzer 2 öffnet DB über OpenDatabase

beides führt zum gleichen ergebnis, da gibt es keinen Unterschied im Laufzeitverhalten.

Gruß
Thomas

 

Hallo Maerad,

wir sind heute dem Problem auf die Schliche gekommen.
Das Problem war, dass das BE auf einem Windows 2003 Server lag.

Wir hatten zufällig einen externen Citrix Speziallisten im Haus, der schon mal ein ähnliches Problem mit einer Borland Database Engine (BDE) hatte.

Als wir das BE auf einen Fileshare im NAS-Bereich gelegt hatten, ergab der Test eine Laufzeit von ca. 8 bis 11 Sekunden anstelle der 90 Sekunden.
Der Experte hat auch gemeint, dass wir auch auf einen Windows 2008 Server umziehen könnten, dort wäre die Laufzeit auch vergleichbar mit der des NAS.

Wir werden wohl auf den Windows 2008 R2 gehen.
Wenn alles Umgestellt ist, melde ich mich nochmals zu diesem Thema.

Gruß
Thomas

 

Hallo
was auch zu einer Besseren performance beitragen kann.
aus Meiner Doc:

 

Hallo zusammen,

aktuell haben folgendes herausgefunden.
Es muss mit den SMB Versionen der einzelnen Server Betriebssystem zu tun haben.

Windows Server 2003 R2 -> SMB 1.0
NetAppFiler -> SMB 2.0
Windows Server 2008 R2 -> SMB 2.1

Schlechte Performance ergibt sich in folgenden Kombinationen:
FE auf SMB 1.0 mit BE auf SMB 1.0
FE auf SMB 1.0 mit BE auf SMB 2.1
FE auf SMB 2.1 mit BE auf SMB 1.0

Gute Performance ergibt sich in folgenden Kombinationen:
FE auf SMB 1.0 mit BE auf SMB 2.0
FE auf SMB 2.1 mit BE auf SMB 2.0
FE auf SMB 2.1 mit BE auf SMB 2.1

Was also nicht empfehlenswert ist, ist das BE auf einem Windows Server 2003 liegen zu haben. Ebenfalls ist es auch nicht empfehlenswert mit einem FE auf Windows Server 2003 bzw. SMB 1.0 auf einen BE auf einem Server mit einer SMB Version höher als 2.0 zuzugreifen.

Da wir die Citrixfarm in Kürze auf Windows Server 2008 R2 (SMB 2.1) und den Fileserver ebenfalls auf Windows Server 2008 R2 (SMB 2.1) umstellen, sollten sich nach heutigem Teststand die Probleme von selbst lösen.

Vielen Dank an bei der Problemsuche mitgeholfen haben!

Grüße
Thomas