Hello Lin,
we worked indirectly on a case in the USA with 1/10
of the numbers you mentioned. And we had terrible
issues. Just to be clear we were called as firemen and
didn't had a chance to study things upfront on that
project. Well basically, 2 things became extremely
slow: workflows because tables were huge and stock
moves (that was on 6.1) because millions of move to
crawl to compute any stock level.
On v8, there is good hope that the stock
scalability issue is gone. As for the workflows I'm
afraid I'll probably still have issues: all workflows
use the same tables and open workflow instances of
sale, stock, account accumulate. My advice is: if it's
on a version prior to v8, forget it because of the way
the stock moves work. If it's on v8, well in any case
plan some very serious optimizations and testing to
see feasibility.
Number of concurrent users isn't too hard to tackle
by adding more cores now that we have process based
parallelism, but as for very large tables, well you'll
have to clean them up often, you'll have tweak
indexes, probably to bypass some computations and use
some custom SQL, add caching...
I never heard about sharding in OpenERP/Odoo so I
guess nobody ever did sharding, so don't assume it
would be easy like in frameworks where it's being
done...
As for the company we worked for, well, after 18
months they ended up dropping OpenERP for SAP.
Probably putting way more money on it than trying
again on v8 and paying a lot of engineering to get the
things optimized, but still it's the decision they
took and scalability was one of the main reasons and
that was 1/10th of the figures you mentioned. So don't
take that challenge lightly and good luck!
Regards.
--
Raphaël Valyi
Founder and consultant
+55
21 3942-2434
![]()
