Performance issue with many tenant based features and opportunity to improve it.

[RickFrankel]

Hi,

When researching the issue with features in v13.1 we came across this piece of code (in both the async and non async versions).

aspnetboilerplate/src/Abp.Zero.Common/MultiTenancy/AbpTenantManager.cs

Line 204 in 8658bcf

values.Add(new NameValue(feature.Name, await GetFeatureValueOrNullAsync(tenantId, feature.Name) ?? feature.DefaultValue));

In our setup we have around 20-30 tenant based features. For each of these features it calls

        return _featureValueStore.GetValueOrNull(tenantId, featureName);

When you look at the featurevaluestore

aspnetboilerplate/src/Abp.Zero.Common/Application/Features/AbpFeatureValueStore.cs

Line 90 in 8658bcf

var cacheItem = await GetTenantFeatureCacheItemAsync(tenantId);

We are calling
var cacheItem = await GetTenantFeatureCacheItemAsync(tenantId);

For every feature we are retrieving the entire cache of feature values for that tenant and then filtering it based on the feature asked for.

We are already implementing the per request redis cache so it improves things a bit but I feel like it is redundant to get the cache of ALL features every time for every feature.

There is a big opportunity to improve the performance here.

Thanks
Rick

[ismcagdas]

Hi @RickFrankel,

Do you use https://aspnetboilerplate.com/Pages/Documents/PerRequestRedisCache ?

[RickFrankel]

Yup I mentioned that above that we do use the PerRequestRedisCache but even then that can be still a lot of calls to the HttpContext when it doesn't really need to be.

[m-aliozkaya]

Hi @RickFrankel,

When I examine this problem and the codes, I think there will be no serious performance problems. When you use PerRequestRedisCache there should be no problem.

Additionally, we are hesitant to make any changes in the relevant area as it would cause too many breaking-changes.