One other real issue with dbContext is that it has no way to clear out the change tree. You should not be afraid to create multiple dbContexts or re-create an existing dbContext to provide isolation or clear out change state if you need it. Yes there’s still some overhead over not creating one, but it’s not a major hit. While the first instantiation of a large dbContext (like the one used here) can be very slow, subsequent instantiation is not. Note some people are hesitant to create new instances of dbContext because it’s supposed to be slow. Immediately re-running those same 6+ hour queries reduced the processing time to a mere 2 minutes. The first thing I tried is to simply move the business object (and therefore the dbContext) instantiation inside of the loop in both operations: foreach ( OrderIDsToProcess orderID in orderIDsToProcess)īusOrder orderBO = new BusOrder () var order = (o=> o.OrderID = orderID.OrderID)
#GW2 FROZEN OUT INSTANCE WAAY TOO LONG CODE#
The code performs 32,000+ SQL load operations and then loads those 32,000 result records into the active dbContext. The problem here is Entity Framework’s Change tracking. So what’s going on here? Watch your DbContext and Change Tracking! We could see however that the interval between database queries was increasing drastically. The first thought we had is that this was slow because of SQL, but checking the SQL Profiler logs it was easy to see that the queries were operating in the nearly immeasurable millisecond range even once the loop starts slowing down. By the time we get to the last few items in the second loop there’s up to a 4 second delay between each iteration of the loop. What happens is that processing starts fast, but then slowly starts slowing down, getting slower and slower as the loop count goes up. Yet the original code ran for more than 6 hours. That’s a lot but really this shouldn’t take very long to process. Assuming 16,000 sales order records, this bit of code would generate 32,000 queries to retrieve the child customers and orders. Then the same process is roughly repeated to collect all the customer ids from this single order that already lives in memory. The process basically creates a single business object/dbContext and then proceeds to iterate over each of the sales order items and collects the orderIDs. OrderID.BillingTypeID = customer.BillingTypeID ? 0 Var customer = (c=> c.CustomerID = orderID.CustomerID) var customer = customerBO.Load(orderID.CustomerID) OrderIDsToProcess.OrderBy(x => x.CustomerID) īusCustomer customerBO = new BusCustomer () Var order = (o=> o.OrderID = orderID.OrderID) var order = orderBO.Load(orderID.OrderID) contains an initialized dbContext instance dbContextįoreach ( OrderIDsToProcess orderID in orderIDsToProcess) In the code below the business objects are used to load up instances of orders and customers for roughly 16,000 sales orders (modified for EF specifics and removed some additional processing code after the load operations to keep the code relevant): private void LoadOrderIDsToProcess() We’re using business objects in this scenario but the business objects essentially host an Entity Framework dbContext and use it for the business object methods. The issue for this customer dealt with processing very large Sales Orders that involves looking up customers and order ids as part of the initial pre-processing operations. Now some people are very quick to blame EF for bad performance and while there may be something to that in some situations, I find that very frequently a few minor adjustments in code can fix serious performance issues. Lots of items for sure, but there’s no reason this should take hours or even more than a few minutes. This task is pretty massive, but it was taking 6+ hours to complete.
#GW2 FROZEN OUT INSTANCE WAAY TOO LONG PLUS#
The customer was running a long order processing task involving an order with many thousands of order items plus a boat load of child items. I spent some time today with a customer debugging a very, very slowly process using Entity Framework operation. Thought I’d highlight a common problem I’ve run into a few times with a few of my customers using Entity Framework.
0 kommentar(er)
