openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

When I said "clean tables", I should have been more explicit: if you crawl
the bug tracker, you'll notice a good quantity of bugs with workflows that
don't close properly when some conditions are meet. This also really depend
on being organized. If you are not properly organized, workflows of
business documents will stay open not even because of bugs but just because
of incomplete processes.

In any case, it's critical to watch out the number of business documents
with an open workflow as it's these that accumulate in the common workflow
table and will make the workflow engine struggle in critical ways. So if
you don't know what to test to get an idea of the feasibility, test this:
create millions of business documents with thousands with an open workflow
as it will definitely be one of the bottlenecks in your case.

Regards.

-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 3942-2434
www.akretion.com



On Sun, Aug 24, 2014 at 11:43 PM, Raphael Valyi <rvalyi@xxxxxxxxx> wrote:

> 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
> http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
> +55 21 3942-2434
> www.akretion.com
>
>
>
>
> On Sun, Aug 24, 2014 at 10:21 PM, lin.yu <lin.yu@xxxxxxxxxxxxxx> wrote:
>
>> Hello Community,
>>
>>
>> We have a potential lead which has a volume of daily 20000 sale orders
>> and 50000 sale order lines from Magento, which will probably result in a
>> daily 100000 or 200000 stock moves, 3000000 stock moves per month.
>>
>> I would like to ask that has anyone experience on Odoo/OpenERP with that
>> daily volume? How about the performance after one month?
>>
>>
>> I would like also to ask if you have any module on
>>
>> * archive stock move , sales order, and other objects
>>
>> * sales forecasting
>>
>>
>> BR,
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>