Starts in:
2 DAYS
10 HRS
33 MIN
30 SEC
Starts in:
2 D
10 H
33 M
30 S
Open Closed

using Nolock in entity framework #6537


User avatar
0
shobhit created
  • ABP Framework version: v4.2.2
  • UI Type: Angular
  • Database System: EF Core (SQL Server, Oracle, MySQL, PostgreSQL, etc..)
  • Tiered (for MVC) or Auth Server Separated (for Angular): yes
  • Exception message and full stack trace:
  • Steps to reproduce the issue:

Hi Team, I have 2 tenants and have physically seperate db for each tenant. sometime my application is very slow for the tenatnt where GET api request is taking more than 1 min. My question is:

1- what all points i can check for better perofrmance 2- I am expecting table lock so how i can enable (nolock) scenarios with EF


2 Answer(s)
  • User Avatar
    0
    jfistelmann created

    Hey,

    1. For this you typically use logging. Here's some inspiration https://community.abp.io/posts/performance-optimization-of-.netbased-and-also-abpbased-application-pmdwhwxc https://akashjwork.medium.com/asp-net-core-7-api-performance-report-logging-mastery-with-serilog-6f490ac2ba2f
    2. Here's how to do that. https://stackoverflow.com/a/63603655 Depending on your DBMS you may get information from that on lock scenarios and performance issues

    kind regards Jack

  • User Avatar
    0
    IanW created

    For better performance I can answer.

    There is a concept of access patterns and it is especially important for any kind of lists of data you are displaying. Lists of data, for the large use case, should have the data itself clustered together on the database disk. This means having the clustered index (usually the primary key, but it can be changed) of one that is (TenantId, Id) which will force all data to be togethered on disk.

    However, the other issue will be joins. If any of the data you are retrieving in the list requires data from other tables, it will be retrieving the data for each item in the list in the other tables one by one. So Ideally all of the data in the other tables that may be joined, is also physically close together - which means clustered on something related to the top level entity you are trying to list. TenantId may be enough is most cases, but if it is not an aggregate root, then perhaps something based on the FK to the top level entitiy.

Made with ❤️ on ABP v9.1.0-preview. Updated on November 20, 2024, 13:06