Comment by osbre
1 year ago
But wouldn't using a connection pool solve this problem of "stressing out the database"? I assumed a single connection from the pool would be considered "occupied" until we hear back from the database.
Or are you saying that processing lots of requests/tasks in Rails while waiting for the database would quickly eat up all the CPU? It seems like a good thing - "resource utilization" = servers should do things whenever possible rather than just waiting. Although now that I think about it you'd only want maximum resource utilization if your database is on a separate server.
With the database it depends on specific queries. Ideally, you can hammer it and it will be fine.
If you have inefficient queries, N+1 problems, competing locks, full table scans, temp tables being generated, etc then more concurrency will amplify the problem. Thats all I meant.