-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem: benchmark block stats is too long #1668
Conversation
Solution: - detect chain idle faster
WalkthroughThe changes in this pull request modify the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
testground/benchmark/benchmark/stateless.py (1)
303-303
: Verify the impact on resource utilization.
While reducing the polling interval will help detect idle states faster, polling too frequently might increase CPU usage. Consider adding resource utilization metrics to validate that 5 seconds is not too aggressive.
Consider these improvements:
- Add logging of detection timing for performance analysis
- Consider making the interval configurable through the config file
- Add resource utilization metrics during the idle detection phase
Example implementation:
def detect_idle_halted(idle_blocks: int, interval: int, chain_halt_interval=120):
"""
returns if the chain is empty for consecutive idle_blocks, or halted.
idle_blocks: the number of consecutive empty blocks to check
interval: poll interval in seconds (default: 5)
chain_halt_interval: the chain is considered halted if no new block for this time
"""
start_time = time.time()
last_time = start_time
prev_height = 0
poll_count = 0
while True:
poll_count += 1
latest = block_height()
if latest > prev_height:
prev_height = latest
last_time = time.time()
print(f"current block {latest} (polls: {poll_count}, " \
f"elapsed: {time.time() - start_time:.2f}s)")
# ... rest of the function
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- testground/benchmark/benchmark/stateless.py (1 hunks)
🔇 Additional comments (1)
testground/benchmark/benchmark/stateless.py (1)
303-303
: Consider documenting the rationale for the polling interval change.
The reduction in polling interval from 20 to 5 seconds will help detect chain idle states more quickly, aligning with the PR's objective to reduce benchmark duration. However, it's worth documenting why 5 seconds was chosen as the optimal interval.
Let's verify the impact of this change on the chain's performance:
✅ Verification successful
The polling interval change is well-documented and appropriate
The function's documentation clearly explains the purpose of the interval
parameter for polling. The change from 20 to 5 seconds is reasonable because:
- The function is used to detect chain idle state after sending transactions
- It's called in two contexts: after sending a batch of transactions and before process termination
- The shorter interval aligns with the PR's goal of reducing benchmark duration
- The function has built-in protection against chain halts with a separate
chain_halt_interval
parameter (120s)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any performance-related logs or issues with the previous polling interval
# Test 1: Look for any performance-related comments or issues in previous PRs
rg -i "detect_idle|polling interval|benchmark duration" .github/
# Test 2: Check for any related configuration parameters in the codebase
rg "poll.*interval|idle.*detect" --type yaml --type toml
Length of output: 125
Script:
#!/bin/bash
# Let's analyze the detect_idle_halted function implementation and its usage
# Find the implementation of detect_idle_halted
ast-grep --pattern 'def detect_idle_halted($$$)'
# Look for any comments or documentation about idle detection or polling
rg -B 2 -A 2 "detect_idle|poll.*interval" --type python
# Check for test files that might provide insights about the polling behavior
fd "test.*\.py$" --exec grep -l "detect_idle"
Length of output: 185
Script:
#!/bin/bash
# Let's try a different approach to find the implementation and usage
# Search for the function definition and its usage
rg -B 3 -A 10 "detect_idle_halted"
# Look for any configuration files that might contain polling settings
fd -e yaml -e toml -e json --exec grep -l "poll"
# Look for any test files or documentation about idle detection
rg -l "idle.*detect" --type md
Length of output: 3072
b6063d4
Solution:
👮🏻👮🏻👮🏻 !!!! REFERENCE THE PROBLEM YOUR ARE SOLVING IN THE PR TITLE AND DESCRIBE YOUR SOLUTION HERE !!!! DO NOT FORGET !!!! 👮🏻👮🏻👮🏻
PR Checklist:
make
)make test
)go fmt
)golangci-lint run
)go list -json -m all | nancy sleuth
)Thank you for your code, it's appreciated! :)
Summary by CodeRabbit
New Features
Bug Fixes