Performance Monitoring

Key Performance Metrics

Response Time

  • Tool Execution Time: Time to complete MCP tool calls
  • HTTP Request Time: ActivityPub/WebFinger request latency
  • Cache Hit/Miss Time: Cache lookup performance
  • End-to-End Latency: Total user request to response time

Resource Usage

  • Memory Usage: Heap size and garbage collection
  • CPU Usage: Processing load and utilization
  • Network I/O: Bandwidth and connection usage
  • Cache Size: Memory used by caching layers

Throughput

  • Requests per Second: Tool call frequency
  • Concurrent Connections: Simultaneous operations
  • Cache Hit Rate: Percentage of cache hits
  • Error Rate: Failed requests percentage

Monitoring Setup

Built-in Monitoring

The server exposes a liveness endpoint and an MCP resource for server metadata:

# HTTP liveness probe (no auth required)
curl http://localhost:3000/health

# Access server metadata via MCP resource
activitypub://server-info

Available Information:

/health is a liveness-only probe: it returns exactly \{ status: "ok" \} and performs no outbound connectivity or readiness check.

The activitypub://server-info MCP resource returns server metadata only — no request timing, memory/GC, cache, or error metrics. Its fields are:

  • name, version, and description
  • capabilities (counts of resources, tools, and prompts)
  • features (audit logging, instance blocklist, content warnings, trending content, thread support)
  • configuration (rate limit settings and log level)
  • uptime and timestamp

External Monitoring Tools

Node.js Profiling

# CPU profiling
node --prof server.js

# Memory profiling
node --inspect server.js

# Heap snapshots
node --inspect --inspect-brk server.js

Process Monitoring

# System resource usage
top -p $(pgrep -f activitypub-mcp)

# Detailed process info
ps aux | grep activitypub-mcp

# Memory details
cat /proc/$(pgrep -f activitypub-mcp)/status

Performance Analysis

Response Time Analysis

1. Baseline Measurement

# Measure tool execution time
time discover-actor @mastodon@mastodon.social

# Benchmark multiple operations
for i in {1..10}; do
  time get-instance-info mastodon.social
done

2. Bottleneck Identification

  • Network Latency: Test with different instances
  • Cache Performance: Compare cached vs uncached requests
  • Processing Time: Profile JSON parsing and data transformation
  • Concurrency Issues: Test with multiple simultaneous requests

Memory Analysis

Memory Profiling

# Generate heap snapshot
kill -USR2 $(pgrep -f activitypub-mcp)

# Analyze with Chrome DevTools
node --inspect server.js
# Open chrome://inspect in Chrome

Memory Leak Detection

  • Monitor Growth: Track memory usage over time
  • Cache Limits: Verify cache size limits are enforced
  • Event Listeners: Check for unremoved listeners
  • Circular References: Look for objects preventing GC

Cache Performance

Cache Metrics

The activitypub://server-info resource has no .statistics field, and activitypub:// is an MCP resource URI (accessed via the MCP protocol), not an HTTP endpoint that curl can fetch. No cacheHits/cacheMisses are exposed through server-info or /health.

Cache statistics exist only internally (LRUCache.getStats and the WebFinger cache) and are not surfaced to clients.

Optimization Strategies

  • TTL Tuning: Adjust cache expiration times
  • Size Limits: Optimize cache size vs hit rate
  • Eviction Policy: Use LRU for better performance
  • Preloading: Cache frequently accessed data

Optimization Strategies

Network Optimization

  • Connection Pooling: Reuse HTTP connections
  • Request Batching: Combine multiple requests
  • Compression: Enable gzip/brotli compression
  • Timeout Tuning: Optimize request timeouts
  • Retry Logic: Implement exponential backoff

Caching Optimization

  • Multi-level Caching: Memory + disk caching
  • Smart Invalidation: Selective cache clearing
  • Predictive Caching: Pre-fetch likely requests
  • Cache Warming: Populate cache on startup
  • Compression: Compress cached data

Processing Optimization

  • Async Operations: Non-blocking I/O
  • Stream Processing: Process data in chunks
  • Worker Threads: Offload CPU-intensive tasks
  • JSON Streaming: Parse large responses incrementally
  • Memory Pooling: Reuse objects and buffers

Performance Alerts

Threshold Configuration

MetricWarningCriticalAction
Response Time> 5s> 15sCheck network/cache
Memory Usage> 80%> 95%Clear cache/restart
Error Rate> 5%> 15%Check logs/connectivity
Cache Hit Rate< 60%< 40%Tune cache settings

Monitoring Scripts

# Simple performance monitor
#!/bin/bash
# Note: activitypub://server-info is an MCP resource URI accessed via the MCP
# protocol, not an HTTP endpoint — curl cannot fetch it. Time the HTTP liveness
# probe (/health) instead.
while true; do
  MEMORY=$(ps -o pid,vsz,rss,comm -p $(pgrep -f activitypub-mcp))
  RESPONSE_TIME=$(curl -w "%{time_total}" -s -o /dev/null http://localhost:3000/health)

  echo "$(date): Memory: $MEMORY, Response: ${RESPONSE_TIME}s"

  if (( $(echo "$RESPONSE_TIME > 10" | bc -l) )); then
    echo "WARNING: High response time detected"
  fi

  sleep 60
done

Performance Checklist

Daily Monitoring

  • Check server response times
  • Monitor memory usage trends
  • Review error logs
  • Verify cache hit rates
  • Check for memory leaks

Weekly Analysis

  • Analyze performance trends
  • Review slow queries
  • Check cache effectiveness
  • Monitor resource usage patterns
  • Update performance baselines

Monthly Optimization

  • Profile application performance
  • Optimize cache configurations
  • Review and tune timeouts
  • Analyze dependency performance
  • Plan capacity upgrades