On 2017-01-24 07:52, Richard PALO wrote: > Le 23/01/2017 à 21:53, Cédric Krier a écrit : > > On 2017-01-23 07:16, Richard PALO wrote: > > > Are there any tuning remedies? If not, what would things be like if we > > > were to migrate a company with an average of over 5500 movements per year? > > > > Normally it should not depend on the number of moves. For me, the > > slowness is the number of queries but not the computation of the > > balance/debit/credit. Those computations should be almost linear (with a > > very small coefficient). > > > Perhaps this could be split up to run parallel by the top (N) level(s), > for example, in French PCG, run parallel queries for each class (1 .. 8) > or subclass (1[0-8], 2[0-9] et cetera)...
I do not think it will improve. There are very few parts that could be run in parallel like the SQL queries (but only if # accounts > 1000) and the cumulate function (but it should normally iterate only once). Also the machineries to make it parallel will probably cost more then it will benefit, without talking about the complexity it will create. > > > Also, unfortunately it appears that the 'views' still only update the > > > final > > > balance field and not the debit/credit fields. > > > I thought I already filed an issue including that way back but can't seem > > > to find it. > > > Is it on 'purpose' to exclude displaying the total movements debit/credit > > > as well as, > > > > Yes it is on purpose (since 1.0). > > > > > eventually, the initial balance in the chart of accounts? > > > > I guess you are looking for the General Ledger instead of the Chart of > > Account. > > (which will load much faster as it is a list) > > > > Now that I try to compare, is there really any reason not to simply replace > chart of accounts > by reports->general ledger? No it makes no sense as GL is based on the CoA. > The views would/should probably need to be added back, though, as they seem > to be missing in both the display and in the reports. Usually, account without moves are not shown on the GL. View accounts have never any moves. But it could be discussed but probably on tryton@ where accounting guys should be. > As to the threaded performance, I've been meaning to check out using uwsgi, > but > it's still a bit premature to spend time on that for the moment. As I said, it will not help for this specific issue because it is the client who perform sequential request because of the design of GTK expand all feature and the lazy loading of Tryton. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/20170124100300.GE68908%40tetsuo.
