For some reason it takes 7 seconds to open a connection to a sql server database for the firt time, subsequent connections takes a second. any idea what could be the reason?
I'm using C# and asp.net
Its after compilation, i essence every time i restart the site, which means every time it needs to actualy create the "first" connection. i understand that setting up connection pooling has overhead, but i have never seen that i should take 7 second to set it up.
As well as connection pooling and CLR compilation, don't forget that the data and plan caches on the database server could be "cold" too...
I've seen first calls on a very "cold" web site take 5-10 seconds to respond from button click (for example, "search") to the data ending up on screen.
The first time the connection has to be established which has a lot of overhead. Each subsequent connection is using connection pooling (assuming you have the same connection string) and the initial setup does not need to be done.
Edit: see this link or this one for some info on connection pooling.
is this after a compile each time? Is the "lagtime" due to JIT compiling rather than the SqlConnection itself?
Related
I'm building a .NET 4.5 (winforms) application that uses LocalDB to work with a local MDF file, using this connection string:
Data Source=(LocalDB)\v11.0;AttachDbFilename=|DataDirectory|\DB\DatabaseFile.mdf;Integrated Security=True;MultipleActiveResultSets=True
When I run my application, the first SQL query takes some time to execute - nothing drastic, about 2 or 3 seconds. After that, all next SQL queries are executed instantly. I assume that the extra seconds during the first execution are needed to attach the MDF file to a local SQL Server service. Right?
I noticed, however, that if 10 minutes (or so) pass since an SQL query was last performed, the next SQL query will again take those 2-3 seconds more to execute. I assume that after some idle time, the MDF gets detached, and when the new SQL command is called, it re-attaches it once again.
I'm wondering, is there a way to override this behavior?
I know I could create a Timer, that performs a simple query every few minutes, but is there a better, cleaner solution?
Unless you keep the connection open, your LocalDB instance will shut down after a few minutes. It is started again when you connect to it again. That would explain 2-3 second delay. You can tune the shutdown timeout, as explained in this question. Opening a connection every couple minutes is another way to keep it running. There should be no need to even run any queries, but you may need to make sure the connection is opened outside of the connection pool (at least in early versions of .NET the connection pool used to return the connection without doing any ping on it).
You can also disable AUTO_CLOSE option for the database and prevent the cache from being unloaded from the memory. See this detailed blog post on memory management in SQL Server Express, the AUTO_CLOSE part is directly applicable to LocalDB.
I would more suspect that your data / index is no longer in memory.
You could run a very fast query like select 'a' to know if it was the connect time.
As for forcing your table / index to stay in memory.
I would so much advise you to let .NET and SQL do their own memory management.
2-3 seconds is not much.
Look at the query plan - maybe you can make it faster (even not in memory).
Actually I am confuse about one thing.
I have .net application and using sql server 2008 for database.
Now, on my Method A i am filling datareader.
now, during while loop i am calling another method B by pass one property of result.
at that time i also open DB connection & close it.
same thing doing Calling another method C from method B.
at that time also open DB connection & close.
To fill final list of Method A. it is taking time.
so, my point is.To open DB connection & closing it. Is it time consuming process?
To open DB connection & closing it. it is time consuming process
Yes. If pooling is enabled and the connection is returned from the pool then opening and closing costs at least one round-trip, to reset the connection. If the connection is not pooled opening and closing is a full SSPI complete handshake. If SQL authentication is used and encryption is enabled, there is another complete SSL handshake to establish a secure channel before the SQL handshake. Even under ideal conditions, it takes 10s of ms, it can go up to whole seconds with some minimal network latency added.
A well written ASP.Net application needs one (pooled) connection per request, never more.
It is generally very bad practice to connect to a third part application (database, WebService or similar) in any kind of loop. Communication like this is always takes a relatively long time.
As the number of elements in the loop increases the application will become exponentially slower and slower.
A much better approach is to perform an operation for all the elements then pass the required data into your loop logic.
As with all things there are exceptions, loops where you have millions of entities to process and the connection is a small overhead may create circumstances where it's more efficient to process each entity atomically.
I have noticed that it takes a long time in connecting to the database when executing my query. Is it possible to write an asp.net application in such way that has a database connection that is always open? Or is it better to write service and have asp.net app communicate with that service?
You can use connection pooling in order to conserve time it takes to initialize a connection. BTW, SQL-Server supports it OOTB, so you don't really have to implement it yourself.
It does not matter much which means you use to connect to the DB (ADO.NET, DAAB, etc..)
As to your second suggestion, to write a service and have the application communicate requests to it: it wont help in this scenario, since you are simply moving the problem to another process, but the accumulated time of fulfilling a request remains or even grows, considering the extra network time.
I've a C# client application that need to checks a table on a Postgres db every 15 minutes. The problem is that I need to install this client into more or less 200 client so, for that I need to close the DB connection after the query.
I use .Close() method but, if I check on pg_stat_activity table on Postgres DB, I can see the connection still open in IDLE status. How can I fix that issue? Is it possible to close definitely the connection?
thanks,
Andrea
Like most ADO.NET providers, Npgsql uses connection pooling by default. When you Close() the NpgsqlConnection object, an internal object representing the actual underlying connection that Npgsql uses goes into a pool to be re-used, saving the overhead of creating another unnecessarily. (See What does "opening a connection" actually mean? for more).
This suits most applications well, as it's common to want to use a connection several times in the space of a second.
It doesn't suit you at all, but if you include the option Pooling=false in your connection string, it will override this default, and Close() will indeed close the actual connection.
Currently there is discussion as to what are the pros and cons of having a single sql connection architecture.
To elaborate what we are discussing is, at application creation open a sql connection and at application close or error closing the sql connection. And not creating another connection at all, but using just that one to talk with the DB.
We are wondering what the community thinks.
Close the connection as soon as you do not longer need it for an undefined amount of time. By doing so, the connection returns to the connection-pool (if connection pooling is enabled), and can be (re)used by someone else.
(Connections are expensive resources, and are sometimes limited).
If you keep hold on a connection for the entire lifetime of an application, and you have multiple users for that application (thus multiple instances of the app, and multiple connections), and if your DB server is limited to have only x number of concurrent connections, then you could have a problem ....
See also best practices for ado.net
Follow this simple rule... Open connection as late as possible and close it as soon as possible.
I think it's a bad idea, for several reasons.
If you have 10,000 users using your application, that's 10,000 connections open constantly
If you have to restart your Sql Server, all those 10,000 connections are invalidated and your application will suddenly - assuming you've included reconnect logic - be making 10000 near-simultaneous re-connect requests.
To expand on point 1, you should close connections as soon as you can because otherwise you're using up a finite resource for, potentially, an inifinite period of time. If you had Sql Server configured to allow a maximum of 10,001 simultaneous connections, then you can only have 10,001 users running your application at any one time. If you open/close connections on demand then your application will scale much further as the likelihood of all the active users making use of the database simultaneously is, realistically, low.
Under the covers, ADO.NET uses connection pooling to manage the connections to the database. I would suggest leaving it up to the connection pool to take care of your connection needs. Keeping a connection open for the duration of your application is a bad idea.
I use a helpdesk system called Richmond Systems that uses one connection for the life of the application, and as a laptop user, it is a royal pain in the behind. Even when I carry my laptop around open, the jumps between the wireless access points are enough to drop the DB conenction. The software then complains about the DB conenction, gets into an error state and won't close. It has to be killed manually from Task Manager.
In short, DON'T HOLD OPEN A DATABASE CONNECTION FOR LONGER THAN NECESSARY.
But on the flip side, I'd be cautious about opening and closing connections too often. This is a lot cheaper with connection pooling than without, but even with pooling, the pool manager may decide to grow or shrink the pool, turning it back into an expensive operation.
My general rule is to open a connection when the user initiates some action, do the work, then close the connection before waiting for the next user input. For any given "Update" button click or whatever, I'll generally have only one connection. But you definately do not want to keep connections open while waiting for user input if you can at all help it for all the reasons others have mentioned. You could literally wait for days before the user presses another key or touches another button -- what if he leaves his computer on and goes on vacation? Tying up a resource for unpredictable amounts of time like that is bad news. In most cases, the elapsed time waiting for user input will far exceed the time doing actual work.