Open Closed

Application configuration caching #1149

Thiqah.Abp created
  • ABP Framework version: v4.2.0

Hi, We have recently done a performance and load test on one of our new systems (developed using ABP). The report came out with high recommendation to improve GetApplicationConfiguration application service.

I have notices the TODO comment to optimize and enhance the service in the source code. Also noticed that there are already an implementation for caching the configurations in Volo.Abp.AspNetCore.Mvc.Client module.

My questions:

  1. Why the caching implementation is applied only on the dynamic client proxy and not implemented directly in the configuration application service? Because I thing it will reduce a lot of processing if the whole configuration object get chached (even if there already a cache implementation for individual configurations).
  2. As the localization only depend on the cuture, Why is the cached localization in the application configuration object not cached seperatly to reduce cache size?
  3. The local event: CurrentApplicationConfigurationCacheResetEventData confused me! how can the handler be called if the Volo.Abp.AspNetCore.Mvc.Client module exists in different application (not the API)? Or I missunderstood the implementation and usage of the module?

Fadi Thanks

1 Answer(s)
  • 1
    hikalkan created
    Support Team


    You have already investigated the code base and understood most of the details :)

    1. As you've written, individual components (those touches to database) are already cached, so object building doesn't get much time I think. This is a big object and if we use distributed cache, it will be serialized to redis and probably it will take more time to get from cache. However, we will work on in the next versions. Probably we can do some imporvements here.
    2. This is a good idea to optimize the caching when we implement it.
    3. It resets the cache if the user changes his/her own data (e.g. permissions). If you change data of any other user, it is not reset. That means if you change permission of a user, it might take a few minues to take the effect, in a tiered architecture.

    We've done some performance improvements with the version 4.3. This topic is in our TODO list for the version 4.4.

    Have a nice day.