[6.0] dashboards display intempestively after you started navigating

[Raphaël Valyi - http://www.akretion.com]

This is web client rev #4386 with a real production database (over 10 000+ orders/expeditions). It happens that on this database with real data, dashboards are rather slow to appear (I hope I'll be able to report an other bug about that poor performance, mostly visible in sale and stock dashboards).

So, a natural behavior from the user, is to start navigating using the left menu while the dashboard is stuck.
The user may start clicking on the left menu elements and would expect the central content will display accordingly to those left menu choices.

Still, this is not the case: a few seconds later, when the dashboards is finally ready to load, the dashboard will display in the central content, no matter your navigation choice, this is a rather confusing user experience and very time consuming as it force you to wait forever for the dashboards to load for almost any trivial operation.

[Ferdinand (office-chricar)]

IMHO dashboards will always be a performance issue-
pls see
https://answers.launchpad.net/openobject-client-web/+question/125890

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Ferdinand,

Thanks for your considerations.
Some ways to avoid useless dashboard, might be to customize the home action indeed or put something that make sense for your usage in those dashboards.

But still, I think it's yet an other problem - in the Javascript event model - that even if you start navigating away from those fancy useless dashboards, they will appear again in the center panel and break your navigation experience.

NB: also, the other issue about the default sale and stock dashboards, is that they make really slow SQL queries (here like 10+ sec to complete on good modern hardware) which makes this issue even more important.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Devishree,

sorry, but I don't really understand why you can that an opinion and not a bug.
To illustrate the issue, I've attached one of the SQL log that is is produced by the regular stock dashboard on a real production database. I'm here logging queries longer than 0.1 seconds. When you'll see the query (here attached), you'll understand why it's actually a lot slower. It's also slow to transmit back to the browser and make the Flash diagrams leak the client CPU for a while.

I could produce similar logs for the sale dashboard at least.

[xrg (xrg)]

On Sunday 30 January 2011, you wrote:
> ** Attachment added: "stock_logs.txt"
>
Is that log suggesting that you have hundreds of stock locations? How come?

I don't claim that there is any "invalid" or "oversize" number for any of the
ORM tables, but production examples of sizing will help us to take better
design decisions about the internals.
For example: (fictional) we think "ok, a partner may have 2-3 different
adresses, let's not worry to optimize loops out of partner->address
matchings". And we write simple python code about that[1]. Then, some
production database comes over with 4000 adresses on one partner. And, of
course, performance suffers there. Hence your "bug".

Giving us simple statistics, like "I have setup a supermarket database with:
 - 5000 products
 - 18000 pricelist entries
 - 40 warehouse locations and 1200 shelves
 - 120 employees
 - 50 accounting journals
 - 2000 cash moves per day..
 - expected printing of POS invoices in <2sec
 - ...
"
will help us do dimensioning analysis. Perhaps not only us, but even yourself,
to setup a testing system that will catch common pitfalls before deploying on
a customer.
I'd be glad to assist anybody that tries to setup such a testing system
(infrastructure, I would call it).

[1] that's a common practice from people that think Python, Java, Ruby can be
fast languages, compared to SQL.

[Cristian Salamea (ovnicraft)]

@Xrg I am working in implementation the system has purchases with 800 different items, the creation of picking and invoice its over 12min and approve the picking takes +20min i think is a bad performance how can you help me here?

Regards,

[Albert Cervera i Areny - http://www.NaN-tic.com (albert-nan)]

Good idea xrg. Here are some numbers of a customer in production with OpenERP
v5:

- 11500 total locations
- 17000 products
- 9200 bills of materials
- 1000 stock moves per day
- 80 account moves / 500 account move lines per day

A Diumenge, 30 de gener de 2011, xrg va escriure:
> On Sunday 30 January 2011, you wrote:
> > ** Attachment added: "stock_logs.txt"
>
> Is that log suggesting that you have hundreds of stock locations? How come?
>
> I don't claim that there is any "invalid" or "oversize" number for any of
> the ORM tables, but production examples of sizing will help us to take
> better design decisions about the internals.
> For example: (fictional) we think "ok, a partner may have 2-3 different
> adresses, let's not worry to optimize loops out of partner->address
> matchings". And we write simple python code about that[1]. Then, some
> production database comes over with 4000 adresses on one partner. And, of
> course, performance suffers there. Hence your "bug".
>
> Giving us simple statistics, like "I have setup a supermarket database
> with: - 5000 products
> - 18000 pricelist entries
> - 40 warehouse locations and 1200 shelves
> - 120 employees
> - 50 accounting journals
> - 2000 cash moves per day..
> - expected printing of POS invoices in <2sec
> - ...
> "
> will help us do dimensioning analysis. Perhaps not only us, but even
> yourself, to setup a testing system that will catch common pitfalls before
> deploying on a customer.
> I'd be glad to assist anybody that tries to setup such a testing system
> (infrastructure, I would call it).
>
>
> [1] that's a common practice from people that think Python, Java, Ruby can
> be fast languages, compared to SQL.

--
Albert Cervera i Areny
http://www.NaN-tic.com
OpenERP Partners
Tel: [phone]

http://twitter.com/albertnan
http://www.nan-tic.com/blog

[Ferdinand (office-chricar)]

well - IMHO the dashboards in web client should (and can ) be disabled - these are visual gimmicks of no real use in day2day work - at least I know nobody who wants to see these statistics evertime he/she changes form accounting to sales and back.

All these boards seem not to take into account company_id. Hence these reports show data of ALL companies even if the users has no access rigths to these companies (hopefully I am wrong, but I do not see any domain restriction)
BTW the most efficient way to restrict the access is to rewrite/extend the underlying views and NOT using (unnecessary) domains
I must admit, that I didn't examine how to pass uid and/or company_id to these queries.

If someone wants to open dashboards he will do it.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

@xrg,

1) We see sale and warehouse dashboards being the major performance
bottleneck in nearly all our 5 V6 deployments, not only this particular case
which as indeed some 1 000 locations (an online bookstore managing supplier
and customer consigned sales).

2) I insist, here my report is not only about only the slowness. But it's
also about the fact the user cannot skip the dashboard display: even if he
starts navigating away from that back hole, minutes after the dashboard is
finally ready, his navigation will be destroyed and bring back to those
useless dashboard, making web-client almost unusable in practice until you
edit those dashboards to drop their content.

3) I think you can look with Olivier Laurent: one of your 2nd level
migration customer you just migrated just facing this issue on v6 and you
have the database so you can study it.

On Sun, Jan 30, 2011 at 2:58 PM, Ferdinand @ Camptocamp <
<email address hidden>> wrote:

> well - IMHO the dashboards in web client should (and can ) be disabled -
> these are visual gimmicks of no real use in day2day work - at least I
> know nobody who wants to see these statistics evertime he/she changes
> form accounting to sales and back.
>
> All these boards seem not to take into account company_id. Hence these
> reports show data of ALL companies even if the users has no access rigths to
> these companies (hopefully I am wrong, but I do not see any domain
> restriction)
> BTW the most efficient way to restrict the access is to rewrite/extend the
> underlying views and NOT using (unnecessary) domains
> I must admit, that I didn't examine how to pass uid and/or company_id to
> these queries.
>
> If someone wants to open dashboards he will do it.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/704394
>
> Title:
> [6.0] dashboards display intempestively after you started navigating
>
> Status in OpenERP Web Client:
> Opinion
>
> Bug description:
> This is web client rev #4386 with a real production database (over 10
> 000+ orders/expeditions). It happens that on this database with real
> data, dashboards are rather slow to appear (I hope I'll be able to
> report an other bug about that poor performance, mostly visible in
> sale and stock dashboards).
>
> So, a natural behavior from the user, is to start navigating using the
> left menu while the dashboard is stuck.
> The user may start clicking on the left menu elements and would expect the
> central content will display accordingly to those left menu choices.
>
> Still, this is not the case: a few seconds later, when the dashboards
> is finally ready to load, the dashboard will display in the central
> content, no matter your navigation choice, this is a rather confusing
> user experience and very time consuming as it force you to wait
> forever for the dashboards to load for almost any trivial operation.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/openobject-client-web/+bug/704394/+subscribe
>

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Guys,

for several customers in productions, we just drop the dashboards from the entry page as they are too slow for production usage.
This is achieve through our "no-fluff" branch addons:
https://code.launchpad.net/~akretion-team/+junk/addons-no-fluff

Hope this workaround helps some.

[Ferdinand (office-chricar)]

the joy of the day ... +1+1+1+1

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

BTW @xrg: you have such big v6 test database for our customer "Adaptoo" you migrated to v6 with the OPW and where dashboards are extremely slow and this is known by your migration team.

[xrg (xrg)]

Thanks for the no-fluff.. ;)

Of course, I wouldn't expect them to be that slow in my server.