- Create benchmark test suites for critical operations: - Node loading performance - Database query performance - Search operations performance - Validation performance - MCP tool execution performance - Add GitHub Actions workflow for benchmark tracking: - Runs on push to main and PRs - Uses github-action-benchmark for historical tracking - Comments on PRs with performance results - Alerts on >10% performance regressions - Stores results in GitHub Pages - Create benchmark infrastructure: - Custom Vitest benchmark configuration - JSON reporter for CI results - Result formatter for github-action-benchmark - Performance threshold documentation - Add supporting utilities: - SQLiteStorageService for benchmark database setup - MCPEngine wrapper for testing MCP tools - Test factories for generating benchmark data - Enhanced NodeRepository with benchmark methods - Document benchmark system: - Comprehensive benchmark guide in docs/BENCHMARKS.md - Performance thresholds in .github/BENCHMARK_THRESHOLDS.md - README for benchmarks directory - Integration with existing test suite The benchmark system will help monitor performance over time and catch regressions before they reach production. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
5.2 KiB
5.2 KiB
n8n-mcp Performance Benchmarks
Overview
The n8n-mcp project includes comprehensive performance benchmarks to ensure optimal performance across all critical operations. These benchmarks help identify performance regressions and guide optimization efforts.
Running Benchmarks
Local Development
# Run all benchmarks
npm run benchmark
# Run in watch mode
npm run benchmark:watch
# Run with UI
npm run benchmark:ui
# Run specific benchmark suite
npm run benchmark tests/benchmarks/node-loading.bench.ts
Continuous Integration
Benchmarks run automatically on:
- Every push to
mainbranch - Every pull request
- Manual workflow dispatch
Results are:
- Tracked over time using GitHub Actions
- Displayed in PR comments
- Available at: https://czlonkowski.github.io/n8n-mcp/benchmarks/
Benchmark Suites
1. Node Loading Performance
Tests the performance of loading n8n node packages and parsing their metadata.
Key Metrics:
- Package loading time (< 100ms target)
- Individual node file loading (< 5ms target)
- Package.json parsing (< 1ms target)
2. Database Query Performance
Measures database operation performance including queries, inserts, and updates.
Key Metrics:
- Node retrieval by type (< 5ms target)
- Search operations (< 50ms target)
- Bulk operations (< 100ms target)
3. Search Operations
Tests various search modes and their performance characteristics.
Key Metrics:
- Simple word search (< 10ms target)
- Multi-word OR search (< 20ms target)
- Fuzzy search (< 50ms target)
4. Validation Performance
Measures configuration and workflow validation speed.
Key Metrics:
- Simple config validation (< 1ms target)
- Complex config validation (< 10ms target)
- Workflow validation (< 50ms target)
5. MCP Tool Execution
Tests the overhead of MCP tool execution.
Key Metrics:
- Tool invocation overhead (< 5ms target)
- Complex tool operations (< 50ms target)
Performance Targets
| Operation Category | Target | Warning | Critical |
|---|---|---|---|
| Node Loading | < 100ms | > 150ms | > 200ms |
| Database Query | < 5ms | > 10ms | > 20ms |
| Search (simple) | < 10ms | > 20ms | > 50ms |
| Search (complex) | < 50ms | > 100ms | > 200ms |
| Validation | < 10ms | > 20ms | > 50ms |
| MCP Tools | < 50ms | > 100ms | > 200ms |
Optimization Guidelines
Current Optimizations
- In-memory caching: Frequently accessed nodes are cached
- Indexed database: Key fields are indexed for fast lookups
- Lazy loading: Large properties are loaded on demand
- Batch operations: Multiple operations are batched when possible
Future Optimizations
- FTS5 Search: Implement SQLite FTS5 for faster full-text search
- Connection pooling: Reuse database connections
- Query optimization: Analyze and optimize slow queries
- Parallel loading: Load multiple packages concurrently
Benchmark Implementation
Writing New Benchmarks
import { bench, describe } from 'vitest';
describe('My Performance Suite', () => {
bench('operation name', async () => {
// Code to benchmark
}, {
iterations: 100,
warmupIterations: 10,
warmupTime: 500,
time: 3000
});
});
Best Practices
- Isolate operations: Benchmark specific operations, not entire workflows
- Use realistic data: Load actual n8n nodes for accurate measurements
- Include warmup: Allow JIT compilation to stabilize
- Consider memory: Monitor memory usage for memory-intensive operations
- Statistical significance: Run enough iterations for reliable results
Interpreting Results
Key Metrics
- hz: Operations per second (higher is better)
- mean: Average time per operation (lower is better)
- p99: 99th percentile (worst-case performance)
- rme: Relative margin of error (lower is more reliable)
Performance Regression Detection
A performance regression is flagged when:
- Operation time increases by >10% from baseline
- Multiple related operations show degradation
- P99 latency exceeds critical thresholds
Analyzing Trends
- Gradual degradation: Often indicates growing technical debt
- Sudden spikes: Usually from specific code changes
- Seasonal patterns: May indicate cache effectiveness
- Outliers: Check p99 vs mean for consistency
Troubleshooting
Common Issues
- Inconsistent results: Increase warmup iterations
- High variance: Check for background processes
- Memory issues: Reduce iteration count
- CI failures: Verify runner resources
Performance Debugging
- Use
--reporter=verbosefor detailed output - Profile with
node --inspectfor bottlenecks - Check database query plans
- Monitor memory allocation patterns
Contributing
When submitting performance improvements:
- Run benchmarks before and after changes
- Include benchmark results in PR description
- Explain optimization approach
- Consider trade-offs (memory vs speed)
- Add new benchmarks for new features