I have a big problem with first run query form my SQL Server CE database.
I already applied this optimization Performance and the Entity Framework, but still first query take about 15 sec to run.
Something that I noticed when I run my application for first time first query take about 15 sec to run.
If I close my application and run again, the first query runs immediately. So if I restart my PC and run application again first query take 15 sec to run.
Overall, after two week research on internet I could not find a good way to solve my problem.
I used ANTS Performance Profiler and I noticed my first query takes about 11 sec and form initialization for each page take 4 sec for first time.
I have some questions:
I want to know which resource loaded to Ram when my application start?
why my application is fast in second time run?
how can I load those resource into Ram before application start?
why these resource Remains in Ram until windows restart?
Maybe 15 sec is good but when I run my application from DVD it take 45 sec to run first query.
Edited
I used multiple database for each section of my application.
for example This query Take 11 sec to run form first time:
public void GetContent(short SubjectID)
{
new QuranOtherEntities(CDataBase.CSQuranOtherEntities))
{
CHtmlDesign.HtmlFile = QODB.AdabTbls.First(data => data.ID == SubjectID).Content;
}
}
Table Structure
First(data => data.ID == SubjectID)
Ok, forget entity framework. Grab the generated SQL code, run it through profiler.
This SMELLS like "I have no clue what an index is". Check "Use-the-index-luke.com".
Also make sure that
Maybe 15 sec is good but when I run my application from DVD it take 45 sec to run first
query
Actually IS the sql statement. It could easily be loading and initializing your application, in which case you ask a totally irrelevant question here. In this case there is no a lot you CAN do - there still are optimizations etc., but youhave to ask specific questions here, i.e. do your homework and this question here is then totally irrelevant. This includes, btw, the time it takes entity framework to initialize - which is not related to the query per se, but can happen on the first query you run at all.
Related
I crate a table value function and used it in my c# program.
When i restart my computer, execute_time for calling this function (in c# program) is 5 minutes.
But when i just modify this function (without any changes) and then run my program, execute_time is 6 seconds.
Who know that what happen when we modify a function?
What can i do to my execute_time always be 6 seconds?
when you run the first time CPU takes time to figure out how to run a query.SQL Server uses memory to cache execution plans to save time the next time you run the query.
source of the information is blog read this blog you will get more info
We started developing an application in C# recently and decided to try Entity Framework 6.1.3 with a code-first approach to handle persistence. The data is being stored in a SQL Server Express 2012 instance which is running on a local server. The application is still very small. Currently we are only persisting two POCOs and have two tables in the database: one with 5 fields (about 10 rows of data), and one with 4 fields (2 rows).
We are experiencing a 3 second delay when Entity Framework processes the first query with subsequent queries being extremely quick. After some searching we found that this is normal for Entity Framework so, although it seemed excessive for such a small database, we've been coping with it.
After doing some work today, none of which was specifically related to persistence, suddenly I found that the first query was only taking a quarter of a second to run. I couldn't see anything obvious in the changes I'd made so I uploaded them to source control and asked my colleague to download everything. When he builds and runs it on his computer, it still takes 3 seconds for the first query. I've compiled the application, tried it on two test computers and they experience the initial 3 second delay.
There seems to be no correlation between the problem and the computers/operating systems. My computer is running Windows 7 SP1 x64. My colleague's development computer is running Windows 10 x64. The other two test computers are running Windows 7 SP1 x86. They are all a similar specification (Core i5, 4GB/8GB RAM).
In my research of the delay I found that there are several things you can do to improve performance (pre-generating views etc) and I have done none of this. I haven't installed anything or made any changes to my system, although I suppose it's possible an update was installed in the background. Nothing has changed on the database server or in the database itself or in the POCOs. We are all connecting to the same database on the same server.
This raises a few obviously related questions. If it's possible for it to start up in a quarter of a second, why has it been taking 3 seconds up until now? What happened on my computer to suddenly improve performance and how can I replicate this on the other computers that are still slow?
Can anyone offer any advice please?
EDIT
I turned on logging in Entity Framework to see what queries were being run and how long they were taking. Before the first and, for testing purposes, only query is run, EF runs 3 queries to do with migration. The query generated to retrieve my data follows that and is as follows:
SELECT
[Extent1].[AccountStatusId] AS [AccountStatusId],
[Extent1].[Name] AS [Name],
[Extent1].[Description] AS [Description],
[Extent1].[SortOrder] AS [SortOrder]
FROM [dbo].[AccountStatus] AS [Extent1]
-- Executing at 28/01/2016 20:55:16 +00:00
-- Completed in 0 ms with result: SqlDataReader
As you can see it runs really quickly which is hardly surprising considering there are only 2 records in that table. The 3 migration queries and my query take no longer than 5ms to run in total on both my computer and my colleague's computer.
Copying that query in to SSMS and running it from various other machines produces the same result. It's that fast it doesn't register a time taken. It certainly doesn't look like the query causes the delay.
EDIT 2: Screenshots of diagnostic tools
In order to give a good comparison I've altered the code so that the query runs at application start. I've added a red arrow to indicate the point at which the form appears. I hadn't noticed before but when my colleague runs the application the first time after starting Visual Studio, it's about a second quicker. All subsequent times are slower.
1) Colleague's computer - first run after loading Visual Studio
2) Colleague's computer - all subsequent runs
3) My computer - all runs
So every time my colleague runs the application (apart from the first time) there is a second's pause in addition to the usual delay. The first run immediately after starting Visual Studio seems to eliminate this second's pause but it's still no where near the speed on my computer.
Incidentally, there is a normal delay of around a quarter of a second caused by the application starting. If I change the application to require a button click for the first query, the second's pause and usual 2 second delay happen only after the button is clicked.
Another thing of note is the amount of memory the application uses. Most of the time on my computer it will use around 40MB but on the other computer it never seems to use more than 35MB. Could there be some kind of memory optimisation going on that is slowing things down for the other computer? Maybe my computer is loading some additional/cached information in to memory that the others are having to generate. If this is possible, any thoughts on where I might look for this?
EDIT 3
I've been holding off making changes to the model and database because I was worried the delay would come back and I'd not have anything to test against. Just wanted to add that after exhausting all other possibilities, I've tried modifying a POCO and the database and it's still quick on my computer but slow on others.
I've altered the title of this question to more accurately reflect the problem I'm trying to solve.
Query plans in SQL Server can change over time. It may be that your machine has cached a good query plan, while your co workers machine has not. In other words, it may have nothing to do with EF. You could potentially confirm or deny this theory by running the same query by hand in management studio.
In order to tackle performance problems related to EF generated queries, I advice you to use Profiler or an alternative (as Express Editions do not have it) to see how much of your time is actually consumed running the query.
If most of your time is used for running the query, as already suggested by jackmott, you can run it in SSMS by toggling Actual Execution Plan to see the generated plan in each situation.
If time is spent on something else (some C# warming up or something similar), Visual Studio 2015 has builtin performance analysis that can be used to see where it is spending that time.
I have a performance problem we have done a bunch of analysis and are stuck. Hopefully one of you have seen this before.
I'm calling DbContext.Database.SqlQuery the database portion takes 3ms but the full execution takes 9 seconds.
We've used EF Profiler to discover this and we also run the SQL directly in SQL Server Management Studio and it is instantaneous.
We also used glimpse and couldn't see deep enough into the process.
The result type is not an entity from the model and therefore we are confident that tracking is not involved.
We also know that this is not the first query executed against the context therefore we are not paying EF startup cost on this query.
We tried the .net profiler and had so many problems running it that we decided we should just ask.
Any tips on how to dig in and figure this out ?
EDIT: The result set for this query is 1 row with 4 columns (decimal)
The line of code is just:
var list=contextInstance.Database.SqlQuery<nonEntityType>(sqstring).ToList();
The SQL itself is not a very long string. We will use a more detailed profiler to find out where in the process this is getting hung up.
We've used EF profiler to discover this and we also run the SQL
directly in SQL server management studio and it is instantaneous.
This doesn't prove anything. The query might run fast, but the data might result in 100MB of data which is then transported to the client and materialized in objects. This might take more time than you think.
The query in SSMS might return instantaneous because it shows only part of the data. You didn't say what the data was.
Use a real .NET profiler, like dotTrace or Ants. This way you can see where time is lost exactly on the line. EF Prof (or my own ORM Profiler: http://www.ormprofiler.com) will tell you which part of the total route taken (ORM->DB->ORM) takes what time. Even EF prof does ;)
If the client for some reason can't use a profiler as Frans suggest you will have to play the guessing game and exclude possiblities.
First of all I think a critical piece of information is missing. Does it always take around 9 seconds or does it vary?
First step:
Decide if the delay is before or after the query hits the database. Should be possible to do either with EF profiler and looking at the timestamps in Sql profiler.
Either way you will have limited the possibilities a bit.
Second step:
Exclude as much as possible
Indexes (No, the query is fast)
Returning too much data (No, according to the info you have)
Slow query compilation (No, raw sql query is used)
Slow data transfer (No, the other queries works well)
Slow DbContext initialization (No, you said it's not the first query)
Row or table locks (Not likely, That would probably show up as a long running query in the profiler)
Slow materialization (No, to few fields unless there is a serious edge case bug)
Third step:
What's left? That depends on the answer to #1 and also if it's always 9 seconds.
My prime suspects here is either some connection issue because another call is blocking so it has to wait for a connection or some second level cache or something that doesn't work well with this query.
To exclude some more alternatives I would try to run the same query using plain old ADO.NET. If the problem persists you know it's not a EF problem and very likely a connection issue. If it goes away it could still be both issues though.
Not so much as an answer as some rants, but hopefully something you didn't think of already.
I'am using mongodb in my project to reduce the time, While comparing the time taken for fetching data from SQL and NoSQL, SQL takes 50ms for each fetch form database but NoSQL takes around 180ms for first time and 15ms for other fetches, how to reduce the fetching time for the first time in NoSQL.
Try to create an index for your collection to make queries run faster
http://docs.mongodb.org/manual/core/indexes/
The first query is probably taking more time because it loads the working set into your RAM. Details about working set can be found here:
http://docs.mongodb.org/manual/faq/storage/#what-is-the-working-set
To avoid this problem you may want to pre-load this before any of your actual users hit the database. One way I can think of is an hourly (or any frequency you find suitable) cron that does this query each hour to load the working set into memory, for faster subsequent queries.
I made a simple WebPerformanceTest in VS2012 which is just logging in and doing some basic jobs on the website. When ran, this test is only running for about a second or two.
Now, I made a load test, containing only this one webtest with a Constant load for 5 minutes and the mode is based on the number of virtual users. And here comes the funny part: No matter how much users I assign to this load test the number of tests executed is always the same as the number of users assigned. I also tried raising the load test execution time giving me the same result: one test = 5 minutes per user, whereas it only took the webtest about 1-2 seconds to execute.
Does anyone have any idea why the test is taking way longer (300 times) in the load test? What am I doing wrong here?
Edit: The machine is a Windows Server 2008 R2 with 4 cores # 3.00ghz and 8 GB RAM
Here's some images of the settings:
Notice the Run Duration: 5:00
You've set each test to run for five minutes. So basically it runs through the test then sits their idle for the rest of the time, closes the tests and then reports back to you that it took 5 minutes. You won't see any difference unless you change this setting or create a test that could take longer than 5 minutes to run.