Le 24/01/2017 à 11:03, Cédric Krier a écrit :
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.
Yeah, I can understand diminishing returns... will just have to avoid using
<shift>+
except at low levels... thanks for the explanations.
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).
okay, though this makes it awkward online, will have to deal with this via
custom reporting.
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)
in many respects, especially using filters, GL is indeed somewhat more
versatile.
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.
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.
except I can't seem to post any longer neither directly nor via gmane group
interface...
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.
I did mean for other use cases, naturally.
cheers
--
Richard PALO
--
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/o67p6j%24cp8%241%40blaine.gmane.org.
