Performance tuning

Speed up a BLAST run by tuning threads, sensitivity flags, database caching, and output format. -num_threads most affects wall-clock time — set it to the available vCPUs without oversubscribing, then trade sensitivity for speed via -word_size and -evalue as needed.

CPU and threads

blastn \
  -query inputs/query.fasta \
  -db inputs/db/genomes_v1 \
  -num_threads 8 \
  -out outputs/results.tsv

• Set -num_threads to available vCPUs; avoid oversubscription.
• Prefer fewer threads with higher -word_size if IO is the bottleneck.

Sensitivity vs. speed

• Faster: increase -word_size, raise -evalue, cap -max_target_seqs.
• More sensitive: decrease -word_size, lower -evalue, adjust gap penalties.
• For protein searches, benchmark -matrix choices (e.g., BLOSUM62 vs. BLOSUM45).

Caching databases

• Keep databases on an attached volume, not /tmp.
• Reuse inputs/db/<name>_<version> across runs; avoid rebuilding.
• For repeat queries, warm caches by running a tiny query before the batch.

Output formatting cost

• Tabular -outfmt 6 is fastest; JSON -outfmt 15 is heavier but structured.
• Avoid writing to stdout; direct -out to a file on the attached volume.

Monitor and summarize

• Capture runtime and CPU stats per query; surface slowest queries in SUMMARY.json.
• Keep BLAST version, database checksums, and command-line flags with outputs for reproducibility.