Activities of "maliming"

Hi,

Thanks for the logs! The server-side processing time is 682ms, and all three bulk cache lookups are hitting the cache (U, R, C). The optimizations are working well on the server side.

The 996ms in the browser includes network latency between your browser and the production server, which is expected.

Just to confirm — compared to the original 10+ seconds, does this feel like the issue is resolved for you now? Or is there still something you'd like us to look into further?

You also mentioned you wanted to clarify something — what is it?

Thanks

Sure, we can do that if needed. But before the meeting, could you first share the debug log output from the admin service? That way we can have concrete data to look at together.

Please enable the debug logging in the admin service as mentioned above, make one request to /api/abp/application-configuration?includeLocalizationResources=false on the production server, and share the full log output liming.ma@volosoft.com.

Thanks

Hi,

Yes, the admin service is the right one. Please enable the debug logging there and share the log output for a single request.

Thanks

Hi,

EF Core has actually had command batching since version 1.0, so the batching behavior itself hasn't changed between EF Core 8 and EF Core 9/10. The timeout is more likely related to lock contention — especially if your Get method is calling a repository update, which would trigger SaveChangesAsync and generate that UPDATE ... SET ConcurrencyStamp SQL on every request.

Could you enable EF Core debug logging, reproduce the issue, and share the logs with us? The debug logs will show the actual SQL queries and updates being executed, which will help us pinpoint what's happening. Please clear/delete old log files before reproducing to keep the log size manageable.

You can follow this guide to enable debug logging: https://abp.io/support/questions/8622/How-to-enable-Debug-logs-for-troubleshoot-problems

Thanks

Hi,

The AI bot's answer covers the right approach. Here are the key documentation pages you can refer to for more details:

Thanks

Hi,

Great progress — 744ms locally is a solid improvement! Now let's find out exactly why production is still 3–4 seconds.

Please enable full debug logging temporarily on production by updating appsettings.json:

{
  "Logging": {
    "LogLevel": {
      "Default": "Debug"
    }
  }
}

Then make one request to /api/abp/application-configuration?includeLocalizationResources=false and send us the full log output. The key things we're looking for:

  • Does it say BulkPermissionStore: cache hit or cache miss in production?
  • What is the Request finished line's duration (in ms) for that endpoint? This tells us the server-side time vs. browser-measured time.
  • Any slow operations from Volo.Abp.PermissionManagement or Volo.Abp.Caching.

Also a few quick questions about your production setup:

  1. How many microservices are in your solution, and how many of them define their own permissions?
  2. Is your production Redis in the same data center / availability zone as your application servers, or in a different location?
  3. Do you have multiple instances of the application-configuration service running behind a load balancer?

These details will help us pinpoint whether the slowness is coming from Redis latency, permission definition loading across services, or something else entirely.

Thanks

Hi,

Glad to hear <AppearanceStyles/> resolved the issue! That's the correct approach for the App.razor hosting model — it renders all LeptonX theme CSS links during SSR prerendering, so the styles are included in the initial HTML response.

Your current App.razor setup should already match the official ABP template structure:

<head>
    <AbpStyles BundleName="@BlazorLeptonXThemeBundles.Styles.Global" />
    <link href="YourProject.Blazor.styles.css" rel="stylesheet"/>
    <HeadOutlet @rendermode="InteractiveServer" />
    <AppearanceStyles/>
</head>

For Blazor Server, the AbpStyles component resolves and renders CSS links at runtime on the server side, so no abp bundle command is needed.

For further optimization, you can enable bundle & minify mode in production to merge multiple CSS/JS files into fewer requests. Configure it in your module's ConfigureServices:

Configure<AbpBundlingOptions>(options =>
{
    options.Mode = BundlingMode.BundleAndMinify;
});

Some useful references:

  • Migration guide for the new App.razor hosting model: https://abp.io/docs/latest/release-info/migration-guides/abp-8-2-blazor-web-app
  • Bundling & Minification configuration: https://abp.io/docs/latest/framework/ui/mvc-razor-pages/bundling-minification
  • Blazor global scripts & styles: https://abp.io/docs/latest/framework/ui/blazor/global-scripts-styles

Thanks

hi

You only need to do this after the initial new databases, after that, you won't have any issues with permissions.

It's also random—it depends on the order in which the servers start up or whether any errors occur during the process. If there are errors, it will retry, and then automatically handle the issues mentioned above.

Thanks.

hi

You can follow https://github.com/abpframework/abp/issues/25228

I have refunded your ticket.

Thanks.

Glad that works for you! A few things to keep in mind:

  • Make sure to add the new Web project's URL to the CORS configuration in both AuthServer and HttpApi.Host (App:CorsOrigins in appsettings.json).
  • If your solution uses a DbMigrator or seed data to register OpenID Connect clients, add the new client there as well so it doesn't get lost after re-seeding.
  • Use a different port for the new Web project to avoid conflicts with existing projects.

Thanks

Showing 671 to 680 of 12917 entries
Boost Your Development
ABP Live Training
Packages
See Trainings
Mastering ABP Framework Book
The Official Guide
Mastering
ABP Framework
Learn More
Mastering ABP Framework Book
Made with ❤️ on ABP v10.8.0-preview. Updated on November 02, 2026, 06:56
1
ABP Assistant
🔐 You need to be logged in to use the chatbot. Please log in first.