{ "schemaVersion": "1.0", "item": { "slug": "afrexai-performance-engineering", "name": "Performance Engineering System", "source": "tencent", "type": "skill", "category": "开发工具", "sourceUrl": "https://clawhub.ai/1kalin/afrexai-performance-engineering", "canonicalUrl": "https://clawhub.ai/1kalin/afrexai-performance-engineering", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/afrexai-performance-engineering", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=afrexai-performance-engineering", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "README.md", "SKILL.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-30T16:55:25.780Z", "expiresAt": "2026-05-07T16:55:25.780Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=network", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=network", "contentDisposition": "attachment; filename=\"network-1.0.0.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/afrexai-performance-engineering" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/afrexai-performance-engineering", "agentPageUrl": "https://openagent3.xyz/skills/afrexai-performance-engineering/agent", "manifestUrl": "https://openagent3.xyz/skills/afrexai-performance-engineering/agent.json", "briefUrl": "https://openagent3.xyz/skills/afrexai-performance-engineering/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "Performance Engineering System", "body": "From \"it's slow\" to \"here's why and here's the fix\" — a complete methodology for measuring, diagnosing, optimizing, and preventing performance problems." }, { "title": "Phase 1: Performance Investigation Brief", "body": "Before touching anything, define the problem.\n\n# performance-brief.yaml\ninvestigation:\n reported_by: \"\"\n reported_date: \"\"\n system: \"\" # service/app name\n environment: \"\" # production, staging, dev\n\nproblem_statement:\n symptom: \"\" # \"API response time increased 3x\"\n impact: \"\" # \"15% of users seeing timeouts\"\n since_when: \"\" # \"After deploy v2.14 on Feb 20\"\n affected_scope: \"\" # \"All endpoints\" | \"Only /search\" | \"Users in EU\"\n\nbaselines:\n target_p50: \"\" # e.g., \"200ms\"\n target_p95: \"\" # e.g., \"500ms\"\n target_p99: \"\" # e.g., \"1000ms\"\n current_p50: \"\"\n current_p95: \"\"\n current_p99: \"\"\n throughput_target: \"\" # e.g., \"1000 rps\"\n error_rate_target: \"\" # e.g., \"<0.1%\"\n\nconstraints:\n budget: \"\" # time/money for optimization\n risk_tolerance: \"\" # \"Can we change the schema?\" \"Can we add caching?\"\n deadline: \"\" # \"Must fix before Black Friday\"\n\nhypothesis:\n primary: \"\" # \"N+1 queries in the new recommendation engine\"\n secondary: \"\" # \"Connection pool exhaustion under load\"\n evidence: \"\" # \"Slow query log shows 200+ queries per request\"" }, { "title": "Performance Budget Framework", "body": "Set budgets BEFORE building, not after complaints:\n\nMetricWeb AppAPIMobileBatch JobP50 response<200ms<100ms<300msN/AP95 response<500ms<250ms<800msN/AP99 response<1s<500ms<1.5sN/AError rate<0.1%<0.01%<0.5%<0.001%Time to Interactive<3sN/A<2sN/AMemory per request<50MB<20MB<100MB<1GBCPU per request<100ms<50ms<200msN/AThroughput100+ rps500+ rpsN/Aitems/min" }, { "title": "The Golden Rule", "body": "Never optimize without measuring first. Never measure without a hypothesis." }, { "title": "Profiling Decision Tree", "body": "Is it slow?\n├── YES → Where is time spent?\n│ ├── CPU-bound → Profile CPU (flame graph)\n│ │ ├── Hot function found → Optimize algorithm/data structure\n│ │ └── Spread evenly → Architecture problem (too many layers)\n│ ├── I/O-bound → Profile I/O\n│ │ ├── Database → Query analysis (Phase 4)\n│ │ ├── Network → Connection profiling\n│ │ ├── Disk → I/O scheduler + buffering\n│ │ └── External API → Caching + async + circuit breaker\n│ ├── Memory-bound → Profile allocations\n│ │ ├── GC pressure → Reduce allocations, pool objects\n│ │ ├── Memory leak → Heap snapshot comparison\n│ │ └── Cache thrashing → Resize or eviction policy\n│ └── Concurrency-bound → Profile locks/contention\n│ ├── Lock contention → Reduce critical section, lock-free structures\n│ ├── Thread starvation → Pool sizing\n│ └── Deadlock → Lock ordering analysis\n└── NO → Define \"fast enough\" (see budgets above)" }, { "title": "CPU Profiling by Language", "body": "Node.js\n\n# Built-in profiler (V8)\nnode --prof app.js\nnode --prof-process isolate-*.log > profile.txt\n\n# Inspector-based (connect Chrome DevTools)\nnode --inspect app.js\n# Open chrome://inspect → Profiler → Start\n\n# Clinic.js (best overall Node.js profiler)\nnpx clinic doctor -- node app.js\nnpx clinic flame -- node app.js # Flame graph\nnpx clinic bubbleprof -- node app.js # Async bottlenecks\n\n# 0x (flame graphs)\nnpx 0x app.js\n\nPython\n\n# cProfile (built-in)\nimport cProfile\nimport pstats\n\nprofiler = cProfile.Profile()\nprofiler.enable()\n# ... code to profile ...\nprofiler.disable()\n\nstats = pstats.Stats(profiler)\nstats.sort_stats('cumulative')\nstats.print_stats(20) # Top 20\n\n# Line profiler (pip install line-profiler)\n# Add @profile decorator, then:\n# kernprof -l -v script.py\n\n# py-spy (sampling profiler, no code changes)\n# pip install py-spy\n# py-spy top --pid \n# py-spy record -o profile.svg --pid # Flame graph\n\n# Scalene (CPU + memory + GPU)\n# pip install scalene\n# scalene script.py\n\nGo\n\n// Built-in pprof\nimport (\n \"net/http\"\n _ \"net/http/pprof\"\n \"runtime/pprof\"\n)\n\n// HTTP server (add to existing server)\n// Access: http://localhost:6060/debug/pprof/\ngo func() { http.ListenAndServe(\":6060\", nil) }()\n\n// CLI analysis\n// go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30\n// go tool pprof -http=:8080 profile.out # Web UI\n\nJava\n\n# async-profiler (best for JVM)\n# https://github.com/async-profiler/async-profiler\n./asprof -d 30 -f profile.html \n\n# JFR (built-in since JDK 11)\njava -XX:StartFlightRecording=duration=60s,filename=rec.jfr MyApp\njfr print --events CPULoad rec.jfr\n\n# jstack (thread dump)\njstack > threads.txt" }, { "title": "Memory Profiling", "body": "Leak Detection Pattern (any language)\n\n1. Take heap snapshot at T0\n2. Run suspected operation N times\n3. Force GC\n4. Take heap snapshot at T1\n5. Compare: objects that grew = potential leak\n6. Check: are they reachable? From where? (retention path)\n\nNode.js Memory\n\n// Heap snapshot\nconst v8 = require('v8');\nconst fs = require('fs');\n\nfunction takeSnapshot(label) {\n const snapshotStream = v8.writeHeapSnapshot();\n console.log(`Heap snapshot written to ${snapshotStream}`);\n}\n\n// Process memory monitoring\nsetInterval(() => {\n const mem = process.memoryUsage();\n console.log({\n rss_mb: (mem.rss / 1048576).toFixed(1),\n heap_used_mb: (mem.heapUsed / 1048576).toFixed(1),\n heap_total_mb: (mem.heapTotal / 1048576).toFixed(1),\n external_mb: (mem.external / 1048576).toFixed(1),\n });\n}, 10000);\n\nPython Memory\n\n# tracemalloc (built-in)\nimport tracemalloc\n\ntracemalloc.start()\n# ... code ...\nsnapshot = tracemalloc.take_snapshot()\ntop = snapshot.statistics('lineno')\nfor stat in top[:10]:\n print(stat)\n\n# objgraph (pip install objgraph)\nimport objgraph\nobjgraph.show_most_common_types(limit=20)\nobjgraph.show_growth(limit=10) # Call twice to see what's growing" }, { "title": "Flame Graph Interpretation", "body": "Reading a flame graph:\n┌─────────────────────────────────────────────┐\n│ main() │ ← Entry point (bottom)\n├──────────────────────┬──────────────────────┤\n│ processData() │ renderOutput() │ ← Width = time spent\n├──────────┬───────────┤ │\n│ parseCSV │ validate │ │ ← Tall = deep call stack\n├──────────┤ │ │\n│ readline │ │ │ ← Top = where CPU burns\n└──────────┴───────────┴──────────────────────┘\n\nWHAT TO LOOK FOR:\n1. Wide plateaus at top → CPU-intensive leaf function (optimize this!)\n2. Many thin towers → excessive function calls (batch or reduce)\n3. Recursive patterns → potential stack overflow risk\n4. Unexpected width → function taking more time than expected\n5. GC/runtime frames → memory pressure\n\nACTION RULES:\n- Plateau >20% width → must investigate\n- Plateau >40% width → almost certainly the bottleneck\n- If top 3 functions = 80% of time → focused optimization will work\n- If evenly distributed → architectural change needed" }, { "title": "Algorithm & Data Structure Optimizations", "body": "ProblemBad O()FixGood O()Search unsorted arrayO(n)Sort + binary search, or use Set/MapO(log n) or O(1)Nested loop matchingO(n²)Hash map lookupO(n)Repeated string concatO(n²)StringBuilder/join arrayO(n)Sorting already-sorted dataO(n log n)Check if sorted firstO(n)Finding duplicatesO(n²)Set-based detectionO(n)Frequent min/max of changing dataO(n) per queryHeap/priority queueO(log n)" }, { "title": "Caching Strategy Decision Matrix", "body": "Should you cache this?\n├── Does the same input always produce the same output?\n│ ├── YES → Cache candidate ✓\n│ └── NO → Can you define a valid TTL?\n│ ├── YES → Cache with TTL ✓\n│ └── NO → Don't cache ✗\n├── Is it called frequently?\n│ ├── <10x/min → Probably not worth caching\n│ └── >10x/min → Cache ✓\n├── Is the source data expensive to compute/fetch?\n│ ├── <10ms → Probably not worth caching\n│ └── >10ms → Cache ✓\n└── Does staleness cause problems?\n ├── Critical (financial, auth) → Short TTL or cache-aside with invalidation\n ├── Important (user data) → 1-5 min TTL with invalidation\n └── Tolerant (content, search) → 5-60 min TTL\n\nCACHE LAYERS (use in order):\n1. In-process (Map/LRU) → <1μs, limited by memory, per-instance\n2. Shared cache (Redis/Memcached) → <1ms, shared across instances\n3. CDN/edge cache → <10ms, geographic distribution\n4. Browser cache → 0ms for user, stale risk\n\nINVALIDATION STRATEGIES:\n- TTL-based: simplest, best for read-heavy + staleness-tolerant\n- Event-based: publish cache-invalidate on write, best for consistency\n- Write-through: update cache on every write, best for write-read patterns\n- Cache-aside: app manages cache explicitly, most flexible" }, { "title": "Connection Pooling", "body": "# Sizing formula\npool_size: min(available_cores * 2 + effective_spindle_count, max_connections / num_instances)\n\n# Rules of thumb:\n# - PostgreSQL: connections = cores * 2 + 1 (per pgBouncer docs)\n# - MySQL: keep total connections < 150 for most workloads\n# - HTTP clients: match to concurrent request volume\n# - Redis: usually 5-10 per instance is enough\n\n# Warning signs of pool problems:\n# - \"connection timeout\" errors under load\n# - Response time spikes at regular intervals\n# - Idle connections holding resources\n# - Connection count hitting max_connections" }, { "title": "Async & Concurrency Patterns", "body": "// BAD: Sequential when independent\nconst user = await getUser(id);\nconst orders = await getOrders(id);\nconst prefs = await getPreferences(id);\n// Total: user_time + orders_time + prefs_time\n\n// GOOD: Parallel when independent\nconst [user, orders, prefs] = await Promise.all([\n getUser(id),\n getOrders(id),\n getPreferences(id),\n]);\n// Total: max(user_time, orders_time, prefs_time)\n\n// GOOD: Controlled concurrency for many items\n// (npm: p-limit, p-map, or manual semaphore)\nimport pLimit from 'p-limit';\nconst limit = pLimit(10); // Max 10 concurrent\nconst results = await Promise.all(\n items.map(item => limit(() => processItem(item)))\n);\n\n# Python: asyncio for I/O-bound\nimport asyncio\n\nasync def fetch_all(ids):\n # Parallel\n tasks = [fetch_one(id) for id in ids]\n return await asyncio.gather(*tasks)\n\n# Python: ProcessPoolExecutor for CPU-bound\nfrom concurrent.futures import ProcessPoolExecutor\nwith ProcessPoolExecutor(max_workers=4) as pool:\n results = list(pool.map(cpu_intensive_fn, items))" }, { "title": "N+1 Query Detection & Fix", "body": "SYMPTOM: Response time scales linearly with result count\nDETECTION: Enable query logging, count queries per request\n\n# Bad: N+1\nusers = db.query(\"SELECT * FROM users LIMIT 100\")\nfor user in users:\n orders = db.query(f\"SELECT * FROM orders WHERE user_id = {user.id}\")\n# Result: 1 + 100 = 101 queries\n\n# Fix 1: JOIN\nSELECT u.*, o.* FROM users u\nLEFT JOIN orders o ON o.user_id = u.id\nLIMIT 100\n\n# Fix 2: Batch load (better for large datasets)\nusers = db.query(\"SELECT * FROM users LIMIT 100\")\nuser_ids = [u.id for u in users]\norders = db.query(f\"SELECT * FROM orders WHERE user_id IN ({','.join(user_ids)})\")\n# Result: 2 queries regardless of count\n\n# Fix 3: ORM eager loading\n# Drizzle: .with(users.orders)\n# SQLAlchemy: joinedload(User.orders)\n# Prisma: include: { orders: true }" }, { "title": "Query Optimization Checklist", "body": "For every slow query:\n□ Run EXPLAIN ANALYZE (not just EXPLAIN)\n□ Check: is it doing a sequential scan on a large table?\n□ Check: is the row estimate accurate? (bad stats = bad plan)\n□ Check: are there implicit type casts preventing index use?\n□ Check: is it sorting more data than needed? (add LIMIT earlier)\n□ Check: is it joining in the right order?\n□ Check: can a covering index eliminate table lookups?\n□ Check: is the query running during peak hours? (schedule if batch)" }, { "title": "EXPLAIN ANALYZE Interpretation", "body": "-- PostgreSQL EXPLAIN output reading guide:\nEXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) SELECT ...;\n\n-- Key metrics to check:\n-- 1. Actual time vs estimated time (large gap = stale stats → ANALYZE)\n-- 2. Rows actual vs estimated (>10x off = bad stats)\n-- 3. Seq Scan on large table (>10K rows) = needs index\n-- 4. Sort with external merge = needs more work_mem or index\n-- 5. Nested Loop with large outer = consider hash/merge join\n-- 6. Buffers shared hit vs read (low hit ratio = needs more shared_buffers)" }, { "title": "Index Strategy Guide", "body": "WHEN TO ADD AN INDEX:\n✓ WHERE clause column (equality or range)\n✓ JOIN condition column\n✓ ORDER BY column (if query is index-only scan candidate)\n✓ Foreign key column (prevents table lock on parent delete)\n✓ Column in a unique constraint\n\nWHEN NOT TO ADD AN INDEX:\n✗ Table has <1000 rows (seq scan is fine)\n✗ Column has very low cardinality (boolean, status with 3 values)\n✗ Write-heavy table where reads are rare\n✗ You already have 8+ indexes on the table (diminishing returns, write penalty)\n\nINDEX TYPES:\n- B-tree (default): equality, range, sorting, LIKE 'prefix%'\n- Hash: equality only (rarely better than B-tree)\n- GIN: arrays, JSONB, full-text search\n- GiST: geometry, range types, full-text\n- BRIN: large tables with natural ordering (timestamps, sequential IDs)\n\nCOMPOSITE INDEX RULES:\n1. Equality columns first, then range columns\n2. Most selective column first (if all equality)\n3. Index on (a, b) works for WHERE a=1 AND b=2 AND for WHERE a=1 alone\n4. Index on (a, b) does NOT work for WHERE b=2 alone" }, { "title": "Load Test Design", "body": "# load-test-plan.yaml\ntest_name: \"\"\ntarget: \"\" # URL/endpoint\ndate: \"\"\n\nscenarios:\n - name: \"Baseline\"\n description: \"Normal traffic pattern\"\n vus: 50 # Virtual users\n duration: \"5m\"\n ramp_up: \"30s\"\n think_time: \"1-3s\" # Pause between requests\n\n - name: \"Peak\"\n description: \"2x normal traffic (expected peak)\"\n vus: 100\n duration: \"10m\"\n ramp_up: \"1m\"\n\n - name: \"Stress\"\n description: \"Find the breaking point\"\n vus_start: 50\n vus_end: 500\n step_duration: \"2m\" # Add users every 2 min\n step_size: 50\n\n - name: \"Soak\"\n description: \"Memory leaks, connection exhaustion\"\n vus: 50\n duration: \"2h\"\n\npass_criteria:\n p95_response_ms: 500\n error_rate_pct: 0.1\n throughput_rps: 200" }, { "title": "k6 Load Test Template", "body": "// load-test.js (run: k6 run load-test.js)\nimport http from 'k6/http';\nimport { check, sleep } from 'k6';\nimport { Rate, Trend } from 'k6/metrics';\n\nconst errorRate = new Rate('errors');\nconst responseTime = new Trend('response_time');\n\nexport const options = {\n stages: [\n { duration: '30s', target: 20 }, // Ramp up\n { duration: '3m', target: 20 }, // Steady\n { duration: '30s', target: 50 }, // Peak\n { duration: '3m', target: 50 }, // Steady peak\n { duration: '30s', target: 0 }, // Ramp down\n ],\n thresholds: {\n http_req_duration: ['p(95)<500'], // 95% under 500ms\n errors: ['rate<0.01'], // <1% error rate\n },\n};\n\nexport default function () {\n const res = http.get('https://api.example.com/endpoint');\n\n check(res, {\n 'status 200': (r) => r.status === 200,\n 'response < 500ms': (r) => r.timings.duration < 500,\n });\n\n errorRate.add(res.status !== 200);\n responseTime.add(res.timings.duration);\n\n sleep(Math.random() * 2 + 1); // 1-3s think time\n}" }, { "title": "Load Test Results Analysis", "body": "READING RESULTS:\n┌──────────────────────────────────────────┐\n│ Metric │ Healthy │ Warning │ Bad│\n├──────────────────────────────────────────┤\n│ p50/p95 ratio │ <2x │ 2-5x │>5x│ ← High ratio = tail latency problem\n│ p95/p99 ratio │ <2x │ 2-3x │>3x│ ← Outliers affecting some users\n│ Error rate │ <0.1% │ 0.1-1% │>1%│ ← Above 1% = user-visible\n│ Throughput drop │ <5% │ 5-20% │>20%│ ← System under stress\n│ CPU at peak │ <70% │ 70-85% │>85%│ ← No headroom\n│ Memory at peak │ <75% │ 75-90% │>90%│ ← Risk of OOM\n│ GC pause time │ <50ms │ 50-200ms│>200ms│ ← GC storm\n└──────────────────────────────────────────┘\n\nBOTTLENECK IDENTIFICATION:\n- Throughput plateaus but CPU is low → I/O bound (DB, network, disk)\n- Throughput plateaus and CPU is high → CPU bound (optimize hot path)\n- Response time climbs linearly → Queue building (capacity limit)\n- Response time climbs exponentially → Resource exhaustion (connection pool, memory)\n- Errors spike at specific VU count → Hard limit hit (max connections, file descriptors)" }, { "title": "Core Web Vitals Optimization", "body": "METRIC │ GOOD │ NEEDS WORK │ POOR │ HOW TO FIX\n────────────┼─────────┼────────────┼────────┼────────────────────────\nLCP │ <2.5s │ 2.5-4s │ >4s │ Optimize largest image/text\nFID/INP │ <100ms │ 100-300ms │ >300ms │ Break up long tasks, defer JS\nCLS │ <0.1 │ 0.1-0.25 │ >0.25 │ Set dimensions, font-display\n\nLCP FIXES (in priority order):\n1. Preload the LCP image: \n2. Use responsive images: srcset with correct sizes\n3. Serve WebP/AVIF (30-50% smaller)\n4. Remove render-blocking CSS/JS from \n5. Use CDN for static assets\n6. Server-side render the above-fold content\n\nINP FIXES:\n1. Break long tasks (>50ms) with requestIdleCallback or setTimeout(0)\n2. Use web workers for CPU-intensive work\n3. Debounce/throttle event handlers\n4. Defer non-critical JS: