sql-serverwpfperformancedatabase-connectionado.net-entity-data-model

Too slow open connection to SQL Server on the first application startup


In my WPF4 desktop application I'm using connection to SQL Server 2008 R2 via ADO.NET Entity Data Model (edmx) and I payed attention, that when I start application for the first time (cold start) it takes too long time (about 10 sec) until application establish (open) connection to DB and could perform basic LINQ-query (no join, table is really small) and show result in DataGrid control.

SQL Server 2008 R2 installed on my local PC, so there is no issues with network load.

The way I build SQL connection (in external thread):

public static DBEntities dbContext = new DBEntities();
dbContext.Connection.Open();

Connection configuration:

<connectionStrings>
    <add name="DBEntities" connectionString="metadata=res://*/DBModel.csdl|res://*/DBModel.ssdl|res://*/DBModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=.\SQLEXPRESS;Initial Catalog=DB;Integrated Security=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />
</connectionStrings>

My questions:

  1. Is it normal behavior for a small basic WPF-application (300 kb executable file, without heavy calculations) to establish the connection to local SQL Server about 10-13 sec? I suppose, that my hardware is not so modern, but anyway, 10 sec…

  2. Could you propose me some solutions to improve the performance of the first connection to SQL Server?

P.S. After a long first connection, the program works fine and there are no some performance issues.


Solution

  • I know about this "bad performance" behavior in a n-tiered application over WCF with SQL Server. Although 10-13 sec is really annoying and pretty extreme. What I do is to kick the connection to WCF service and thereby afterwards a SQL Server connection into a dummy call to a WCF service with a SQL Server select query (with EF) into the splashscreen.

    This way the end-user doesn't experience this first time startup delay. when the end-user actually wants to view / get data the application is responsive.

    Although this doesn't actually "solve your problem" it's a nice workaround/ cover-up ;)