I'm using 5.0.0.3 client and server. I had the same problem in the web
client and the GTK client. I just (about ten minutes ago) dumped the
database and reloaded on a different machine. Production system, CentOS
5.2, python2.4 and postgresql8.1. The machine I restored to is Fedora 10,
python2.5 and Postgresql8.3. No delay problem at all on the new machine.
I'm going to turn on what you recommended and see what is going on.
On Wed, 6 May 2009, [email protected] wrote:
Guys, can you confirm this is using v5?
Because if that's on v4 that possible. But in v5, the new MPTT SQL modeling
makes it insanely fast to compute stocks and vitual stocks for any location so
I don't think that's the problem.
Those kind of problem can also arise in badly code fields.function (no
store=True, slow computation or many2one field forgetting to answer the name
along with the id to avoid subsequent GTK client requests). Ways to detect
those last kind of bugs are:
- activate your GTK client logs (-l debug_rpc),
- activate your SQL bugs,
- look if using the webclient has the issue two.
- decrease the number of records per list view in the action window and see how
it impact tree to form view load time.
Don't forget, the GTK client assume you can load n entity in an O(1) or
O(log(n)) time. If one of your field doesn't respect this you are caught. Using
the smart filed.function store abilities you can generally achieve such
properties.
Thank you for your feeback. Also please notice that we have at least one
customer in prod on v5 with lots of moves + locations (fleet_maintenance
module) and no such problem is seen. It's just damn fast.
Rapha??l Valyi
------------------------
http://www.smile.fr
-------------------- m2f --------------------
--
http://www.openobject.com/forum/viewtopic.php?p=35933#35933
-------------------- m2f --------------------
_______________________________________________
Tinyerp-users mailing list
http://tiny.be/mailman/listinfo/tinyerp-users
