CODEWITHSUNDEEP
djangomultithreadingnginxconcurrencygunicorn
Temi
Temi

Reputation: 257

Optimising Gunicorn Configuration for High-Concurrency I/O-Intensive Tasks with Low CPU and Memory Usage

I'm currently managing a Django application hosted on a 16-core server. Despite having 25% maximum CPU and memory usage, performance starts to degrade at around 400 active connections according to Nginx statistics. Currently, we have 12 Gunicorn workers, which is lower than the recommended (2 * CPU) + 1. However, as per Gunicorn's documentation, 4-12 workers should handle hundreds to thousands of requests per second.

  1. Question about Worker Configuration: Has anyone successfully used a number of workers exceeding the 12 as mentioned, especially in scenarios with low CPU and memory usage? Any insights into optimal configurations for high-concurrency scenarios in such situations?

  2. Performance Optimization: Our application primarily involves I/O tasks. Despite optimizing database queries and having low CPU and memory usage, performance remains an issue. Would increasing the number of workers or introducing threads (summing up to (2 * CPU) + 1) be a viable solution for improving performance in I/O-bound scenarios with seemingly underutilized resources? This means setting workers to 33 if I use (2 * CPU) + 1, or maybe 10 workers with 3 threads?

  3. Additional Considerations: We are considering tweaking Gunicorn configurations, but want to ensure we're on the right track given the low CPU and memory usage. Are there any other considerations or best practices for optimizing Gunicorn for I/O-intensive workloads in scenarios where resource usage is not fully utilized?

Any advice, experiences, or recommendations would be greatly appreciated. Thank you!

Upvotes: 1

Views: 1976

Answers (1)

TanThien
TanThien

Reputation: 742

  • First your point: Your application run I/O tasks, so It's a I/O bound and your server 'll use not much cpu. A larger number of workers is not necessarily better. With a I/O bound application, you can use gevent worker. gevent is the best choice when you need concurrency and most of your work is I/O bound (network calls, file access, databases, etc…).

  • Second: Most of the server's work is querying to database so database, so the database is where the processing takes place and requires CPU not your django application. Instead of increasing the number of workers, you can check your driver database can use async mode

  • Final: You just need to pay attention to three parameters: mode worker, number worker, number threads to serving amount requests. Here a old post about type worker: post

Upvotes: 1

Related Questions