Base solution for your next web application
Open Closed

Many IRepository causes huge startup delay #6776


User avatar
0
ivanosw1 created

Hi, we have a big solution with houndred of IRepository. The startup time after an application pool reset takes about 1 second for each repository. We have splitted in small application services and entity framework core contexts, but there isn't an effective improvement. Now the startup time is about 30 seconds and is growing as our application grows up.

Debugging the solution we have noted that the dependency resolution is where the most of the time is consumed.

This is an example of our repository to resolve a client request for a detailed dto. This takes about 10 seconds to resolve dependency (only the first time). Imagine that the client makes at the same time another request for a different dto with many repository, the response arrives after 20 seconds.

Have you some guide line to deal with a very huge application? Thank you

` public class RisorseQueryService : IRisorseQueryService { private readonly IRepository

    public RisorseQueryService(
        IRepository<RisorsaMaterialeReferenceData> risorsaMaterialeRepository,
        IRepository<TipologiaRisorsaMaterialeReferenceData> tipologiaRisorsaMaterialeRepository,
        IRepository<UbicazioneReferenceData> ubicazioneRepository,
        IRepository<RisorsaMaterialeCentroRicavoReferenceData> risorsaMaterialeCentroRicavoRepository,
        IRepository<CentroRicavoReferenceData> centroRicavoRepository,
        IRepository<RisorsaMaterialeUnitaLavoroReferenceData> risorsaMaterialeUnitaLavoroRepository,
        IRepository<RisorsaMaterialeUnitaOffertaReferenceData> risorsaMaterialeUnitaOffertaRepository,
        IRepository<PostoClasseConfortReferenceData> postoClasseConfortRepository,
        IRepository<ClasseConfortReferenceData> classeComfortRepository,
        IRepository<PostoProfilazioneReferenceData> postoProfilazioneRepository,
        IRepository<ProfilazioneUtenteViewReferenceData> profilazioneUtenteViewRepository,
        IRepository<WorkspaceData, long> workspaceRepository)
    {
    `
    
   

Asp.Net Zero 5.6.0


8 Answer(s)
  • User Avatar
    0
    maliming created
    Support Team

    If you want to be fast for the first time, the cost may be that the application needs to do a lot of warm-up work after startup, so the startup will be slower.

    refer to: https://github.com/aspnetboilerplate/aspnetboilerplate/issues/4292#issuecomment-465416947

  • User Avatar
    0
    ivanosw1 created

    Hi @maliming Thank you for response. I have read the topic and what I understand is that there isn't a real effective solution. You suggest a warm-up procedure to resolve all dependency at start-up? A kind of scaffolding tool with a noop method?

    Or maybe is all about dependecy resolver's problem?

  • User Avatar
    0
    alper created
    Support Team

    if you think Repository instantiate step is making the big impact. You can change IRepositories to Singleton. (Be aware that you repositories shouldn't keep state if you make them singleton)

    Also you can do the same thing to application services.

    But this is risky because Singleton requires stateless objects to work properly. But it's fast!

  • User Avatar
    0
    ivanosw1 created

    We are still looking for a solution to the "first time" startup request. After many attempts we found this workaround.

    Instead of instantiating many IRepository, we request only one dependency of IDbContextProvider<YourContext> so the constructor resolution is fast. After you can use every repository in your context with ` private QueryContext QueryContext => _queryContextProvider.GetDbContext(); private IQueryable

    public async Task<List

            return result;
        }
    

    `

    It works and is fast at first request. This is our approach only for reporting, query and reference contexts, while for the domain operations (CRUD) we use the classic IRepository. Is a good approach for the point of view of Aspnet Zero architecture ?

  • User Avatar
    0
    aaron created
    Support Team

    private IQueryable YourEntitiesRepository => QueryContext.YourEntities.AsQueryable();

    YourEntitiesQueryable is more accurate. It doesn't use repository abstraction at all.

    There is direct dependency on YourContext from data layer.

  • User Avatar
    0
    ivanosw1 created

    Yes sure. I know that in this manner I depend on YourContext and on EF Core, but do you think that is a valid compromise? Or you see some probably issue?

  • User Avatar
    0
    aaron created
    Support Team

    Yes, that is fine. Data filters still work too.

  • User Avatar
    0
    ivanosw1 created

    Awesome. Thank you aaron