performance-engineering — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited performance-engineering (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Performance engineering encompasses load testing, profiling, and optimization to deliver reliable, scalable systems. This skill provides frameworks for choosing the right performance testing approach (load, stress, soak, spike), profiling techniques to identify bottlenecks (CPU, memory, I/O), and optimization strategies for backend APIs, databases, and frontend applications.
Use this skill to validate system capacity before launch, detect performance regressions in CI/CD pipelines, identify and resolve bottlenecks through profiling, and optimize application responsiveness across the stack.
Common Triggers:
Use Cases:
Validate system behavior under expected traffic levels.
When to use: Pre-launch capacity planning, regression testing after refactors, validating auto-scaling.
Find system capacity limits and failure modes.
When to use: Capacity planning, understanding failure behavior, infrastructure sizing decisions.
Identify memory leaks, resource exhaustion, and degradation over time.
When to use: Detecting memory leaks, validating connection pool cleanup, testing long-running batch jobs.
Validate system response to sudden traffic spikes.
When to use: Validating auto-scaling, testing event-driven systems (product launches), ensuring rate limiting works.
Which test type to use?
What am I trying to learn?
├─ Can my system handle expected traffic? → LOAD TEST
├─ What's the maximum capacity? → STRESS TEST
├─ Will it stay stable over time? → SOAK TEST
└─ Can it handle traffic spikes? → SPIKE TESTFor detailed testing patterns, load scenarios, and interpreting results, see references/testing-types.md.
Installation:
brew install k6 # macOS
sudo apt-get install k6 # LinuxBasic Load Test:
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '30s', target: 20 },
{ duration: '1m', target: 20 },
{ duration: '30s', target: 0 },
],
thresholds: {
http_req_duration: ['p(95)<500'],
http_req_failed: ['rate<0.01'],
},
};
export default function () {
const res = http.get('https://api.example.com/products');
check(res, {
'status is 200': (r) => r.status === 200,
});
sleep(1);
}Run: k6 run script.js
For stress, soak, and spike testing examples, see examples/k6/.
Installation:
pip install locustBasic Load Test:
from locust import HttpUser, task, between
class WebsiteUser(HttpUser):
wait_time = between(1, 3)
host = "https://api.example.com"
@task(3)
def view_products(self):
self.client.get("/products")
@task(1)
def view_product_detail(self):
self.client.get("/products/123")Run: locust -f locustfile.py --headless -u 100 -r 10 --run-time 10m
For REST API testing and data-driven testing, see examples/locust/.
| Symptom | Profiling Type | Tool |
|---|---|---|
| High CPU (>70%) | CPU Profiling | py-spy, pprof, DevTools |
| Memory growing | Memory Profiling | memory_profiler, pprof heap |
| Slow response, low CPU | I/O Profiling | Query logs, pprof block |
py-spy (Production-Safe):
pip install py-spy
# Profile running process
py-spy record -o profile.svg --pid <PID> --duration 30
# Top-like view
py-spy top --pid <PID>Memory Profiling:
from memory_profiler import profile
@profile
def my_function():
a = [1] * (10 ** 6)
return a
# Run: python -m memory_profiler script.pypprof (Built-in):
import (
"net/http"
_ "net/http/pprof"
)
func main() {
go func() {
http.ListenAndServe("localhost:6060", nil)
}()
startApp()
}Capture profile:
# CPU profile (30 seconds)
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
# Interactive analysis
(pprof) top
(pprof) webChrome DevTools (Browser/Node.js):
Node.js:
node --inspect app.js
# Open chrome://inspect
# Performance tab → Recordclinic.js (Node.js):
npm install -g clinic
clinic doctor -- node app.jsFor detailed profiling workflows and analysis, see references/profiling-guide.md and examples/profiling/.
When to cache:
Redis example:
import redis
r = redis.Redis()
def get_cached_data(key, fn, ttl=300):
cached = r.get(key)
if cached:
return json.loads(cached)
data = fn()
r.setex(key, ttl, json.dumps(data))
return dataN+1 prevention:
# Bad: N+1 queries
users = User.query.all()
for user in users:
print(user.orders) # Separate query per user
# Good: Eager loading
users = User.query.options(joinedload(User.orders)).all()Indexing:
CREATE INDEX idx_users_email ON users(email);Cursor-based pagination:
app.get('/api/products', async (req, res) => {
const { cursor, limit = 20 } = req.query;
const products = await db.query(
'SELECT * FROM products WHERE id > ? ORDER BY id LIMIT ?',
[cursor || 0, limit]
);
res.json({
data: products,
next_cursor: products[products.length - 1]?.id,
});
});Key metrics:
Optimization techniques:
For detailed optimization strategies, see references/optimization-strategies.md and references/frontend-performance.md.
| Service Type | p95 Latency | p99 Latency | Availability |
|---|---|---|---|
| User-Facing API | < 200ms | < 500ms | 99.9% |
| Internal API | < 100ms | < 300ms | 99.5% |
| Database Query | < 50ms | < 100ms | 99.99% |
| Background Job | < 5s | < 10s | 99% |
| Real-time API | < 50ms | < 100ms | 99.95% |
For detailed SLO framework and performance budgets, see references/slo-framework.md.
GitHub Actions example:
name: Performance Tests
on:
pull_request:
branches: [main]
jobs:
load-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install k6
run: |
curl https://github.com/grafana/k6/releases/download/v0.48.0/k6-v0.48.0-linux-amd64.tar.gz -L | tar xvz
sudo mv k6-v0.48.0-linux-amd64/k6 /usr/local/bin/
- name: Run load test
run: k6 run tests/load/api-test.jsPerformance budgets:
// k6 test with thresholds (fail build if violated)
export const options = {
thresholds: {
http_req_duration: ['p(95)<500'],
http_req_failed: ['rate<0.01'],
},
};Standard process:
Best practices:
Primary: k6 (JavaScript-based, Grafana-backed)
When to use: Modern APIs, microservices, CI/CD integration.
Alternative: Locust (Python-based)
When to use: Python-heavy teams, complex user flows.
Python:
Go:
TypeScript/JavaScript:
For detailed tool comparisons, see references/testing-types.md and references/profiling-guide.md.
Detailed Guides:
references/testing-types.md - Load, stress, soak, spike testing patternsreferences/profiling-guide.md - CPU, memory, I/O profiling across languagesreferences/optimization-strategies.md - Caching, database, API optimizationreferences/frontend-performance.md - Core Web Vitals, bundle optimizationreferences/slo-framework.md - Setting SLOs, performance budgetsreferences/benchmarking.md - Benchmarking best practicesExamples:
examples/k6/ - Load, stress, soak, spike testsexamples/locust/ - Python-based load testingexamples/profiling/ - Profiling examples (Python, Go, TypeScript)examples/optimization/ - Caching, query, API optimizationFor comprehensive testing strategies, see the testing-strategies skill.
For CI/CD integration patterns, see the building-ci-pipelines skill.
For infrastructure sizing based on load tests, see the infrastructure-as-code skill.
For Kubernetes performance testing, see the kubernetes-operations skill.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.