In my environment in[banking domain ] which my application is running with [.net and sql server 2005 ]1. in my deep monitoring from 9 months i have seen maximum of 420 concurrnet users in the job activity monitor.

2. due to the most hits from the concurrent users " tempdb " issues happend so many times later we increased more space to tempdb (files ) containing drive .

3. in this mean while before increasing space i workedout as per microsoft recommendations 16 processors should run in 24 gb ram but in my environment it is runig in 2gb instead of increasing the ram sapce is allocated for tempdb

4. to solve the rapid growth of tempdb in most concurrent users

5. i have link sorry to say this activity happend before 6 months but iam unable to find that mail once i found i'vl send by that u can see the process to check details of processors using ram

6. depending on the first point i said " you calculate as per ur requirement "

Mohan Kumar VS (3/2/2010)Our application will be used by 3200 concurrent users in the near future.

I'm in agreement with Rohit. Chances are the base statement for capacity planning is tainted - hard to believe an application handling 3200 concurrent users is managed as lightly as this one appears to be.

Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.

Thank you very much for your response. The requirement was for a government project and the details were provided by the IT team over there. Right now I'm not working with that organization. Thanks again.

Keep in mind that 3200 people connecting to your application (web or thick client), don't mean 3200 connections to SQL Server. Usually those connections come and go.

However user connections don't give you any idea for load unless you know what they're doing. One user can fill tempdb or use up all the memory.

What you need to do is profile the application, and get an idea of the load from different use cases. Then scale those up. SQL Server 2005 can definitely handle large loads, though I'm not sure why you wouldn't at least use 2008 R2 if not 2012.