Performance and scalability: db connection pool size & concurrent users
for an application that heavily accesses the database, should the connection pool size equal the number of concurrent users you want to support? for example, if i want to support 500 concurrent users, what should my db pool size be?
- Posted by: red dre
- Posted on: April 02 2004 17:32 EST
- db connection pool size & concurrent users by Sean Sullivan on April 02 2004 18:41 EST
- Re: db connection pool size & concurrent users by Andreas Berg on April 03 2004 13:26 EST
- db connection pool size & concurrent users by Michael Foley on April 05 2004 16:05 EDT
When you say "500 concurrent users", do you mean:
A) 500 concurrent sessions
B) 500 concurrent HTTP requests
Do you have a cluster of app servers or a single app server?
500 concurrent http requests. the site will have 20000 users. currently we are using a single appserver. I would also appreciate some tips on load testing, like some good trialware or free tools. right now, we are using the ms web stress tool to simulate users.
for an application that heavily accesses the database, should the connection pool size equal the number of concurrent users you want to support? for example, if i want to support 500 concurrent users, what should my db pool size be?It all depends...
You say you have 500 concurrent http requests. How much of the time of processing the requests is spent on database connectivity? If a typical request spends 50% of its time doing calculations and 50% on database connectivity you might only need 250 connections in your pool. Of course your application should release the db connection as early as possible.
In general holding a connection is not expensive for a database (while creating a new one is quite expensive). It should be no problem to keep the size high enough.
Load testing: If you have a web application with such a high number of concurrent users, I think there is no way around using a professional and supported (!= trial) load testing product.
yes, it depends.
you want the connection pool big enough so that you never run out of connections in the pool....but no bigger. this size will depend on the application and usage patterns. i suppose it is even possible to need more connections than users if each session is running multiple sql statements.
running realistic multi-user use-case scenarios ...with wait times...for the mix of user activities you expect will likely require a good tool such as mercury interactive's loadrunner. there may be usage spikes in the morning...say when everybody logs in...or on friday...or at the end of a fiscal quarter that you need to account for. also, how you set assumptions...such as wait times...can also vary your results a good deal.