Add parallel benchmarks for router and route matching#3780
Add parallel benchmarks for router and route matching#3780CHANDRAHARSHIT wants to merge 3 commits into
Conversation
Introduces parallel benchmark variants for critical router and route matching paths to better reflect real-world concurrent workloads. These benchmarks use b.RunParallel and allocate per-goroutine state to avoid data races, helping to surface contention and synchronization costs. Documentation is updated with instructions and rationale for running the new parallel benchmarks.
|
Thanks for opening this pull request! 🎉 Please check out our contributing guidelines. If you need help or want to chat with us, join us on Discord https://gofiber.io/discord |
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughAdds a docs note and a suite of new parallel benchmarks in Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Dev as go test -bench
participant TB as testing.B
participant PB as b.RunParallel
participant W as Worker Goroutine
participant App as appHandler / Router
Dev->>TB: run Benchmark_*_Parallel
TB->>PB: call RunParallel(body)
PB->>W: spawn concurrent workers
loop per worker
W->>W: init per-goroutine fasthttp.RequestCtx
W->>App: call appHandler(ctx)
App-->>W: return response/status
end
PB-->>TB: finish
TB-->>Dev: report results
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello @CHANDRAHARSHIT, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the project's benchmarking suite by introducing parallel benchmarks for the router and route matching functionalities. The primary goal is to provide a more realistic performance evaluation under concurrent conditions, helping to uncover synchronization costs and potential performance regressions that might not be apparent in sequential tests. This change improves the robustness of performance testing without altering any production APIs. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Pull Request Overview
This PR adds parallel benchmark variants for the Fiber router to expose concurrency-related performance characteristics that are not visible in sequential benchmarks. The parallel benchmarks use b.RunParallel to surface mutex contention and synchronization costs under concurrent workloads.
- Adds 12 new parallel benchmark functions covering router hot paths and route matching scenarios
- Documents the new benchmarks in the "What's New" guide with usage examples
- Provides per-goroutine state allocation to avoid data races during concurrent execution
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| router_test.go | Adds parallel benchmark variants for router operations including method-not-allowed, not-found, handler execution, route chaining, and route matching |
| docs/whats_new.md | Documents the new parallel benchmarks section with rationale, usage examples, and contributor guidelines |
| // go test -benchmem -run=^$ -bench ^Benchmark_Router_Handler_StrictRouting_Parallel$ -count=1 | ||
| func Benchmark_Router_Handler_StrictRouting_Parallel(b *testing.B) { | ||
| app := New() | ||
| app.config.CaseSensitive = true |
There was a problem hiding this comment.
This benchmark sets CaseSensitive = true but the function name suggests it should test StrictRouting. This appears to be a copy-paste error from the CaseSensitive benchmark above.
| app.config.CaseSensitive = true | |
| app.config.StrictRouting = true |
|
|
||
| What’s included: | ||
|
|
||
| - Parallel versions of router handler benchmarks (e.g., method-not-allowed, not-found, handler, chaining, case sensitivity, strict routing, unescaping) |
There was a problem hiding this comment.
[nitpick] Consider using 'URL unescaping' instead of just 'unescaping' for clarity about what type of unescaping is being benchmarked.
| - Parallel versions of router handler benchmarks (e.g., method-not-allowed, not-found, handler, chaining, case sensitivity, strict routing, unescaping) | |
| - Parallel versions of router handler benchmarks (e.g., method-not-allowed, not-found, handler, chaining, case sensitivity, strict routing, URL unescaping) |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request is a valuable addition, introducing parallel benchmarks to better assess performance under concurrent loads. The implementation is solid, and the documentation update is helpful. I've identified a few minor issues in the new benchmarks, such as a misconfigured allocation report, a misnamed and duplicated benchmark, and another benchmark with a misleading name. I've also pointed out a small formatting issue in the documentation. Addressing these points will improve the clarity and correctness of the new tests.
| func Benchmark_Router_Handler_StrictRouting_Parallel(b *testing.B) { | ||
| app := New() | ||
| app.config.CaseSensitive = true |
There was a problem hiding this comment.
This benchmark is named Benchmark_Router_Handler_StrictRouting_Parallel, but it sets app.config.CaseSensitive = true instead of app.config.StrictRouting = true. This makes it a duplicate of Benchmark_Router_Handler_CaseSensitive_Parallel and doesn't test strict routing as the name implies. To fix this, you should set the StrictRouting property.
| func Benchmark_Router_Handler_StrictRouting_Parallel(b *testing.B) { | |
| app := New() | |
| app.config.CaseSensitive = true | |
| func Benchmark_Router_Handler_StrictRouting_Parallel(b *testing.B) { | |
| app := New() | |
| app.config.StrictRouting = true |
|
|
||
| ### Test Config | ||
|
|
||
| ## 🔬 Parallel Benchmarks |
There was a problem hiding this comment.
The heading level for 'Parallel Benchmarks' should probably be ### to be a sub-section of ## 🗺 Router, consistent with other sections like ### Test Config.
Also, this new section seems to be inserted in the middle of the 'Test Config' section. It should be moved to be either before or after the 'Test Config' section entirely to maintain the document's structure.
| ## 🔬 Parallel Benchmarks | |
| ### 🔬 Parallel Benchmarks |
| b.ReportAllocs() | ||
| app := New() | ||
| app.Use(func(c Ctx) error { return c.Next() }) | ||
| registerDummyRoutes(app) | ||
| appHandler := app.Handler() | ||
|
|
||
| b.ResetTimer() |
There was a problem hiding this comment.
To get accurate allocation metrics for the benchmarked code, b.ReportAllocs() should be called after the setup phase and just before b.ResetTimer(). Currently, it's including allocations from the setup (e.g., New(), registerDummyRoutes()), which can skew the results.
| b.ReportAllocs() | |
| app := New() | |
| app.Use(func(c Ctx) error { return c.Next() }) | |
| registerDummyRoutes(app) | |
| appHandler := app.Handler() | |
| b.ResetTimer() | |
| app := New() | |
| app.Use(func(c Ctx) error { return c.Next() }) | |
| registerDummyRoutes(app) | |
| appHandler := app.Handler() | |
| b.ReportAllocs() | |
| b.ResetTimer() |
| } | ||
|
|
||
| // go test -benchmem -run=^$ -bench ^Benchmark_Router_WithCompression_Parallel$ -count=1 | ||
| func Benchmark_Router_WithCompression_Parallel(b *testing.B) { |
There was a problem hiding this comment.
The name Benchmark_Router_WithCompression_Parallel is misleading. This benchmark registers the same route multiple times, which results in a single route with multiple handlers, effectively testing handler chaining. It does not seem to involve compression. This is similar to Benchmark_Router_Chain_Parallel. Consider renaming this benchmark to more accurately reflect what it's testing, or removing it if it's redundant.
|
@CHANDRAHARSHIT Remove the changes to docs/whats_new.md |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3780 +/- ##
==========================================
- Coverage 91.67% 91.65% -0.03%
==========================================
Files 113 113
Lines 11959 11959
==========================================
- Hits 10964 10961 -3
- Misses 731 733 +2
- Partials 264 265 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Deleted the documentation about parallel benchmarks from the 'whats_new.md' file. This streamlines the changelog and removes detailed benchmark instructions and tips.
Done |
|
@CHANDRAHARSHIT These benchmarks were created using AI, they are not properly benchmarking what their titles say. |
Reorganized and improved parallel benchmarks for router and route matching to increase concurrency coverage and validation. Added response status checks, improved per-goroutine isolation, and restored several non-parallel benchmarks with updated run counts. This enhances detection of race conditions and correctness under concurrent access.
This PR adds parallel benchmarks for Fiber's router and route matching components to detect concurrency-related performance issues that are not visible in sequential benchmarks. These benchmarks help identify mutex contention, race conditions, and synchronization overhead under realistic concurrent workloads. Problem Solved: Sequential benchmarks don't expose performance bottlenecks that only appear under concurrent load, such as mutex contention in route matching, parameter extraction races, and cache line sharing effects. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
router_test.go(3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.go
📄 CodeRabbit inference engine (AGENTS.md)
**/*.go: Format Go code using gofumpt (enforced viamake format)
Ensure code passes golangci-lint checks (enforced viamake lint)
Optimize struct field alignment using betteralign (enforced viamake betteralign)
Modernize Go code using gopls modernize (enforced viamake modernize)
Files:
router_test.go
🧬 Code graph analysis (1)
router_test.go (4)
app.go (4)
New(515-628)Handler(40-40)Config(113-418)Error(62-65)ctx_interface_gen.go (1)
Ctx(18-426)constants.go (1)
MethodGet(5-5)router.go (1)
Route(43-62)
| app := New() | ||
| h := func(c Ctx) error { | ||
| return c.SendString("Hello World!") | ||
| } | ||
| app.All("/this/is/a/", h) | ||
| app.Get("/this/is/a/dummy/route/oke", h) | ||
| appHandler := app.Handler() | ||
|
|
||
| b.ReportAllocs() | ||
| b.ResetTimer() | ||
|
|
||
| b.RunParallel(func(pb *testing.PB) { | ||
| c := &fasthttp.RequestCtx{} | ||
| c.Request.Header.SetMethod("DELETE") | ||
| c.URI().SetPath("/this/is/a/dummy/route/oke") | ||
|
|
||
| for pb.Next() { | ||
| c.Response.Reset() // Reset response for each iteration | ||
| appHandler(c) | ||
| // Validate the method not allowed response | ||
| if c.Response.StatusCode() != 405 { | ||
| b.Errorf("Expected 405, got %d", c.Response.StatusCode()) | ||
| } | ||
| } | ||
| }) |
There was a problem hiding this comment.
Keep the MethodNotAllowed assertions from the sequential benchmark
Currently the parallel variant only checks the status code, so we lose the header/body verifications that Benchmark_App_MethodNotAllowed performs. Those checks are what catch regressions in the Allow header or response payload, so we should keep them (run them once per goroutine to avoid skewing the numbers).
@@
- appHandler := app.Handler()
+ appHandler := app.Handler()
+ expectedAllow := MethodGet
+ expectedBody := utils.StatusMessage(StatusMethodNotAllowed)
@@
- b.RunParallel(func(pb *testing.PB) {
+ b.RunParallel(func(pb *testing.PB) {
c := &fasthttp.RequestCtx{}
c.Request.Header.SetMethod("DELETE")
c.URI().SetPath("/this/is/a/dummy/route/oke")
-
- for pb.Next() {
+ validated := false
+ for pb.Next() {
c.Response.Reset() // Reset response for each iteration
appHandler(c)
// Validate the method not allowed response
- if c.Response.StatusCode() != 405 {
- b.Errorf("Expected 405, got %d", c.Response.StatusCode())
+ if c.Response.StatusCode() != StatusMethodNotAllowed {
+ b.Errorf("Expected %d, got %d", StatusMethodNotAllowed, c.Response.StatusCode())
+ }
+ if !validated {
+ if allow := string(c.Response.Header.Peek("Allow")); allow != expectedAllow {
+ b.Errorf("Expected Allow header %q, got %q", expectedAllow, allow)
+ }
+ if body := string(c.Response.Body()); body != expectedBody {
+ b.Errorf("Expected body %q, got %q", expectedBody, body)
+ }
+ validated = true
}
}
})📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| app := New() | |
| h := func(c Ctx) error { | |
| return c.SendString("Hello World!") | |
| } | |
| app.All("/this/is/a/", h) | |
| app.Get("/this/is/a/dummy/route/oke", h) | |
| appHandler := app.Handler() | |
| b.ReportAllocs() | |
| b.ResetTimer() | |
| b.RunParallel(func(pb *testing.PB) { | |
| c := &fasthttp.RequestCtx{} | |
| c.Request.Header.SetMethod("DELETE") | |
| c.URI().SetPath("/this/is/a/dummy/route/oke") | |
| for pb.Next() { | |
| c.Response.Reset() // Reset response for each iteration | |
| appHandler(c) | |
| // Validate the method not allowed response | |
| if c.Response.StatusCode() != 405 { | |
| b.Errorf("Expected 405, got %d", c.Response.StatusCode()) | |
| } | |
| } | |
| }) | |
| app := New() | |
| h := func(c Ctx) error { | |
| return c.SendString("Hello World!") | |
| } | |
| app.All("/this/is/a/", h) | |
| app.Get("/this/is/a/dummy/route/oke", h) | |
| appHandler := app.Handler() | |
| expectedAllow := MethodGet | |
| expectedBody := utils.StatusMessage(StatusMethodNotAllowed) | |
| b.ReportAllocs() | |
| b.ResetTimer() | |
| b.RunParallel(func(pb *testing.PB) { | |
| c := &fasthttp.RequestCtx{} | |
| c.Request.Header.SetMethod("DELETE") | |
| c.URI().SetPath("/this/is/a/dummy/route/oke") | |
| validated := false | |
| for pb.Next() { | |
| c.Response.Reset() // Reset response for each iteration | |
| appHandler(c) | |
| // Validate the method not allowed response | |
| if c.Response.StatusCode() != StatusMethodNotAllowed { | |
| b.Errorf("Expected %d, got %d", StatusMethodNotAllowed, c.Response.StatusCode()) | |
| } | |
| if !validated { | |
| if allow := string(c.Response.Header.Peek("Allow")); allow != expectedAllow { | |
| b.Errorf("Expected Allow header %q, got %q", expectedAllow, allow) | |
| } | |
| if body := string(c.Response.Body()); body != expectedBody { | |
| b.Errorf("Expected body %q, got %q", expectedBody, body) | |
| } | |
| validated = true | |
| } | |
| } | |
| }) |
🤖 Prompt for AI Agents
In router_test.go around lines 1442 to 1466, the parallel benchmark only checks
the 405 status code and drops the header/body assertions from
Benchmark_App_MethodNotAllowed; update the parallel variant to preserve the
Allow header and response body verifications by performing those checks once per
goroutine to avoid skewing timings (e.g., after first appHandler call in each
goroutine capture and assert c.Response.Header.Peek("Allow") and
c.Response.Body() match expected values), keep the per-iteration status code
check inside the loop, and ensure response is properly Reset between iterations
so the one-time checks run safely without impacting benchmark metrics.
| app := New() | ||
| app.Use(func(c Ctx) error { | ||
| return c.Next() | ||
| }) | ||
| registerDummyRoutes(app) | ||
| appHandler := app.Handler() | ||
|
|
||
| b.ReportAllocs() | ||
| b.ResetTimer() | ||
|
|
||
| b.RunParallel(func(pb *testing.PB) { | ||
| c := &fasthttp.RequestCtx{} | ||
| c.Request.Header.SetMethod("DELETE") | ||
| c.URI().SetPath("/this/route/does/not/exist") | ||
|
|
||
| for pb.Next() { | ||
| c.Response.Reset() // Reset response for each iteration | ||
| appHandler(c) | ||
| // Validate the not found response | ||
| if c.Response.StatusCode() != 404 { | ||
| b.Errorf("Expected 404, got %d", c.Response.StatusCode()) | ||
| } | ||
| } | ||
| }) |
There was a problem hiding this comment.
Check the NotFound payload too
The sequential Benchmark_Router_NotFound asserts both the 404 status and the "Not Found" body. The parallel version only keeps the status check, so it can no longer catch regressions in the default response body. Mirror the sequential assertions (once per goroutine) to preserve coverage.
@@
- appHandler := app.Handler()
+ appHandler := app.Handler()
+ expectedBody := "Not Found"
@@
- b.RunParallel(func(pb *testing.PB) {
+ b.RunParallel(func(pb *testing.PB) {
c := &fasthttp.RequestCtx{}
c.Request.Header.SetMethod("DELETE")
c.URI().SetPath("/this/route/does/not/exist")
-
- for pb.Next() {
+ validated := false
+ for pb.Next() {
c.Response.Reset() // Reset response for each iteration
appHandler(c)
// Validate the not found response
- if c.Response.StatusCode() != 404 {
- b.Errorf("Expected 404, got %d", c.Response.StatusCode())
+ if c.Response.StatusCode() != StatusNotFound {
+ b.Errorf("Expected %d, got %d", StatusNotFound, c.Response.StatusCode())
+ }
+ if !validated {
+ if body := string(c.Response.Body()); body != expectedBody {
+ b.Errorf("Expected body %q, got %q", expectedBody, body)
+ }
+ validated = true
}
}
})📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| app := New() | |
| app.Use(func(c Ctx) error { | |
| return c.Next() | |
| }) | |
| registerDummyRoutes(app) | |
| appHandler := app.Handler() | |
| b.ReportAllocs() | |
| b.ResetTimer() | |
| b.RunParallel(func(pb *testing.PB) { | |
| c := &fasthttp.RequestCtx{} | |
| c.Request.Header.SetMethod("DELETE") | |
| c.URI().SetPath("/this/route/does/not/exist") | |
| for pb.Next() { | |
| c.Response.Reset() // Reset response for each iteration | |
| appHandler(c) | |
| // Validate the not found response | |
| if c.Response.StatusCode() != 404 { | |
| b.Errorf("Expected 404, got %d", c.Response.StatusCode()) | |
| } | |
| } | |
| }) | |
| app := New() | |
| app.Use(func(c Ctx) error { | |
| return c.Next() | |
| }) | |
| registerDummyRoutes(app) | |
| appHandler := app.Handler() | |
| expectedBody := "Not Found" | |
| b.ReportAllocs() | |
| b.ResetTimer() | |
| b.RunParallel(func(pb *testing.PB) { | |
| c := &fasthttp.RequestCtx{} | |
| c.Request.Header.SetMethod("DELETE") | |
| c.URI().SetPath("/this/route/does/not/exist") | |
| validated := false | |
| for pb.Next() { | |
| c.Response.Reset() // Reset response for each iteration | |
| appHandler(c) | |
| // Validate the not found response | |
| if c.Response.StatusCode() != StatusNotFound { | |
| b.Errorf("Expected %d, got %d", StatusNotFound, c.Response.StatusCode()) | |
| } | |
| if !validated { | |
| if body := string(c.Response.Body()); body != expectedBody { | |
| b.Errorf("Expected body %q, got %q", expectedBody, body) | |
| } | |
| validated = true | |
| } | |
| } | |
| }) |
🤖 Prompt for AI Agents
In router_test.go around lines 1471 to 1494, the parallel benchmark checks only
the 404 status and omits the Not Found response body assertion; add a
per-goroutine assertion after appHandler(c) that validates
c.Response.StatusCode() == 404 and also that the response body equals the
expected "Not Found" string (convert c.Response.Body() to string or compare
bytes), and call b.Errorf if the body does not match—keep the check inside the
for pb.Next() loop so each iteration validates the payload.
No description provided.