Repository navigation
Conversation
Falcon preloads the app, forks worker processes, and serves many concurrent requests per worker as fibers on one thread. Without an integration the agent falls back to Null: it reports the app server as "null" and starts lazily on each worker's first request. ServerIntegrations::Falcon reports "falcon" and starts the agent in every forked child through Process._fork (Ruby >= 3.1), so workers the supervisor restarts are covered too. It defers start in the preloading parent, which serves no requests, so no reporting thread is mid-request when Falcon forks. The allocation counter is per OS thread, so every request on a Falcon worker was charged for the allocations of every request overlapping it. The extension now charges allocations to the running fiber on each RUBY_EVENT_FIBER_SWITCH, and Allocations.count returns the current fiber's total. Single-fiber threads see no change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Under Falcon the agent has no server integration, so it reports the app server as
nulland starts lazily on each worker's first request. This addsServerIntegrations::Falcon. It reportsfalconand starts the agent in every forked worker throughProcess._fork, which also covers workers the supervisor restarts. It deliberately does not start in the preloading parent, which serves no requests and keeps forking: a reporting thread caught mid-request at fork time could leave locks held in the child.The bigger problem is allocations. Falcon runs many requests on one thread as fibers, and the allocation counter is per OS thread, so each request was charged for the allocations of every request overlapping it. At about 44 overlapping requests per worker, a request allocating about 24k objects was reported at about 4M. The extension now charges allocations to the running fiber on
RUBY_EVENT_FIBER_SWITCH. With this branch, the same Rails app under real Falcon reports about 24k whether requests overlap or not, and the per-request layers, SQL and HTTP spans are unchanged. The full suite passes locally on Ruby 4.0.7 with and withoutSCOUT_USE_PREPEND(287 runs, 0 failures), and new tests cover both changes.🤖 Generated with Claude Code