![]() Now, the transaction is there for a reason: SaveChanges may need to apply multiple update operations, and we want those updates to be wrapped in transaction, so that if there’s a failure, everything is rolled back and the database is left in a consistent state. Looking at this through my performance analysis spectacles, that transaction costs us two additional database roundtrips – one to start it, and another to commit. So far, so good but there’s more going on here: a transaction is started before the command is executed, and committed afterwards. Since you may want to continue doing further operations after inserting that row, EF must fetch back the ID value and populate it in your blog instance. In EF Core, when your entity’s key is an int, EF will usually set it up to be database-generated by default for SQL Server, this means an IDENTITY column. The main command – which took 30 milliseconds – contains two SQL statements (ignoring the NOCOUNT which isn’t relevant): the expected INSERT statement, followed by a SELECT to fetch the ID for the new row we just inserted. Info: 17:10:48.521 RelationalEventId.CommandExecuted ()Įxecuted DbCommand (30ms) (Size = 4000)], CommandType='Text', CommandTimeout='30']ĭbug: 17:10:48.549 RelationalEventId.TransactionCommitted () Running this with EF Core 6.0 shows the following log messages (filtered to highlight the important stuff): dbug: 17:10:48.450 RelationalEventId.TransactionStarted ()īegan transaction with isolation level 'ReadCommitted'. ![]() Let’s examine a very trivial EF program that inserts a single row into the database: var blog = new Blog Regardless of the performance optimization described below, I highly recommend keeping roundtrips in mind when interacting with a database, and reading the EF performance docs for some tips (for example, prefer loading rows eagerly whenever possible). In the cloud environment the database server tends to be farther away, increasing latency. In traditional on-premises deployment the database server is typically located close to the application servers.Latency also varies based on various factors, so eliminating a roundtrip has an increasing effect the higher the latency.Network latency is typically a significant factor (sometimes measured in milliseconds), so eliminating an unneeded roundtrip can be far more impactful than many micro-optimizations in the code itself.Optimizing network roundtrips is particularly important for modern application performance: The update pipeline improvements in EF Core 7.0 are quite different it turned out that there were opportunities for improvement in the SQL which EF sends to the database, and even more importantly, in the number of network roundtrips which occur under the hood when SaveChanges is invoked. the time spent within EF Core code when executing a query. The query optimizations in EF Core 6.0 were essentially about runtime performance: the goal was to reduce EF Core’s direct overhead, i.e. For EF Core 7.0, we targeted EF Core’s “update pipeline”: that’s the component that implements SaveChanges, and is responsible for applying inserts, updates and deletions to your database. ![]() For EF Core 6.0, we concentrated on improving the performance of non-tracking queries, achieving a very significant speedup and making EF Core comparable to raw SQL queries using Dapper ( see this blog post for the details). Performance is always high on our priorities in EF Core. In some scenarios, we’re seeing a 74% reduction in time taken – that’s a four-fold improvement! Background In EF7, SaveChanges performance has been significantly improved, with a special focus on removing unneeded network roundtrips to your database. This blog post will focus on optimizations to update performance for the full list of EF7 Preview 6 enhancements, see this page. Keep reading for links to individual packages. Entity Framework 7 (EF7) Preview 6 has shipped and is available on. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |