We have a critical systematic performance issue where all AppServices experience significant delays during cold start. The key finding is that the delay occurs AFTER the business logic method completes execution, not during initialization or business logic execution. Impact: 15.1x performance degradation with 6,444ms unexplained delay in ABP's post-method pipeline.
The method is executed but when is finished take many seconds (3 - 7 seconds) in all enviroments. When is the fist call, the second is very quick.
Key Findings
1. Timing Analysis • Business Logic Execution: 456ms (fast) • Total HTTP Request Time: 6,900ms (extremely slow) • Delay Location: Post-method execution, within ABP pipeline • Silent Gap: 6,444ms of unexplained processing
2. Affected Components • All ABP AppServices: Experience cold start delays • Non-ABP Controllers: No delays (normal performance) • Direct Repository Access: Fast execution
Test Implementation We created three identical implementations to isolate the issue:
- ABP AppService (ClinicalTrialsAppService) - Standard ABP implementation
- Custom AppService (ClinicalTrialsPerformanceAppService) - No ABP inheritance
- Direct Controller (ClinicalTrialsPerformanceController) - Direct DbContext access
// Added to all test methods var stopwatch = Stopwatch.StartNew(); stopwatch.Stop();
Critical Analysis - The 6+ Second Silent Gap
KEY FINDING: In AppServices, there is a 6,444ms gap between:
- Our method completing execution (456ms)
- The HTTP response being sent (6,900ms total)
During this gap: • ❌ No logs from our application code • ❌ No logs from business logic • ❌ No logs from Entity Framework • ❌ No visible processing activity • ✅ Something is consuming 6,444ms silently
Performance Comparison - Exact Measurements
| Implementation | Business Logic | Method Total | HTTP Total | Silent Gap | Performance Factor | |---|---|---|---|---|---| | ABP AppService | 334ms (245+89) | 456ms | 6,900ms | 6,444ms | 15.1x slower | | Custom AppService | 265ms (198+67) | 287ms | 378ms | 91ms | 1.3x | | Direct Controller | 211ms (164+47) | 222ms | 289ms | 67ms | 1.3x |
Impact Assessment
All Environment (Local and Release) • First request to any AppService: 6.9+ second delay or apply any filter (if second time apply filter is quick) • API responsiveness: Severely degraded on cold start • System scalability: Cold starts occur frequently in cloud environments
Question: What specific components run in ABP AFTER method completion? • Response serialization • Authorization post-processing • Audit logging • Unit of Work finalization • Result caching/compression • Other interceptors or middleware
Question: Are there lazy-loaded components that initialize on first use?
• AutoMapper configuration compilation • Validation rule compilation • Permission checking cache • Other reflection-based components
Depends the appservice it takes between 3-7 seconds to execute and up to 11 seconds in Production.
8 Answer(s)
-
0
Based on your detailed analysis and the available verified sources, here are the key points and recommendations regarding cold start performance issues in ABP AppServices:
- The significant cold start delay (3–7 seconds, sometimes up to 11 seconds) after business logic execution in AppServices is not observed in non-ABP controllers or direct repository access.
- This delay is most prominent on the first request and disappears on subsequent requests, indicating initialization or first-use overhead in the ABP pipeline.
What Happens After AppService Method Execution in ABP?
ABP performs several post-processing steps after your business logic completes, including:
- Response serialization
- Authorization post-processing
- Audit logging
- Unit of Work finalization
- Result caching/compression
- Interceptor and middleware execution
Additionally, the first call may trigger:
- AutoMapper configuration compilation
- Validation rule compilation
- Permission checking cache population
- Reflection-based component initialization
Key Insights from Verified Sources
- ABP introduces a small performance overhead due to its features (exception handling, validation, authorization, audit logging, etc.), but this is typically negligible after the first request. If you disable unnecessary ABP features, the overhead decreases. (Why ABP Platform?)
- Cold start delays are often related to the initialization of caches, permission stores, or distributed caches (e.g., Redis). Issues with distributed cache configuration or network latency can cause significant delays, especially on the first request. (Support Case 6533)
- In some cases, permission and settings caches are populated on the first request, which can cause a noticeable delay. This is especially true if Redis or another distributed cache is slow or misconfigured. (Support Case 3587)
Recommendations
Check Distributed Cache (Redis) Performance:
- If you are using Redis, ensure it is running optimally and is not introducing network or containerization delays.
- Try running Redis outside Docker or on a different host to compare performance.
Warm-Up Critical Endpoints:
- Implement a warm-up routine that triggers key AppService methods on application startup to pre-initialize caches and reduce cold start impact.
Review and Optimize ABP Features:
- Disable or defer non-essential ABP features (e.g., audit logging, validation) for endpoints where performance is critical.
Profile and Log ABP Middleware:
- Add detailed logging around ABP middleware and interceptors to pinpoint which component is causing the delay.
Compare with Direct Controller:
- As you have done, continue to compare AppService and direct controller performance to isolate ABP-specific overhead.
Update ABP and Dependencies:
- Ensure you are using the latest ABP version and all related packages, as performance improvements and bug fixes are released regularly.
References (validated)
These sources confirm that cold start delays are typically due to cache initialization, permission store population, or distributed cache latency, and are not inherent to every request. Optimizing your cache setup and pre-warming endpoints are the most effective mitigations.
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
How can it take so long to bring 7 records?
- We don't use Redis.
- Warm-Up Critical Endpoints, not is a solution
- Profile and Log ABP Middleware: Can you tell me how to collect this information, because I don't see where the delay is coming from. The method in the appservice is very fast.
-
0
Large DbContext Impact
Performance Correlation with DbContext Size
| Solution | Entity Count | DbContext Size | Cold Start Time | |---|---|---|---| | Current (Large) | ~XXX entities | Large/Complex | 6,900ms | | Comparison (Small) | ~XX entities | Small/Simple | 600ms |
The Problem
ABP Framework's cold start performance degrades exponentially with DbContext size:
- Small DbContext: Normal performance (~600ms)
- Large DbContext: 11.5x slower performance (6,900ms)
Why This Matters
- Scalability issue: Larger applications become unusable
- Enterprise impact: Real-world apps have large data models
- Framework limitation: ABP should handle large DbContexts efficiently
-
0
hi maria_ruiz
Can you share a project to reproduce the above problem?
liming.ma@volosoft.com
Thanks
-
0
Good morning,
I can't give you the solution as it is the company's project.
We would have to try to replicate it in a project of approximately 100 entities.
-
0
ok, you can test your code in a new template project.
Thanks.
-
0
Good morning again,
After many test, only slow when has many dependencies in the appservice.
We resolve that for the moment using LazyServiceProvider, now the endpoint is faster.
-
0
Great news 👍 That's the purpose of the
LazyServiceProvider.
