Hi Rob,

our largest (known) active single installation with regards to project size is running with roughly 4000 projects, 10.000 users and a quarter million work packages.
The underlying hardware is balanced on several application servers with 16G RAM each and a shared MySQL cluster. It is used daily by several hundred users, although mostly within few projects.

As our application is forked from Redmine, and some of the older views are not correctly paginated thus will scale linearly.
The views you mention are good examples and may cause additional seconds to load with thousands of projects. However, we’re slowly rolling out changes in major versions to dry out these unpaginated views. The latter one you mentioned is being reworked into the paginated project list currently available at /admin/projects, which
scales just fine.

We do know the pain points of the application regarding scalability of projects (and types, custom fields) and are actively working on making the application behave better
on larger scale.

Let me give you a glimpse on the issues that come to my mind. This might give you a quick overview over the pain points we know and are working on sooner or later, if possible.

- ‘Projects’ partials in the administration. This happens for Users > Memberships, Groups > Projects Types > Projects, Custom Fields. These could be solved with a simple autocompletion which projects are available.

- /projects page. Is being consolidated with /admin/projects (with a customizable table) in a future release, possibly OpenProject 8.0 (next major release after 7.0).

- ‘Project’ dropdown in work package is a simple <select> and does not scale well (usability-wise) above 50 entries, performance-wise somewhere around 500/1000 entries depending on your client. Needs to be replaced with an autocomplete.

- Global work package page. Depending on your permissions, lots of additional data needs to be processed (especially schemas, which are bound to each project and type combination), and may cause in increased loading times. This is not easily fixed, however most users will likely never use that global view anyway.

- (Global) Activity view is not performant to the way of activities being aggregated in Ruby. This is still redmine code.

We do welcome all feedback regarding performance of the application, and even more so appreciate contributions on the various small fixes that improve performance, often caused by
naive usage of Rails’ activerecord (partially dating back to redmine code), leading to N+1 queries and unnecessary work.

Best,
Oliver

Oliver, thank you so much for your detailed and transparent response! It gives me a lot of confidence in using OpenProject over the long-term.

System resources are not an issue for the project I have in mind, so PO is looking to be a good fit. I wonder, if there were only 100 active projects at a time (ie - the remaining of the thousands would be archived) would performance be a bit better as a result? This would actually be our working process, not as an effort to optimize performance. I’m just asking to have a better understanding.

Thank you.

I wonder, if there were only 100 active projects at a time (ie - the remaining of the thousands would be archived) would performance be a bit better as a result?

Yes. Archived projects are excluded in all of the affected views. That would be a good workaround.

Best,
Oliver

Great, and thank you Oliver.