when multiple user login then after some time ASP.Net C# Application get slow

Question

在应用程序中，所有sql连接均正确关闭，此外，当用户注销其连接时，仍会在内存中增加sql进程内存，并在一段时间后使应用程序变慢。

Answer 1

@Shrik: SQL Server is a class A memory user - by design. By default, it is setup to take all the memory it can grab. It will actually move data from disk into physical memory - so that future accessing of this data will be much faster.

When the sql server service sits on its own box - well, that's not much of a problem. But when other apps are trying to run on that box - serious resource bottlenecks occur. This scenario is what I'm reading between the lines in your discussion.

If your app(s) are running on the SQL box, and performance is suffering whenever sql server starts 'doing its thing', either: Limit the # of memory sql has available to it (not so good) or give sql server its own box.

If your sql server is already on its own box, the first place that I would do to differentiate where the 'slowness' is originating is to run a typical 'slow' query / statement - both from the app & from SQL Server, through SSMS. So very not high tech, I know, but so very telling. If the query is quick and nimble through SSMS, then leave the DBMS alone, and focus on the app and network physical / soft layers. If the query is not so good - then look @ the SQL Server.

If it is sql server, my quess is that you have a poorly performing query, with, the way that you are describing it, gets worse as the app progresses, but does better after the app restarts? ( which btw, if a restart of the app, but not Sql Server 'fixes' the problem, it is likely an app problem ).

And as always, logs are your friend! See what SQL Server is saying. For instance, your app might make heavy use of SQL CLR. When an assembly is called for the first time, it is SLOOOOW. Second time, FAST. SQL Server manages its memory spaces, and sometimes, it will push assemblies out of memory. Next time the assembly is called - guess what the user's experience is? SLOOOOOW. Guess where one can see if SQL Server is pushing assemblies from memory?

Let's try some of this troubleshooting, you post the results and I bet someone can help you out a bit more. Remember - ANY logs, error messages, or hard data that you can give us will really help us answer your questions.

Good luck!

Answer 2

Are you using the default SqlMembership providers? Or did you craft something on your own? If it's option 2 I suggest you start profiling your code and stress test it. You can also use SQL Profiler to see what's being sent to the database. You can also use sp_lock or the newer sys.dm_tran_lock to see if there's row locking somewhere.

Are there some other processes running on the same server which could cause SQL Server to not get enough ram to work properly? Sysinternals have some great tools to check these.

Answer 3

This question is vague. Are you talking about application logins using a SQL Server-based provider, or logins to the actual database server itself (via Management Studio or something similar)?