Community mailing list archives
Re: Largest implementation of Oodoby
The Portuguese Ministry of Education adopted OpenERP as an RAD platform to replace 150 applications, and can have 50 000 concurrent users at peak usage.
ThinkOpen Solutions has case study about it.
This is the link to the article (in portuguese, but tehre could be an english version):
You should try contacting them for more information.
Our largest customer has about 120 users across 109 locations using sales, distribution, finance etc (ie a good spread of modules)
Contact me if of use
ERP Capability Manager
Mobile +64 22 651 3753
Phone +64 9 977 5805
Solnet Solutions Limited
Level 19, Crombie Lockwood
191 Queen Street, Auckland 1010
PO Box 6619, Auckland 1141
Is there any record of largest implementation of Oodo in any part of the world?
One of my prospect has a large customer base and is considering using Oodo sales and marketing modules. As I see this post I am prompted to ask this question.
I am interested to know the number of concurrent users using sales and marketing modules or any other module for that matter.
Also, on what hardware and software platform with specification of capacity and versions?
Appreciate your help in advance.
Sent from my iPad Air
On 22 Feb 2016, at 7:47 AM, Jason / 崔建平 <firstname.lastname@example.org> wrote:
Indeed, check the CPU utilization as well.
We have encountered cases where CPU reached 100% when logging in or running some other apps. Tweaking memory allocation and postgresql could relieve by some extent but not fully fixing it.
Previous posts from mailing list members mentioned that misconfigured email server settings drove CPU usage to 100%. The same is true to other configurations, say, loading google fonts makes server slowdown in China as google services are blocked from within China. There could be more unidentified causes to downgrade server performance.
Qingdao Oudu Software
From: Houssine BAKKALI [mailto:email@example.com]
Sent: Saturday, February 20, 2016 6:08 AM
To: Community <firstname.lastname@example.org>
Subject: Re: Online Journal entries and vice versa very slow as compare to local host
RAM is not the only parameter that could matter on perf. The disk, SSD of HDD, is also important.
Then you should also have a look at your server configuration and check if your server is up to date.
Vouching Abdul Qudoos Mehdi's Statements !
We are also facing such issues.
#1. We had deployed Odoov9 in Ubuntu 14.04 LTS at first and now in CentOS 7. In both the cases we have used 8GB RAM.
Time taken for the landing page after Login is 30 seconds and consecutive Login 25 seconds.
This worsens if there are multiple logins.
#2. How many concurrent users are possible?
#3. How many users are possible?
On Fri, Feb 19, 2016 at 1:56 PM, Abdul Qudoos <email@example.com> wrote:
We are using Accounting module of Odoo 9 in our company. First we installed it on linux VPS with 512MB RAM. It was very slow in performance. So we changed the VPS. Now we installed Odoo 9 on windows VPS with 4 GB RAM, and other specifications are also very good but still it is very slow. We have only one accountant who enter journal entries. We only install Accounting module in it. when second person try to login to Odoo, the server become too slow to open anything, even we check at that time server statistics, normal RAM was going to use.
Some one told me that you have to tune your Odoo database. What does it mean and if this is the solution then how can I do it?
Can anyone give me best solution for this problem?
First priority is to set Odoo 9 in existing VPS.
And what should be the VPS specs for 1 to 5 users?
Abdul Qudoos Mehdi
Stephen Raj D,
Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or firstname.lastname@example.org as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd.