| chat.freenode.net #tryton.de log beginning Mon Jul 10 00:01:01 CEST 2017 | ||
| 2017-07-10 07:33 -!- flachtassekasse(~flachtass@5.104.149.54) has joined #tryton.de | ||
| 2017-07-10 07:48 -!- LordVan(~LordVan@gentoo/developer/LordVan) has joined #tryton.de | ||
| 2017-07-10 09:33 -!- Lordvan_(~LordVan@gentoo/developer/LordVan) has joined #tryton.de | ||
| 2017-07-10 09:35 -!- LV(~LordVan@gentoo/developer/LordVan) has joined #tryton.de | ||
| 2017-07-10 10:43 -!- udono(~udono@078-058-210-188.ip-addr.inexio.net) has joined #tryton.de | ||
| 2017-07-10 11:04 <scrapper> Hallo Leute, Hallo udono, alljährlich haben wir ein ähnliches Problem. Beim Jahresabschluss ist für uns die Generierung des "Kontenplan öffnen" total wichtig. (Info wir arbeiten nach wie vor auf einem alten Tryton 2.2.0 Production Server mit Ubuntu 16.04 Postgresql-9.6 - zuviele Spezialanpassungen als das hier im Nächsten Jahr eine Migration auf eine neue Tryton Version möglich wäre...). Gibt es eine Möglichkeit die Generierung des Kontenpl | ||
| 2017-07-10 11:04 <scrapper> ans zu beschleunigen? Wir sind eine kleine Firma mit vielleicht 15-20 Rechnungen (Total=in+out) und die Generierung des Kontenplans dauert ca. 75 Sekunden. Früher hat diese sogar über 7Minuten in Anspruch genommen, doch seit mehr als 1Jahr läuft das Teil auf einem i7 mit SSDs und wurde dadruch um einen Faktor ~9 beschleunigt. | ||
| 2017-07-10 11:05 <scrapper> Meine Analyse ergab folgendes: CPU's lediglich auf 50-70% bei der Report Generierung "Kontenplan öffnen" | ||
| 2017-07-10 11:06 <scrapper> RAM erbärmlich wenig. Der RAM verändert sich lediglich um vielleicht 5-10MB bei der Generierung. | ||
| 2017-07-10 11:08 <scrapper> Was mir aufgefallen ist... die Netzwerk-Kommunikation "Tryton-Server" <-> "Client" mit dem JSON-RPC Protokoll läuft bei der Report-Generierung kontinuierlich. Sprich es ist nicht so, dass man die Query auslöst und den Kontenplan vom Server erstellt wird und am Ende an den Client gesendet wird. SONDERN während der Generierung kommunizieren Server und Client kontinuierlich. Es scheint als würde der Server das Ergebnis in kleinen Stücken an den C | ||
| 2017-07-10 11:08 <scrapper> lient liefern. Und ich habe das Gefühl (bin mir aber nicht sicher) dass dies der Engpass (bottleneck) sein könnte und das der Grund ist warum die "Kontenplan öffnen" Generierung soviel Zeit (~70Sekunden) in Anspruch nimmt. | ||
| 2017-07-10 11:09 <scrapper> Hat jemand eine Idee / Lösungsvorschlag diese Report-Generierung "Kontenplan öffnen" zu beschleunigen? | ||
| 2017-07-10 11:09 <udono> scrapper: Hi, in der 2.2 sind die Einträge im Kontenplan noch übersetzbar. Je nachdem wieviele Konten ihr benutzt bzw. welchen Kontenplan ihr benutzt kann das lange dauern. Hast Du mal ausprobiert, die nie verwendeten Konten zu löschen? | ||
| 2017-07-10 11:12 <scrapper> udono: die nie verwendeten Konten habe ich noch nie gelöscht... im laufe der Firmengeschichte werden die verwendeten Konten ja auch immer mehr. Wir verwenden den österreischen Kontenrahmen. es stimmt schon, der ist schon ganz ordentlich. Was mir auch aufgefallen ist, wenn ich "Kontenplan öffnen" für etwas früheres mache,... z.B.: 31.12.2011 dann geht das wesentlich schneller als wenn ich 31.12.2015 öffne. Da müssen wohl nicht soviele Konten | ||
| 2017-07-10 11:12 <scrapper> kalkuliert werden. | ||
| 2017-07-10 11:13 <scrapper> udono: gehen ich richtig mit der Annahme, dass das json-RPC und die Server-Client Kommunikation hier die Engstelle ist!? Der Server läuft nichtmal auf 100% CPU sondern deutlich darunger und auch die I/O auf den SSDs ist sehr niedrig. Irgendwo ist hier die Engstelle. Und ich kann mir nur das JSON-RPC denken. Oder lieg ich hier total falsch? | ||
| 2017-07-10 11:15 <scrapper> udono: ich bin zuversichtlich, dass beim Löschen der nie verwendeten Konten das Teil beschleunigt wird... aber eine andere Lösung wär mir natürlich lieber : ) - ich lösche ungerne etwas : ) | ||
| 2017-07-10 11:16 <scrapper> udono: Beispielsweise die Generierung von "Summen - und Saldenliste" oder "Bilanzbogen" oder "Steuerkennziffern" das nimmt alles 'nur' um die 10Sekunden in Anspruch. Damit kann man arbeiten... Aber "Kontenplan öffnen" ist brutal langsam. | ||
| 2017-07-10 11:17 <udono> scrapper: das ist sehr schwer zu beantworten. Das Kontensystem ist eine Baum Struktur, da ist die Berechnung und die Darstellung noch ineffizient in der 2.2 | ||
| 2017-07-10 11:17 <scrapper> udono: wenns wenigstens an CPU, RAM oder I/O auf den SSDs scheitern würde... das wäre zu verstehen. Aber irgendwie habe ich das Gefühl es wird ausgebremst durch die "Server-Client" Kommunikation. | ||
| 2017-07-10 11:18 <scrapper> udono: ich hab mir einen Tag Zeit genommen um die Unterschiede zwischen 2.2 und 4.4 ins Auge zu fassen. Leider ähnliches Problem wie vor 1Jahr... keine Chance, dass ich das in sinnvoller Zeit < 5Tage von 2.2 auf 4.4 migrieren kann. | ||
| 2017-07-10 11:20 <udono> Die altenkontenpläne lassen sich wahrscheinlich schneller öffnen, weil du einen Jahresabschluss /Periodenabschlüsse gemacht hast. Dabei werden die Summen der einzelnen Kontenklassen extra gespeichert. Beim aktuellen Plan muss immer erst die Baumstruktur aufgebaut werden und dann die Summen berechnet werden. Deshalb könnte hier ausmisten des Kontenplans helfen. Du kannst ja jederzeit in der Kontenplanvorlage nachschauen wie ein gel | ||
| 2017-07-10 11:20 <udono> öschtes Konto konfiguriert war. | ||
| 2017-07-10 11:21 <udono> scrapper: was für eine Verbindung haben server/Cloient bei dir? | ||
| 2017-07-10 11:22 <scrapper> udono: JSON-RPC ca. 12Mbit Ethernet/LAN. Kommunizieren tun die nur mit 10kbit... aber eben so kontinuierlich, dass ich dachte, eventuell gibts hier Pausen bei Handshake oder was weiß ich was : ) | ||
| 2017-07-10 11:23 <udono> scrapper: wenn alles andere flüssig läuft, dann wird es IMHO nicht die Kommunikation sein. | ||
| 2017-07-10 11:24 <scrapper> udono: geholfen hast du mir schon. die Wahrheit ist... (peinlich) ausser 2011 habe ich noch keine Geschäftsjahre geschlossen. da hier überall noch minimale Abschlussarbeiten nötig sind. | ||
| 2017-07-10 11:26 <scrapper> udono: Somit wird laut Deiner Aussage... "Dabei werden die Summen der einzelnen Kontenklassen extra gespeichert." ... den Vorteil hat meine Kontengenerierung 'noch' nicht. Wenn ich das zumindest mal erledige, kann er sich nur aufs aktuelle Jahr konzentrieren und müsste zumindest hier mal deutlich schneller werden. Somit schaff ichs eventuell auf 20Sekunden runter. Das wär auch schon ein großer Erfolg. | ||
| 2017-07-10 11:27 <scrapper> udono: ich erledige das die nächsten Tage und melde mich hier an dieser Stelle mit einer Speed-Analyse. Wie so oft... ich danke dir! | ||
| 2017-07-10 11:29 <scrapper> udono: ich werd heute Abend einfach ein Backup erstellen und das mal testen, dann wissen wirs genau ; ) | ||
| 2017-07-10 11:29 <udono> scrapper: ja, du solltest die vorangegangenen Geschäftsjahre schließen, dann wird es bestimmt schneller. | ||
| 2017-07-10 11:31 <scrapper> udono: hast du 4+ irgendwo im Einsatz? mit welchem Performance Boost kann man in diesem Zusammenhang in der Praxis rechnen? | ||
| 2017-07-10 11:33 <udono> scrapper: Es ist deutlich schneller geworden, als die Übersetzungen des Kontenplans entfernt wurden. Aber das schließen von Geschäftsjahren ist immer entscheidend für die Performance. | ||
| 2017-07-10 11:36 <udono> scrapper: ich würde ein Backup der Datenbank mit noch offenen Geschäftsjahren sichern. Dann hast du immer noch die Möglichkeit deine Abschlusskorrekturen einzutragen. | ||
| 2017-07-10 11:37 <scrapper> udono: ja unbedingt, werde das heute Abend vor den Änderungen sichern. Danke Dir! | ||
| 2017-07-10 11:38 <udono> scrapper: sehr gern | ||
| 2017-07-10 13:03 -!- yangoon(~mathiasb@p5DFE034F.dip0.t-ipconnect.de) has joined #tryton.de | ||
| 2017-07-10 13:57 -!- flachtassekasse(~flachtass@5.104.149.54) has joined #tryton.de | ||
| 2017-07-10 14:07 -!- Timitos(~kpreisler@host-88-217-184-172.customer.m-online.net) has joined #tryton.de | ||
| 2017-07-10 19:56 -!- scrapper(~scrapper@mail.alpmine.com) has left #tryton.de |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!