B
Bob
We have a production web site that's data intensive (save user input to DB
and query for displaying) with the ASP.NET app part on one W2K server and
SQL 2000 DB on another W2K server. I have set up performance logs to log #
of pooled database connections on the web server every 60 seconds (.NET CLR
Data(_global_)\SqlClient: Current # pooled connections). The # of
connections is constantly higher than the # of active ASP.NET sessions.
E.g. right now there are 25 connections and 18 active session. Is this
normal? I would think the # of pooled DB connections shouldn't be higher
than the # of active sessions since the connections in the pool are shared
and user certain pauses between loading pages and entering data.
Last year during peak usage when the # of active sessions got around 180 and
# of connections peaked at around 150, the SQL Server experienced deadlock
as too many processes were waiting for one another. User experience was
very bad during that period needless to say. We redesigned the data layer
and made very sure that every call to the database closes the connection
explicitly. So I'm concerned that the effort didn't resolve anything and am
afraid the same problem would happen again. All the calls to the database
are straightforward, no transactions involved.
Could anyone point out what the potential problems we might have?
Thanks a lot
Bob
and query for displaying) with the ASP.NET app part on one W2K server and
SQL 2000 DB on another W2K server. I have set up performance logs to log #
of pooled database connections on the web server every 60 seconds (.NET CLR
Data(_global_)\SqlClient: Current # pooled connections). The # of
connections is constantly higher than the # of active ASP.NET sessions.
E.g. right now there are 25 connections and 18 active session. Is this
normal? I would think the # of pooled DB connections shouldn't be higher
than the # of active sessions since the connections in the pool are shared
and user certain pauses between loading pages and entering data.
Last year during peak usage when the # of active sessions got around 180 and
# of connections peaked at around 150, the SQL Server experienced deadlock
as too many processes were waiting for one another. User experience was
very bad during that period needless to say. We redesigned the data layer
and made very sure that every call to the database closes the connection
explicitly. So I'm concerned that the effort didn't resolve anything and am
afraid the same problem would happen again. All the calls to the database
are straightforward, no transactions involved.
Could anyone point out what the potential problems we might have?
Thanks a lot
Bob