Office: (Office 2016) Performance / langsames Netzwerk / Frontend

Hallo zusammen,

Ich habe mal eine Frage an die erfahrenen hier:

Situation:
- Netzwerk ist unglaublich langsam
- Aufteilung in Front- und Backend war notwendig

Lösung: jegliche Stammdaten sind schon ins Frontend auf eine lokale Platte geschoben, das ist jetzt zwar 65MB groß, aber das juckt ja keinen - und dafür ist es schneller. Aktualisiert werden die Daten über regelmäßige Abfragen auf den Datenstand auf dem Server (Teil 1 vom Backend) im Vergleich zum Datenstand lokal.

Soweit so gut - leider sind die "lebenden Daten" (Teil 2 vom Backend) inzwischen auch bei circa 2 MB angelangt - trotz Archivierung von Altlasten. (Es handelt sich um eine Art gut genutztes Ticketsystem.) Hier würde ich gerne performanter werden.

In der Fallübersicht habe ich einen gewissen Anteil an alten Fällen, bevor die automatisiert ins Archiv fliegen, aktuell und zu bearbeiten sind immer so circa 20-30 Stück.

Mein aktueller Ansatz ist ein regelmäßiges "requery", was die Anwendung Dank der Netzwerkperformance teilweise komplett lahm legt für ne Minute.

Kreativ wie ich bin, habe ich jetzt den Plan die Tickets zur Ansicht auch ins Frontend zu kopieren, Bearbeitung weiter im Backend.

Das "requery" würde dann nur auf eine Tabelle laufen, in der der Zeitpunkt der letzten Veränderung einer Tabelle im Backend festgehalten wird und bei Bedarf die aktualisierten Datensätze ausm Backend ins Frontend kopiert. So würde man den Datenaustausch minimieren hoffe ich.

Hoffe das ist verständlich beschrieben?

Ist die Idee gut oder doof? Oft ist Kreativität ja nur ein Ausdruck von "ich weiß es nicht besser". Bin für jegliche Anregungen offen.

Vielen Dank schon einmal :-)

:)

 

Wie schnell ist denn Deine Netzwerkumgebung und wieviele Benutzer greifen gleichzeitig auf die DB zu?

PS: 2MB sind gerade einmal 1/1000stel der max. Größe einer Access Datenbank - also weniger wie das Schwarze unter einem Fingernagel.

 

Wie sieht es aus mit Indexnutzung?
Eine solche sollte auch für eine Verkleinerung von Recordsets sorgen.

 

Also die Geschwindigkeit des Netzwerkes ist leider komplett tagesformabhängig. Ist mir auch absolut nicht klar, was die sich da gedacht haben. Hatten erst lokale Server, war natürlich absolut ätzend bei diversen Standorten, die untereinander nicht verbunden waren. Aber dafür wars performant. Jetzt sind die Standorte verbunden, man hat direkt versucht weitestgehend alles in die Cloud zu packen (inkl. Desktop). Ich habe seitdem alles auf dem lokalen Laufwerk, weil ich keine Lust habe auf das Öffnen einer kleinen Exceldatei lange zu warten.
Lange Rede, kurzer Sinn: es ist saulangsam.

User sind so um die 10-20. Also alles human, und auch wenn ich alleine in der DB bin ist es langsam. Denke damit hängt das weniger zusammen. Lokal laufen die Abfragen auch superschnell.

Zum Datenvolumen eines Requery: circa 700 Datensätze aus einer Tabelle, circa 30 Spalten. Also auch hier: lächerliche Mengen. Der Rest an Stammdaten kommt aus dem Frontend.

Das Bottleneck ist die Leitung, sehen wir auch bei anderen Anwendungen.

Von daher ist mein Ziel eine Reduzierung des Datenvolumen, solange ich damit nicht an anderen Stellen so langsam werde, dass der Vorteil sich wieder egalisiert.

Ich muss halt sicherstellen, dass der User mit wenig Verzug neue Einträge und Aktualisierungen sieht - daher das requery - oder ist hier schon ein Fehler und man kann das anders sicher stellen?

Die Index-Sache muss ich mir noch einmal angucken. Aber denke aufgrund der geringen Datenmengen wird es das nicht sein.

 

Das wird auf Dauer aber nicht funktionieren. Bei deinem Beispiel mit den 700 Datensätzen wird doch deutlich, dass schon extrem "kleine Datenmengen" letztlich nicht performant laufen.

Nebenher hast du - zum Stichwort Cloud - das Problem, dass Datenzugriffe auf das Backend sporadisch abreissen können. Auf Dauer wirds hier immer mal wieder Probleme mit zerissenen Datensätzen geben.

Ihr müsst da m.E. strukturell ran. Wenn denn lokale Daten je "Niederlassung" tabu sind, was aufgrund der beschriebenen Probleme vielleicht doch nochmal diskutiert werden muss, dann muss auf ein Terminalserver-Konzept oder irgendwas in der Art ausgewichen werden.

 

Gibt es bereits. *grins

Ich bin leider nicht in der Position das Thema zu beeinflussen, da sitzen andere am Hebel (ist rechtlich sogar eine andere Firma). Und aufregen tue ich mich da auch nicht mehr, man lebt halt mit dem Irrsinn und sucht sich seine Workarounds. Also mit anderen Worten: Mir ist klar, dass das alles total unhaltbar ist, verstehen tue ich die Entscheidungen selbst nicht (die Niederlassungen hängen auch alle am SAP und anderen zentralen Anwendungen und auch dort gibt es regelmäßig Probleme), aber ändern kann ich es nicht.

Also noch einmal die Ursprungsfrage:
- Ist die angehängte Struktur als Workaround zur Datenreduzierung tragbar und sinnvoll oder gibt es da Verbesserungen? Bin mir z.B. unsicher, die dritte BE-Datenbank für den Datenstand nicht lieber in BE1+2 integriert sein sollte.
- Gibt es Alternativen zu "Requery", die weniger Daten nutzen und trotzdem neue Fälle übertragen? Das würde das Konstrukt ja auch überflüssig machen.

 

ich sehen keine alternative zu requery, den nur so erhälst du die neuen Datensätze.
Für Access ist wichtig, dass das Netz "hohe ping" antwortzeiten hat, die Datensatzrate ist nicht so sehr.
G
JPA

 

Diskussionen in Verbindung mit Daten die über das Web gehen hat es hier schon öfters gegeben und die verlaufen in der Regel im Sand.

Wie soll jemand Externer die Sachlage so nebenbei beurteilen mit praktisch keiner Kenntnis der Gesamtlage? Es muss jemanden internen geben, der ein Gesamtkonzept erstellt und der muss sich halt auskennen.

Da geht es nicht um alternativen zum Requery (die es schon gibt), Terminalserver oder was auch immer. Da geht es um ein durchdachtes Gesamtkonzept, welches von vielen Faktoren abhängt.

LG Markus

 

Alles klar, dann werde ich das einfach mal so umsetzen und berichten, ob es den erhofften Erfolg gebracht hat. Um nicht auf 3 Backends, sondern nur auf zwei zugreifen zu müssen, werde ich die letzte Änderung eines Datensatzes pro Tabelle in die beiden BE integrieren.

Ob der Ping bei mir auch n Problem ist, kann ich nicht sicher sagen - aber solange ich beim Speichern kleiner Dateien aufm Server zugucken kann, gehe ich davon aus, dass hier auf jeden Fall ein Ansatzpunkt ist und die Datensatzrate ein Bottleneck darstellt.

 

Du meinst sicher: niedrige, denn die Pings werden in ms gemessen und wenig ist schnell.

Zur Verbindungstechnik:
wenn die Daten auf einem Access-File bleiben sollen, führt aus meiner Sicht kein Weg an einem Terminalserver vorbei.
Alles andere ist Frickelkram.

Wenn das zu teuer ist, kann ich empfehlen, die Daten auf einen WebServer in eine MySQL Datenbank zu verfrachten.
Und zu dieser Datenbank Verbindungen aus den Access FrontEnds aufzubauen.
Entweder per ODBC-Verknüpfungen oder per ADODB.

 

Hallo
hier einige Typs welche ich öffters anwende
Lies in meiner Doc. s. Fusszeile unten rechts

Seite:53
5.1.15 Eine andere Metode für CurrentDb (CurrentDBC)
Seite: 54
5.2.1.1 Tabelle Optimieren
Seite: 55
5.2.1.2 Permanente Verknüpfung mit der Daten–
MDB(accdb) (BE) zur Performance Verbesserung
finde ich sehr wichtig !!

evtl. kanst Du das ganze Kapitel 5.2 lesen *wink.gif*
auch da sage ich Indizes (Indexe) Sind SEHR wichtig
im weiteren verwende ich als FE bei den User ein .accdE oder .accdR



ob es viel oder wenig bringt ? (Deine Erfahrung interessiert mich)
versuchen ist mein Ratschlag

 

Hallo,

vielleicht passt das nicht ganz auf deine Situation, aber evt. hilft es weiter.
Wir haben ca. 30 verschiedene Frontends mit ca. 10 Backends.
Wir nutzen noch Access 2003, haben allerdings eine hochmoderne Netzwerk Infrastruktur.

Seit dem Wechsel von Windows XP auf Windows 7 (ca. vor 4 Jahren) haben wir stark mit Performance Problemen zu kämpfen.
Diese Performance Probleme lassen sich jetzt auch nicht zurückführen auf eine hohe Netzwerkauslastung oder auf eine Auslastung der lokalen Hardware. Das haben wir alles getestet.

Was wir allerdings festgestellt haben ist das manche Berechnungen wesentlich länger dauern unter der Verwendung einer Intel Prozessor Architektur. Mit AMD laufen diese Berechnungen zu 200% schneller.
Für unser Haus/Datenbank konnten wir dieses Verhalten validieren!

Besonders große Probleme haben wir bei ODBC Abfragen, das liegt allerdings sehr wahrscheinlich an der dahinterstehenden Datenbank.


Falls ich dir helfen konnte, oder falls mir jemand Helfen kann... Immer gerne *Smilie

 

Das ist ja ein absolutes Biest! Man merkt, dass du mit der Materie schon sehr lange zu tun hast! Sehr cool :-) hab Kapitel 5 mal überflogen bzw. auch genauer gelesen, wenn unbekannt/neue Information. Das Ding werde ich auf jeden Fall als Lexikon bereithalten, Sehr viele Fragen, die man sonst so online ergooglet sind da ja sauber beantwortet.

Allerdings bin ich besonders an zwei Dingen etwas verwirrt:
1. Aussagekräftige Namen vs. kurze Namen
Ich finde nichts schlimmer als kryptischen Code (=kurze Namen), auf der anderen Seite verstehe ich die Intention hinter kurzen Namen. Bin mir aber nicht sicher, ob diese Intention heute noch von relevanter Bedeutung ist oder aufgrund der technischen Entwicklung im Grundrauschen untergeht.
2. Gespeicherte Abfragen vs. SQL-Text
Du schreibst gespeicherte Abfragen sind grundsätzlich schneller (was auch meiner gefühlten Erfahrung entspricht, auf der anderen Seite besteht aber 90% der Doc aus hart gecodeten SQL-Beispielen statt dem Aufruf von gespeicherten Abfragen. Ich würde trotzdem den Weg wählen den SQL-Code wo möglich in einer gespeicherten Query zu haben und den VBA-Code schlank und lesbar zu halten oder?

Ansonsten habe ich da noch ne Menge zu "verdauen" und ein wenig zu verstehen und recherchieren - auf jeden Fall super Anhaltspunkte!

@MK1: gucke ich mal, ob die Umstellung der Netzwerktechnik mit dem Wechsel auf Win7 erfolgte, bin mir da nicht mehr sicher. Office haben wir damals auf jeden Fall gewechselt, aber beim OS bin ich mir nicht mehr sicher. Keine Lösung ist jedenfalls alle PCs zu tauschen, um eine AMD CPU zu haben *biggrin.gif*

 

Das würde ja bedeuten, dass jede Intel/AMD CPU gleich schnell rechnet. Solche pauschalen Aussagen, dass eine AMD CPU nur 1/3 der Zeit benötigt, sind doch eher mit Vorsicht zu genießen, da die Geschwindigkeit bei Gleitkommazahlen z. B. auch sehr start von der Grafikkarte abhängen kann. Da geht es nicht um eine persönliche Erfahrung, sondern um die korrekte Interpretation, die nur mit sehr viel Hintergrundwissen möglich ist.

Auch das ist mit Vorsicht zu genießen. Selbst der beste Server kann schlechte geschriebene Abfragen nicht kompensieren. Da werden aus Sekundenbruchteilen dann Minuten.

LG Markus