openevidence-performance-tuning
Improves latency for OpenEvidence clinical queries through strategic caching and citation batching.
Install
mkdir -p .claude/skills/openevidence-performance-tuning && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4797" && unzip -o skill.zip -d .claude/skills/openevidence-performance-tuning && rm skill.zipInstalls to .claude/skills/openevidence-performance-tuning
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Performance Tuning for OpenEvidence.Key capabilities
- →Cache evidence responses with a 30-minute TTL
- →Cache citation metadata with a 1-hour TTL
- →Batch citation retrieval in groups of 25 with 500ms pauses
- →Enable HTTP keep-alive for persistent API connections
- →Monitor average query latency
- →Set client timeout to 30s for complex multi-condition queries
How it works
The skill implements caching strategies for evidence summaries and citation batching to reduce system load. It optimizes query specificity and request handling for large-scale medical data retrieval.
Inputs & outputs
When to use openevidence-performance-tuning
- →Implement response caching for medical evidence queries
- →Batch citation fetches to reduce API overhead
- →Optimize query performance for clinical AI tools
- →Set TTL intervals for evidence and citation data
About this skill
OpenEvidence Performance Tuning
Overview
OpenEvidence's clinical API handles evidence query response times, citation batch retrieval, and complex multi-condition query optimization. Clinical evidence queries can take 2-5 seconds as the system searches across thousands of medical studies and synthesizes responses. Citation batch retrieval for systematic reviews generates heavy load when fetching 50-200 references per query. Caching evidence responses, batching citation fetches, and optimizing query specificity reduces clinician wait times by 50-70% and keeps complex queries within acceptable latency bounds.
Caching Strategy
const cache = new Map<string, { data: any; expiry: number }>();
const TTL = { evidence: 1_800_000, citations: 3_600_000, queries: 300_000 };
async function cached(key: string, ttlKey: keyof typeof TTL, fn: () => Promise<any>) {
const entry = cache.get(key);
if (entry && entry.expiry > Date.now()) return entry.data;
const data = await fn();
cache.set(key, { data, expiry: Date.now() + TTL[ttlKey] });
return data;
}
// Citations are stable (1hr). Evidence summaries update with new studies (30 min).
Batch Operations
async function fetchCitationsBatch(client: any, citationIds: string[], batchSize = 25) {
const results = [];
for (let i = 0; i < citationIds.length; i += batchSize) {
const batch = citationIds.slice(i, i + batchSize);
const res = await Promise.all(batch.map(id => client.getCitation(id)));
results.push(...res);
if (i + batchSize < citationIds.length) await new Promise(r => setTimeout(r, 500));
}
return results;
}
Connection Pooling
import { Agent } from 'https';
const agent = new Agent({ keepAlive: true, maxSockets: 6, maxFreeSockets: 3, timeout: 30_000 });
// Moderate socket count — evidence queries are sequential, citations parallel
Rate Limit Management
async function withRateLimit(fn: () => Promise<any>): Promise<any> {
try { return await fn(); }
catch (err: any) {
if (err.status === 429) {
const retryMs = parseInt(err.headers?.['retry-after'] || '10') * 1000;
await new Promise(r => setTimeout(r, retryMs));
return fn();
}
throw err;
}
}
Monitoring
const metrics = { queries: 0, citationFetches: 0, cacheHits: 0, avgLatencyMs: 0, errors: 0 };
function track(op: 'query' | 'citation', startMs: number, cached: boolean) {
metrics[op === 'query' ? 'queries' : 'citationFetches']++;
const lat = Date.now() - startMs;
metrics.avgLatencyMs = (metrics.avgLatencyMs * (metrics.queries - 1) + lat) / metrics.queries;
if (cached) metrics.cacheHits++;
}
Performance Checklist
- Cache evidence responses with 30-min TTL (studies update periodically)
- Cache citation metadata with 1-hour TTL (stable once published)
- Batch citation retrieval in groups of 25 with 500ms pauses
- Use specific condition + intervention queries instead of broad searches
- Prefetch commonly queried drug interaction evidence
- Enable HTTP keep-alive for persistent API connections
- Monitor average query latency (target < 3s for simple queries)
- Set client timeout to 30s for complex multi-condition queries
Error Handling
| Issue | Cause | Fix |
|---|---|---|
| Slow evidence query (> 5s) | Broad multi-condition search | Narrow query to specific condition + intervention |
| 429 on citation batch | Too many parallel citation fetches | Batch to 25, add 500ms delay between groups |
| Stale evidence summary | Cache too long for rapidly evolving topic | Reduce TTL for high-churn topics (e.g., COVID) |
| Timeout on complex query | Multi-study synthesis exceeding limit | Increase timeout to 30s, simplify query scope |
| Missing citations | Study not yet indexed | Retry after 24h, check study publication date |
Resources
- OpenEvidence Platform
- OpenEvidence API Docs
Next Steps
See openevidence-reference-architecture.
When not to use it
- →When evidence summaries are stale due to a cache that is too long for rapidly evolving topics
- →When a study is not yet indexed, resulting in missing citations
Limitations
- →Slow evidence queries can occur with broad multi-condition searches
- →Rate limits can be hit with too many parallel citation fetches
- →Complex queries may time out if multi-study synthesis exceeds limits
How it compares
This skill explicitly defines TTLs for evidence and citations, batches citation fetches with pauses, and uses connection pooling, unlike generic performance tuning.
Compared to similar skills
openevidence-performance-tuning side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| openevidence-performance-tuning (this skill) | 1 | 27d | No flags | Intermediate |
| exa-performance-tuning | 3 | 27d | Review | Intermediate |
| perplexity-rate-limits | 0 | 27d | No flags | Intermediate |
| documenso-performance-tuning | 0 | 27d | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
exa-performance-tuning
jeremylongshore
Optimize Exa API performance with caching, batching, and connection pooling. Use when experiencing slow API responses, implementing caching strategies, or optimizing request throughput for Exa integrations. Trigger with phrases like "exa performance", "optimize exa", "exa latency", "exa caching", "exa slow", "exa batch".
perplexity-rate-limits
jeremylongshore
Implement Perplexity rate limiting, backoff, and idempotency patterns. Use when handling rate limit errors, implementing retry logic, or optimizing API request throughput for Perplexity. Trigger with phrases like "perplexity rate limit", "perplexity throttling", "perplexity 429", "perplexity retry", "perplexity backoff".
documenso-performance-tuning
jeremylongshore
Optimize Documenso integration performance with caching, batching, and efficient patterns. Use when improving response times, reducing API calls, or optimizing bulk document operations. Trigger with phrases like "documenso performance", "optimize documenso", "documenso caching", "documenso batch operations".
gamma-performance-tuning
jeremylongshore
Optimize Gamma API performance and reduce latency. Use when experiencing slow response times, optimizing throughput, or improving user experience with Gamma integrations. Trigger with phrases like "gamma performance", "gamma slow", "gamma latency", "gamma optimization", "gamma speed".
juicebox-prod-checklist
jeremylongshore
Execute Juicebox production deployment checklist. Use when preparing for production launch, validating deployment readiness, or performing pre-launch reviews. Trigger with phrases like "juicebox production", "deploy juicebox prod", "juicebox launch checklist", "juicebox go-live".
v3-mcp-optimization
ruvnet
MCP server optimization and transport layer enhancement for claude-flow v3. Implements connection pooling, load balancing, tool registry optimization, and performance monitoring for sub-100ms response times.