Redmine performance
Added by ashraf alzyoud over 2 years ago
Maximum number of concurrent requests in redmine?!?! As example 500req/sec
What the best congratulations in MySQL,Nginx with passenger to best performance?!?
Replies (3)
RE: Redmine performance - Added by Holger Just over 2 years ago
This heavily depends on your specific configuration of Redmine, which functions of Redmine your users are using, your database as well as your server and network hardware.
In general, a lot of the time required to answer requests in Redmine is taken within the database while querying for the required data. As such, you should make sure that your database server
- has enough hardware resources, specifically enough memory
- is actually configured to use those resources (many database servers are configured to use only a very limited amount of hardware resources by default)
- has enough CPUs available to handle the load without peaking at 100% load
Afterwards, you have to configure the application server; you mentioned Passenger here.
Here, the most important metric to achieve a high throughput is the available concurrency, that is the number of requests which can be answered in parallel. With Redmine, this usually boils down to the number of worker processes configured. Each worker process can answer a single request at a time. How many processes you can configure here heavily depends on the available hardware resources. This is mostly determined by:
- the amount of available memory - Each worker process should have at least 250 MB available. Depending on your configuration, number of plugins and usage patterns, this can grow up to 1 GB per worker process
- the available CPU resources - A rough rule of thumb is to run up to 2-4 workers per CPU core, but this can vary depending on your usage patterns
The application server (i.e.passenger) is mostly stateless. That means, you can scale these processes up with a simple loadbalancer over multiple servers if required. Here, you just have to make sure that all application servers run the same code and configuration.
As for expected performance: a single (dynamic) request usually takes between 10ms and 100ms. Depending on your exact configuration and usage patterns, this can grow up to multiple seconds for some requests. This may giove you a first insight onto how many resources are required for your performance goal. You may have to monitor your actual usage and improve areas which appear slow. Requests to static assets such as stylesheets, javascript files, ... are handled by nginx itself and do not affect the performance of Redmine. They should be quite fast.
With that being said, 500 (dynamic) req/s are A LOT. Unless you are running a huge and incredibly busy Redmine installation with several thousand users accessing your Redmine at the same time, you will likely get away with 5-10% of that.
RE: Redmine performance - Added by ashraf alzyoud over 2 years ago
Thx brother a lot for your answer
My hardware
Ubuntu 20.04
24 cpu
32 gig ram
1 Tera hard disk
I think I will have 100 user online
My question?!?
Nginx.cong mysqld what the best configuration to
Handle the req/sec?!
RE: Redmine performance - Added by Holger Just over 2 years ago
You have to read the documentation of the various components to learn what you can optimize and how this affects the respective components. There are a lot of guides out there on how to improve performance of some components for certain workloads. There is no one-size-fits-all approach; you have to define yourself what your specific goals are, how you can measure those, and how you decide between diverging goals (such as cost vs. performance, CPU use vs. memory use, memory use vs IOPS, throughput vs. latency, ...).
Some starting points for documentation are:
Before attempting any optimization steps, you have to make sure that you have a functionally complete system in any case. It's useless to try to optimize a system that does not work (yet). Thus, start with a basic functional configuration and work from that. When changing the configurations, make sure to change only a single setting at a time and the measure whether it has either improved things, made things worse, or didn't matter at all. Usually, it's a good idea to only keep settings changes from their respective default configurations if this has resulted in meaningful improvements.