Meet the following issue when working with EntityFramework v6.1.3
The query is:
var query = DataContext.ExternalPosts.Include(e => e.ExternalUser)
.Where(e => e.EventId == eventId)
.OrderByDescending(e => e.PublishedAt)
.Take(35);
When I do
query.ToList()
I get "The wait operation timed out" exception. But when I use query from
query.ToString()
and execute it directly on server (via Management Studio) it take about 150ms
I have updated CommandTimeout period to 180 and managed to get the result after 50sec via EntityFramework.
When I remove '.OrderByDescending' or '.Include' it works correct for me, I didn't measure the time but it works quite fast.
There is statistics: http://grab.by/KsQ2
I use AzureDb.
UPDATE:
New day, new situation: today it works quite normal with the same query and on the same set of data. Could this be Azure services issue?
Any ideas?
This might help :- msdn forum link
Related
Recently we ran into an issue where a process that normally took seconds to execute one day took an hour and then the next day took almost 9 hours. That is a separate issue which I am also investigating, but issue I want to talk about here is the fact that the query in question was called through Entity Framework with a 600 second timeout and when the process started running long, there was no timeout exception triggered.
In each instance of the process running long, it eventually completed successfully with no errors generated. We do not override anything related to DbContext so the default timeout of 30 seconds should still apply.
We validated that the query was still running by evaluating current executions on the SQL Server instance. My first thought was that the query finished but goofiness with Entity Key columns in the entity class for this view caused it to take forever to validate. There is only 1 Entity Key column on that object and it is the PK of the main table of the view. We also confirmed that the dataset was not returning duplicate records. So everything points to the fact that the query is executing for the duration of the process and no timeout exceptions are being generated.
Has anyone ever experienced such a thing with EF in their own environment?
We are on EntityFramework 6.1.3 and SQL Server Standard 2016 SP2 CU4.
CODE SAMPLE:
EntitiesCommandTimeout=600
if (ConfigurationManager.AppSettings.AllKeys.Contains("EntitiesCommandTimeout"))
{
_entitiesCommandTimeout = Convert.ToInt32(ConfigurationManager.AppSettings["EntitiesCommandTimeout"].ToString());
}
...
using (var db = new myContext())
{
db.Database.CommandTimeout = _entitiesCommandTimeout;
List<vwMyView> myViewItems = db.myView.Where(v => v.myColumn == myVariable).ToList();
}
UPDATE 2019-03-19:
I forgot to mention that when one of my developers ran this process locally through Visual Studio and the config file set to match what we have setup in Prod, the timeout exception was properly triggered.
I have following query within my project and it is consuming lot of time to execute. I am trying to optimize it, but not able to successfully do it. Any suggestions would be highly appreciated.
_context.MainTable
.Include(mt => mt.ChildTable1)
.Include(mt => mt.ChildTable1.ChildTable2)
.Include(mt => mt.ChildTable3)
.Include(mt => mt.ChildTable3.ChildTable4)
.SingleOrDefault(
mt =>
mt.ChildTable3.ChildTable4.Id == id
&&
mt.ChildTable1.Operation == operation
&&
mt.ChildTable1.Method = method
&&
mt.StatusId == statusId);
Include() gets translates to join and you are using too many joins in the code. You can optimize indexes with the help of DB engine execution plan.
I suggest you not to use all Include in one go. instead, you break the query and apply Include one by one. I meant you apply Include, get the result and then apply theIncludeagain and so..By having more than twoInclude` affect the performance.
I Don't see any performance issues with you query.
Since you have a singleOrDefault I would look at uptimizing the database call. If you have analytics tools available then in SQL Server Management Studio then you choose tools > Sql Server Profiler. Get query into SQL Server Management Studio, mark the query and choose "Analyse Query in Database Engine Tuning advisor"
Orientdb throws on each live query subscripion using binary protocoll following Nullpointer exception:
Error executing live query subscriber. java.lang.NullPointerException at com.orientechnologies.orient.server.network.protocol.binary.OLiveCommandResultListener.onLiveResult(OLiveCommandResultListener.java:113)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLLiveSelect$2.call(OCommandExecutorSQLLiveSelect.java:134)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLLiveSelect.execInSeparateDatabase(OCommandExecutorSQLLiveSelect.java:144)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLLiveSelect.onLiveResult(OCommandExecutorSQLLiveSelect.java:131)
at com.orientechnologies.orient.core.query.live.OLiveQueryQueueThread.run(OLiveQueryQueueThread.java:69)
The Live Query is subscribed by one client: "live select from Account where CheckInDateTime like "2018-02-25%"", Orientdb returns also the live request token ID gracefully. But when another client updates Account with "update Account set CheckInDateTime = "2018-02-25 13:00:00"" the mentioned NullPointerexception is thrown. I've tried to use versions 2.2.30 and 2.2.32 Comunity, DB Administrator and Server Administrator accounts. Also loading of plugins seems not to work (even the used version is 2.2.30 and 2.2.32 where Live Query should be enabled at server by default). Nothing seems to help to get that work, also queries like "live select from account" (without where ...).
Any further ideas? Thx.
Currently live queries do not support the WHERE clause you included in the query.
You can only select entire collections or V and E (which is what I use to get all updates)
If you would like to filter using that where, you will have to write it yourself in code.
Thx for answering mitchken! Fortunately, I found the mistake. The TCP connection from client to DB was in wrong state (must be all the time in waitforreadyread).
I have this line of code within a request of an ApiController of an Azure Mobile App Web API:
var user = t.TrackDependency(() => context.Users.SingleOrDefault(x => x.Email == loginRequest.Id || x.Name == loginRequest.Id), "GetUser");
Here is the result from Application Insights:
We can see that while the line of code took 2613ms, the actual query call to the database took 190ms. While this is an edge case it happens often enough to get complaining users about slow performance.
The thing is I have no idea where the difference could come from. Note this is not due to a cold start, the app was warm when this exact call happened.
The second line is the actual call to the database endpoint. Before that it is not database related.
ps: the graph is from application insights. They capture the call to the database and I add my onwn data through the TrackDependency method.
UPDATE
Today I got more data thanks to Application Insights sampling (great tool!).
Here are the results (this is not the exact request call instance but this is the same problem):
It clearly shows that context.Database.CompatibleWithModel(false) is the culprit. It is called by the call to InitializeDatabase of my custom implementation of IDatabaseInitializer. My custom intializer is set at Startup.
I found another unanswered question on SOF with the same issue
Why does it take so long?
InitializeDatabase is not always called and I don't know when it is called and why.
I found another culprit:
Now we see that EntityConnection.Open is waiting something. Are there some locks on the connection? So far the call to the database endpoint is still not made so we're still on EntityFramework here.
UPDATE 2
There are two issues in that post:
Why is CompatibleWithModel slow? There are many articles about startup time improvements. This is not be adressed in that SOF question.
Why is EntityConnection.Open blocking. This is not related to EntityFramework but is general to getting a connection which takes up to 3 seconds if not called within a 5 minutes windows. I raised that problem in a specific post.
Hence there is no more questions in that post which and it could be deleted but may still be useful as an analysis of tracking down lost time in Web Api calls.
I'm using MVC5 along with EF6 to develop an application. I'm using SQL Server Express for database. I have two tables/entities in the database.
Vehicle - Contains Information about the vehicles
GsmDeviceLog - Contains data received from GPS Tracker Fit in the vehicle.
My GsmDeviceLogs table currently has around 20K records and it takes around 90 Seconds to execute the below code. Just to fetch one record(i.e. The Last Record).
Here is the code:
var dlog = db.Vehicles.Find(2).GsmDeviceLogs.LastOrDefault();
When I try to open the table using Server explorer it shows ALL the data with in 5-10 seconds. Can anyone help me get the details loaded quickly on the page as well.
Thanks for reading and paying attention to the question.
Can anyone suggest any means to reduce the time.
Your query should look like this:
var dlog = db.Vehicles
.Where(v => v.Id == 2)
.SelectMany(v => v.GsmDeviceLogs)
.OrderByDescending(gdl => gdl.Id) // or order by some datetime
.FirstOrDefault();
In your original query you are loading the Vehicle with Find. Then accessing the GsmDeviceLogs collection loads all logs of that vehicle into memory by lazy loading and then you pick the last one from the loaded collection in memory. It's probably the loading of all logs that consumes too much time.
The query above is executed completely in the database and returns only one GsmDeviceLog record. Side note: You must use OrderByDescending(...).FirstOrDefault here because LastOrDefault is not supported with LINQ to Entities.
Your Linq query is inefficient. try doing db.Vehicles.Single( x => x.Id).GsmDeviceLogs.OrderByDescending(x => x.Id).FirstOrDefault() or whatever your primary keys are