Agent skill · software engineering · jeremylongshore
quicknode-performance-tuning
Tune QuickNode RPC performance from endpoint metrics, method mix, payload size, connection reuse, and chain semantics instead of synthetic request counts. Use when tail latency, errors, or credit use regress. Trigger with: "optimize QuickNode latency", "analyze QuickNode p95", "reduce RPC response time".
Why this skill is useful
Provides specific implementation patterns and error handling for QuickNode RPC endpoints that the AI wouldn't reliably generate on its own.
What it needs
Requires quicknode account access. About 2k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
QuickNode Performance Tuning Overview Optimize against a declared service-level objective and QuickNode's endpoint metrics. Separate provider latency from client queueing, chain execution, payload transfer, and downstream decoding. Prerequisites Endpoint ID, chain, network, and latency/error SLO A representative method and payload workload Access to endpoint metrics or an application-side measurement source Instructions Step 1: Establish a baseline Use Read and Grep to find timeouts, concurrency, connection pools, retries, batch settings, and method mix. Measure end-to-end and provider-call latency separately. Step 2: Read provider metrics Use Bash(qn:) for authenticated endpoint metrics, including method calls, response codes, chain errors, and supported percentile views. Keep the time range and percentile explicit. Step 3: Segment the workload Compare method, network, payload size, block age, cacheability, and protocol. Historical traces and large log ranges must not be averaged with a small latest-block read. Step 4: Remove avoidable work Use Write or Edit to reuse connections and configured clients, coalesce identical reads, cache immutable block results, paginate large ranges, and request only necessary fields where the API supports it. Step 5: Control concurrency Set a bounded in-flight limit below measured saturation. Use JSON-RPC batching only where the chain and client contract support it, and cap both batch count and response size. Step 6: Validate the change Replay the same workload and compare p50, p95, p99, error rate, credits, and application queue time. Roll back if tail latency or chain-error rates worsen even when the mean improves. Tool Discipline Use Read and Grep for code and configuration discovery, Bash(qn:) for read-only metrics, and Write/Edit for bounded performance changes and tests. Do not change production capacity or rate limits implicitly. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/quicknode-performance-tuning