ich versuche, sofern ich es nicht vegesse, immer die automatische optimierung zu nehmen...
bei unseren SQL-Parametern hat sich nach dem Update nichts verändert (zumindest der vmax RAM war individuell).
wie ist euer Index? Wir haben auch die 12er Intel
Ansonsten hat sich am Index nach der 17er quasi nichts verändert...
@Gelöschter Nutzer schrieb:...@agmü
wie ist euer Index? Wir haben auch die 12er Intel
entweder wird das Tool in unserer Variante der Software nicht ausgeliefert, oder ich bin unfähig die das Messtool zu finden.
Der DHC ist in dieser Beziehung ein echter Fail: Suchwort "Leistungsindex Rechnungswesen" Treffer: Dokumentennummer 1080330.🤔
Laufwerk:\DATEV\PROGRAMM\RWApplic\Leistungsindex.cmd
Mitunter ist der Pfad ausgeblendet und man muss in komplett im explorer oder der Eingabeaufforderung eingeben.
Ggf. ist der Zugriff auch komplett gesperrt.
Viele Grüße
sieht tatsächlich im Vergleich nicht so super aus. Allerdings habe ich bei REWE keine Leistungseinbußen bemerkt.
Der Leistungsindex scheint sich auch nur mit ReWe zu beschäftigen nicht mit dem Rest der DATEV-Software.
Mir bereitet der DAP die eigentlichen Kopfschmerzen - von milchigen Bildschirmen bis zu Komplettabstürzen reicht die Bandbreite des Programmverhaltens.
@agmü ,
wenn diverse andere Aktionen, z.B. die "netzweite Aktualisierung" oder die "automatische Systemoptimierung" auch vorher schon massive Probleme hatte, könnte es ja sein, dass man versteckte Probleme in die neue Plattforminstallation der DVD 17.x 'hinübergerettet' hat.
... nur eine Spekulation, aber nicht immer behebt eine Software-Aktualisierung die Probleme der vorangegangenen Installation 😎
Ich selbst war vorher insgesamt mit den "Netzweiten Aktualisierungen" und der "automatischen Systemoptimierung" und mit der Performance zufrieden und bin es immer noch.
Vielleicht bin ich einfach ein bescheidener Mensch und schnell zufrieden zu stellen 😎😅
Ohne es beweisen zu können, behaupte ich, dass die Programmierung des DAP nicht annähernd leistungsoptimiert ist.
Leider sind heutige System in der Regel gut bestückt und es spiel keine Rolle wie umständlich der Code letztlich ist.
Im Hinblick auf gute Übersicht und Kompatibilität würde ich auch die eine oder andere performanceraubende Kurve verstehen, aber ich vermute, dass hier gehörige Performance-Bremsen enthalten sind.
Dies mag auch am Windows-Umfeld an sich liegen, aber wir brauchen keine weichen Farbübergänge, animierten KrimsKams... es muss halt alles bedienbar und lesbar sein...
Ich bin auch immer überrascht, wie lange es dauert, um quasi ein paar Zahlen auszulesen...
Denke ab V13 hat sich die Performance bei uns spürbar nach unten entwickelt
Der Leistungsindex ist eine Momentaufnahme (gerade bei WTS und virtuellen Systemen zu beachten) erlaubt aber schon relative Vergleiche zwischen vergleichbaren Strukturen. Letztlich wird die Performance des DAP damit auch abgebildet aber die ist bei sehr schnellen Rechnern ggf. normal langsam und bei langsamen Rechnern halt sehr langsam 😉.
Vielleicht muss der SQL noch länger lernen, was er wie cachen muss und nach einigen Wochen gelingen zumindest die Datenbankzugriffe (die ja vom DAP teilweise abgewartet werden) schneller?
Da laufen ja auch irgendwelche Optimierungsläufe abseits der native images.
Warum ist der DAP langsam?
Man kann DATEV schnell machen.. allerdings muss man dann die Virtualisierung begraben..
hat alles so seine Vor- und Nachteile..
Der SQL optimiert sich in relativ kurzer Zeit von selbst.
Die eigentliche Umstellung auf den SQL 2019 ist bei uns bereits mit der Pilotierung der DVD 17.0B vor etlichen Monaten erfolgt. Daher war meine - vielleicht falsche - Erwartung , dass die Installation der Freigabeversion (der DVD 17.0) - wie in der Vergangenheit letztlich nur noch zu geringfügigen Änderungen führt.
@vogtsburger : zwischenzeitlich habe ich an die Installation der DATEV-Software nur noch die Erwartung, dass ich die Installation (ohne Schwierigkeiten) durchführen kann. Wenn dieser Anspruch überzogen ist😂😂🤣, dann muss ich wohl doch nach 20 Jahren einen externen Dienstleister mit der Installation beauftragen.
Ein kleiner Hinweis zum Leistungsindex-Screenshot von @agmü, die Festplattenperformance ist deutlich unterirdisch....
@agmü schrieb:[...]
@vogtsburger : zwischenzeitlich habe ich an die Installation der DATEV-Software nur noch die Erwartung, dass ich die Installation (ohne Schwierigkeiten) durchführen kann. Wenn dieser Anspruch überzogen ist😂😂🤣, dann muss ich wohl doch nach 20 Jahren einen externen Dienstleister mit der Installation beauftragen.
[...]
... in den 20 Jahren wurde aber sicher auch schon mehrere Male der/die 'Datev-Server' (Fileserver, Domaincontroller, WTS etc) gewechselt, entweder durch Neuinstallation oder durch 'Umzug' der Datev-Welt 'mit Sack und Pack', mit Hilfe von Datev-Tools (Umzugsassistenten)
Ein solcher Wechsel der zentralen Hard- und Software-Komponenten in der eigenen On Premises Infrastruktur ist (aus meiner Sicht) verd.ammt 'heikel', zeitaufwändig und bezüglich des KnowHows anspruchsvoll.
Auf Mandantenseite habe ich schon mehrfach erlebt, dass Admins des Unternehmens oder externe Dienstleister (ohne viel Datev-Erfahrung) dieses 'Bisschen Datev-Netzwerkinstallation' selbst erledigen wollten ...
.... und gescheitert sind.
Eine 'verbastelte' Datev-Installation dann wieder zu 'reparieren', ist sicher noch heikler und fehleranfälliger als eine nagelneue Standard-Datevinstallation streng nach Datev-Checkliste zu machen.
Und Fehler, die man irgendwann mal 'eingebaut' hat, haben oft einen einen starken Überlebenswillen und 'rächen' sich gerne auch noch Jahre später
@Gelöschter Nutzer schrieb (von mir editiert zur Bezugnahme):
- Warum ist der DAP langsam?
- Man kann DATEV schnell machen.. allerdings muss man dann die Virtualisierung begraben..
hat alles so seine Vor- und Nachteile..- Der SQL optimiert sich in relativ kurzer Zeit von selbst.
Letztlich ist die Performance typischerweise praktisch aber schon so, dass man schon auch arbeiten kann. Die Anforderungen an die CPU (SingleCore Speed) zeigt aber deutlich, dass hier Raketentechnik für ein Datenbankprogramm nötig ist.
PS:
Habe früher im wissenschaftlichen Bereich größere Datenbestände auswerten müssen und kann sagen, dass abhängig von der Programmiersprache (maschinennäher oder eben besser strukturiert) und auch der Programmierlogik ein Faktor >100 kein Problem ist. In einem Fall einige Minuten warten im anderen unsicher sein ob das Programm überhaupt gestartet wurde, weil nach ein paar Sekunden fertig...
Natürlich muss hier die Datev Wert auf eine klare Struktur legen (die hatten die letzten Jahre sicher auch eher zu Kämpfen die diversen Regelungen umzusetzen und wohl eher wenig Sinn für Optimierungen), was einen Kompromiss hinsichtlich der Performance bedingt.
Wie auch immer, das Ganze müsst in meinen Augen auch auf einem langsamen virtualisierten System zügig laufen...
Wir haben hier ja keine Echtzeit-Weltwetter Simulation und keine große dynamische Festigkeitssimulation mit diversen nichtlinearen Materialeigenschaften oder eine 8K-Video-Schnittmaschine...
Die Frage ob virtualisiert oder auf Blech ist irgendwann ohnehin hinfällig, da DATEV in die browserbasierte Cloud will oder muss.
Bis dahin zieh ich das Blech noch durch, da es trotz ein paar Nachteilen auch noch viele Vorteile mit sich bringt... wegen Office muss ich mir z.B. keine Gedanken machen..
über die Kostenexplosion bei diesen virtuellen Azure-Maschinen usw. auch nicht.
Letztlich kann DATEV in der derzeitigen Form nicht richtig Multicore.. und daran wird sich vermutlich soweit nichts mehr ändern, da die Ressourcen auf die Cloudanwendungen und die Hybridisierung gelenkt werden.
Als kleines Update nach der Installation des SR vom 07.09.
Die Performance unseres Systems entspricht wieder dem Zustand, den ich vor Installation der Freigabeversion der DVD 17.0 kannte.
Mein Bauchgefühl, dass die Performance durch "irgendeines" der Programme in den Keller gezogen wurde, scheint sich bestätigt zu haben. Welches der Programme? I don't know.
... inzwischen habe ich auch einige Mitarbeiter einer Umsteiger-Kanzlei unserer Größenordnung bezüglich der Performance nach ihren 'Bauchgefühlen' befragt
(vorher On-Premises-Kanzlei mit 1 All-In-One-Datev-Server mit 20 Clients, jetzt PARTNERasp-Kanzlei)
Ergebnis (nicht repräsentativ) :
das vorherige On-Premises-Datev-Netzwerk war schneller als das jetzige PARTNERasp-Datev-Netzwerk
wie gesagt:
das sind nur einige nicht repräsentative 'Bauchgefühle' einiger Datev-Anwender
... mich hatte allerdings überrascht, dass ein vermeintlich 'überfordertes' On-Premises-Datev-Netzwerk mit nur 1 Datev-Server, ohne WTS, ohne Virtualisierung oder andere Gimmicks bezüglich der Performance anscheinend mindestens 'in der selben Liga spielt' wie ein neu eingerichtetes PARTNERasp-Datev-Netzwerk
... ich weiß, dass man eigentlich mehr Daten bräuchte und dass man nicht Äpfel mit Birnen vergleichen sollte, ...
... aber bei Obstsalat spielt das 'Bauchgefühl' ja schließlich auch eine Rolle
Nachtrag:
... wusste gar nicht, dass andere User Beiträge des Thread-Erstellers als Lösung markieren können
... oder war es eine Moderatorin ?
... mein Gedächtnis sagt, es war @Agnes_Krause
... aber warum ?
... soll hier nicht weiter geschrieben werden ?
... folgt jetzt noch der 'Deckel auf dem Topf', das Schließen des Threads, weil die Frage ja gelöst erscheint ?
Nachtrag 2:
ich hätte mein Gedächtnis gar nicht 'quälen' müssen
Im Benachrichtigungs-Feed steht ja deutlich lesbar der Username 😅
Hallo @vogtsburger ,
ich hatte @Agnes_Krause darum gebeten den Beitrag als "Lösung" zu markieren. Wie Sie vermuteten können das nur die Moderatoren in dem Bereich machen.
Ich hatte Sie darum gebeten, da ich mit Herrn @agmü heute Vormittag einmal zu dem Thema gesprochen hatte.
In seinem Kontext hat das Service Release Abhilfe geschaffen und wird dementsprechend als "Lösung" markiert.
Das sollte nicht signalisieren, dass der Thread damit geschlossen wird. Sie können gerne weiter Ihre Erfahrungen zu dem Thema teilen.
Konkret können wir dann aber nur persönlich bzw. über einen Servicekontakt Abhilfe schaffen.
Besten Dank und Gruß
Lucas