6 Answer(s)
-
0
- The first login is slow because ABP loads all permission grants from the database and builds the permission cache (PermissionGrants). This is expected behavior, especially if you have a large number of permission grants (as shown in your screenshot: 204,034 entries).
- The second login is fast because the permission data is served from the cache, not the database.
- When you manually clear the permission cache, the next login is slow again because ABP must reload all permission grants from the database to rebuild the cache.
This behavior is typical for ABP's distributed permission cache. The initial load is expensive if you have a large number of permission grants, but subsequent requests are fast due to caching.
Recommendations:
- Reduce the number of permission grants if possible (e.g., avoid assigning permissions at the user level unless necessary; prefer role-based permissions).
- Ensure your cache (e.g., Redis) is properly configured and performant.
- If you must clear the cache, be aware that the first request after clearing will always be slower.
Sources:
- https://abp.io/support/questions/6533
- https://abp.io/support/questions/3386
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
-
0
你有多少个权限项目?
第一次的权限检查发生在哪里? 菜单检查吗?
-
0
接近4000个权限，50个角色，500用户，每次登录，PermissionGrants Cache，客户端4000，角色4000，用户4000，然后去重。第一登录慢，出现白屏，第二次快点，手动删除缓存，又变慢
-
0
请打开Debug日志看看sql的查询, 我们在之后的版本中改成了批量查询缓存和数据库.
var loggerConfiguration = new LoggerConfiguration() .MinimumLevel.Debug() .Enrich.FromLogContext() .WriteTo.Async(c => c.File("Logs/logs.txt"))https://abp.io/support/questions/8622/How-to-enable-Debug-logs-for-troubleshoot-problems
-
0
.har文件发你邮箱不，7.2.2 后权限修改代码，copy 会722 重写编译，替换722的权限模块代码可以不
-
0
不需要har文件, 只需要debug日志. 包括EF Core的Information日志.
你可以替换权限模块的任何内置服务.
