Performances issues with purchase-1.2
B.V.
We are experiencing quite worrying performance issues with tryton-1.2,
especially on purchase and account_invoices modules.
We have a database with about 2600 purchase orders and 45000 purchase
order lines.
Reading 80 orders (1350 lines) takes more than 9 seconds (measured
with a script) for following fields: 'reference', 'untaxed_amount',
'tax_amount' and 'total_amount'. The given time is taken after
executing several times the same script.
Having a look on postgresql log, we saw numerous queries to
account_tax (always same 3 queries [1][2][3]): each one is called 2700
times.
For now, our workaround is too hide amount fields on trees to keep
acceptable user experience.
For information, the given results are for a server ran on Debian 5.0,
with Core 2 Duo 2300MHz/512 Mb RAM. We have same results with a Ubuntu
9.04 with Core 2 Duo 2300MHz/3Gb RAM.
[1] SELECT date_trunc('', create_date) AS
create_date,"sequence","invoice_tax_sign","write_uid","create_uid","credit_note_base_sign","group","invoice_account","credit_note_tax_code","template","percentage","type","parent","company","invoice_tax_code",date_trunc
('', write_date) AS
write_date,"active","invoice_base_sign","credit_note_account","credit_note_base_code","credit_note_tax_sign","amount","invoice_base_code",id
FROM "account_tax" WHERE id IN (0) AND (((((("account_tax".company =
0)))) AND true));
[2] SELECT "account_tax".id FROM "account_tax" WHERE
(("account_tax".parent IN (0)) AND ("account_tax".active = E'')) AND
((((("account_tax".company = 0)))) AND true) ORDER BY
"account_tax".sequence ASC,"account_tax".id ASC;
[3] SELECT "description",id FROM "account_tax" WHERE id IN (0) AND
(((((("account_tax".company = 0)))) AND true));
Cédric Krier
>
> Hello,
>
> We are experiencing quite worrying performance issues with tryton-1.2,
> especially on purchase and account_invoices modules.
>
> We have a database with about 2600 purchase orders and 45000 purchase
> order lines.
>
> Reading 80 orders (1350 lines) takes more than 9 seconds (measured
> with a script) for following fields: 'reference', 'untaxed_amount',
> 'tax_amount' and 'total_amount'. The given time is taken after
> executing several times the same script.
>
> Having a look on postgresql log, we saw numerous queries to
> account_tax (always same 3 queries [1][2][3]): each one is called 2700
> times.
This is improved a lot on 1.3 with the cache on cursor.
In my test, I have only one query of each kind for 10 purchase orders.
PS: This kind of technical discussion should go on tryton-dev.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email: cedric...@b2ck.com
Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/
Cédric Krier
>
> PS: This kind of technical discussion should go on tryton-dev.
>
Or better, it should be an issue on roundup [1]
Cédric Krier
> >
> > Hello,
> >
> > We are experiencing quite worrying performance issues with tryton-1.2,
> > especially on purchase and account_invoices modules.
> >
> > We have a database with about 2600 purchase orders and 45000 purchase
> > order lines.
> >
> > Reading 80 orders (1350 lines) takes more than 9 seconds (measured
> > with a script) for following fields: 'reference', 'untaxed_amount',
> > 'tax_amount' and 'total_amount'. The given time is taken after
> > executing several times the same script.
> >
> > Having a look on postgresql log, we saw numerous queries to
> > account_tax (always same 3 queries [1][2][3]): each one is called 2700
> > times.
>
> This is improved a lot on 1.3 with the cache on cursor.
> In my test, I have only one query of each kind for 10 purchase orders.
A possible solution would change compute on account.tax to accept
BrowseRecord, add on get_tax_amount a cache of BrowseRecords for account.tax
and use the cached BrowseRecords to call commpute.
Mathias Behrle
2009 21:25:28 +0200):
> > We are experiencing quite worrying performance issues with tryton-1.2,
> > especially on purchase and account_invoices modules.
> >
> > We have a database with about 2600 purchase orders and 45000 purchase
> > order lines.
> >
> > Reading 80 orders (1350 lines) takes more than 9 seconds (measured
> > with a script) for following fields: 'reference', 'untaxed_amount',
> > 'tax_amount' and 'total_amount'. The given time is taken after
> > executing several times the same script.
> >
> > Having a look on postgresql log, we saw numerous queries to
> > account_tax (always same 3 queries [1][2][3]): each one is called 2700
> > times.
>
> This is improved a lot on 1.3 with the cache on cursor.
> In my test, I have only one query of each kind for 10 purchase orders.
Just adding another experience from 1.3:
In a database with about 6000 parties I am experiencing a rather sluggish
display when browsing through the records, while searching for subsets is
tolerable.
Amazing fact is, that it is not only on forward browsing through the list, but
also backwards and it seems not to change. Shouldn't the already browsed data be
in the cache or how big is the cache?
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://mbsolutions.selfip.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x89BCA161
Cédric Krier
> Just adding another experience from 1.3:
> In a database with about 6000 parties I am experiencing a rather sluggish
> display when browsing through the records, while searching for subsets is
> tolerable.
> Amazing fact is, that it is not only on forward browsing through the list, but
> also backwards and it seems not to change. Shouldn't the already browsed data be
> in the cache or how big is the cache?
It is and it is as big as the host memory.