home / skills / jeremylongshore / claude-code-plugins-plus-skills / posthog-performance-tuning

This skill helps optimize PostHog API performance by implementing caching, batching, and connection pooling for faster, more reliable integrations.

npx playbooks add skill jeremylongshore/claude-code-plugins-plus-skills --skill posthog-performance-tuning

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
5.0 KB
---
name: posthog-performance-tuning
description: |
  Optimize PostHog API performance with caching, batching, and connection pooling.
  Use when experiencing slow API responses, implementing caching strategies,
  or optimizing request throughput for PostHog integrations.
  Trigger with phrases like "posthog performance", "optimize posthog",
  "posthog latency", "posthog caching", "posthog slow", "posthog batch".
allowed-tools: Read, Write, Edit
version: 1.0.0
license: MIT
author: Jeremy Longshore <[email protected]>
---

# PostHog Performance Tuning

## Overview
Optimize PostHog API performance with caching, batching, and connection pooling.

## Prerequisites
- PostHog SDK installed
- Understanding of async patterns
- Redis or in-memory cache available (optional)
- Performance monitoring in place

## Latency Benchmarks

| Operation | P50 | P95 | P99 |
|-----------|-----|-----|-----|
| Read | 50ms | 150ms | 300ms |
| Write | 100ms | 250ms | 500ms |
| List | 75ms | 200ms | 400ms |

## Caching Strategy

### Response Caching
```typescript
import { LRUCache } from 'lru-cache';

const cache = new LRUCache<string, any>({
  max: 1000,
  ttl: 60000, // 1 minute
  updateAgeOnGet: true,
});

async function cachedPostHogRequest<T>(
  key: string,
  fetcher: () => Promise<T>,
  ttl?: number
): Promise<T> {
  const cached = cache.get(key);
  if (cached) return cached as T;

  const result = await fetcher();
  cache.set(key, result, { ttl });
  return result;
}
```

### Redis Caching (Distributed)
```typescript
import Redis from 'ioredis';

const redis = new Redis(process.env.REDIS_URL);

async function cachedWithRedis<T>(
  key: string,
  fetcher: () => Promise<T>,
  ttlSeconds = 60
): Promise<T> {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const result = await fetcher();
  await redis.setex(key, ttlSeconds, JSON.stringify(result));
  return result;
}
```

## Request Batching

```typescript
import DataLoader from 'dataloader';

const posthogLoader = new DataLoader<string, any>(
  async (ids) => {
    // Batch fetch from PostHog
    const results = await posthogClient.batchGet(ids);
    return ids.map(id => results.find(r => r.id === id) || null);
  },
  {
    maxBatchSize: 100,
    batchScheduleFn: callback => setTimeout(callback, 10),
  }
);

// Usage - automatically batched
const [item1, item2, item3] = await Promise.all([
  posthogLoader.load('id-1'),
  posthogLoader.load('id-2'),
  posthogLoader.load('id-3'),
]);
```

## Connection Optimization

```typescript
import { Agent } from 'https';

// Keep-alive connection pooling
const agent = new Agent({
  keepAlive: true,
  maxSockets: 10,
  maxFreeSockets: 5,
  timeout: 30000,
});

const client = new PostHogClient({
  apiKey: process.env.POSTHOG_API_KEY!,
  httpAgent: agent,
});
```

## Pagination Optimization

```typescript
async function* paginatedPostHogList<T>(
  fetcher: (cursor?: string) => Promise<{ data: T[]; nextCursor?: string }>
): AsyncGenerator<T> {
  let cursor: string | undefined;

  do {
    const { data, nextCursor } = await fetcher(cursor);
    for (const item of data) {
      yield item;
    }
    cursor = nextCursor;
  } while (cursor);
}

// Usage
for await (const item of paginatedPostHogList(cursor =>
  posthogClient.list({ cursor, limit: 100 })
)) {
  await process(item);
}
```

## Performance Monitoring

```typescript
async function measuredPostHogCall<T>(
  operation: string,
  fn: () => Promise<T>
): Promise<T> {
  const start = performance.now();
  try {
    const result = await fn();
    const duration = performance.now() - start;
    console.log({ operation, duration, status: 'success' });
    return result;
  } catch (error) {
    const duration = performance.now() - start;
    console.error({ operation, duration, status: 'error', error });
    throw error;
  }
}
```

## Instructions

### Step 1: Establish Baseline
Measure current latency for critical PostHog operations.

### Step 2: Implement Caching
Add response caching for frequently accessed data.

### Step 3: Enable Batching
Use DataLoader or similar for automatic request batching.

### Step 4: Optimize Connections
Configure connection pooling with keep-alive.

## Output
- Reduced API latency
- Caching layer implemented
- Request batching enabled
- Connection pooling configured

## Error Handling
| Issue | Cause | Solution |
|-------|-------|----------|
| Cache miss storm | TTL expired | Use stale-while-revalidate |
| Batch timeout | Too many items | Reduce batch size |
| Connection exhausted | No pooling | Configure max sockets |
| Memory pressure | Cache too large | Set max cache entries |

## Examples

### Quick Performance Wrapper
```typescript
const withPerformance = <T>(name: string, fn: () => Promise<T>) =>
  measuredPostHogCall(name, () =>
    cachedPostHogRequest(`cache:${name}`, fn)
  );
```

## Resources
- [PostHog Performance Guide](https://docs.posthog.com/performance)
- [DataLoader Documentation](https://github.com/graphql/dataloader)
- [LRU Cache Documentation](https://github.com/isaacs/node-lru-cache)

## Next Steps
For cost optimization, see `posthog-cost-tuning`.

Overview

This skill helps you optimize PostHog API performance using caching, request batching, and connection pooling. It provides practical patterns and code-guided strategies to reduce latency, increase throughput, and stabilize integrations. Use it to quickly add caching layers, batching logic, and tuned HTTP agents for PostHog clients.

How this skill works

The skill inspects common PostHog interaction patterns and applies three core techniques: response caching (LRU or Redis) to avoid repeated reads, request batching (DataLoader-style) to combine many small calls, and connection pooling with keep-alive to reduce TCP/SSL overhead. It also includes pagination generators and simple timing wrappers to measure baseline and post-change latency.

When to use it

  • When API calls to PostHog show elevated latency or high P95/P99 times
  • When your integration issues many small requests that could be batched
  • When you need a distributed cache for multiple instances (Redis)
  • When connection churn or socket exhaustion affects throughput
  • When you want measurable baseline and post-optimization telemetry

Best practices

  • Measure current latency and error rates before changes to establish a baseline
  • Cache idempotent or read-mostly responses and pick conservative TTLs with stale-while-revalidate if needed
  • Batch logically related requests and cap max batch sizes to avoid timeout spikes
  • Use keep-alive agents and set sensible maxSockets and timeouts to prevent connection exhaustion
  • Monitor cache hit rate, batch sizes, and connection pool usage after deployment

Example use cases

  • Add an in-process LRU cache for frequently requested records to lower read latency
  • Switch to Redis for caching across multiple worker instances to share cache state
  • Wrap multiple fetches in a DataLoader to reduce request count and smooth traffic spikes
  • Configure an HTTPS agent with keep-alive and limited maxSockets to improve throughput
  • Implement an async pagination generator to stream large result sets without loading all data into memory

FAQ

How do I choose between in-memory LRU and Redis caching?

Use in-memory LRU for single-process speed and low operational overhead; choose Redis when you run multiple instances and need a shared, persistent cache.

What batch size should I use?

Start with conservative values (e.g., 50–100) and tune based on latency and error rates; reduce batch size if you see increased timeouts or backend pressure.

How can I avoid cache stampedes?

Implement stale-while-revalidate, randomized TTL jitter, or singleflight/coalescing so only one request refreshes a stale cache entry.