---
title: Performance tuning
description: Tune threads, sensitivity flags, and database caching to speed up a BLAST run.
---

Speed up a [BLAST](/docs/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.

> **Where these commands run**

> You cannot open a shell on the platform yourself. The commands on this page are BLAST+ command lines: ask Ivy in chat to run them in the chat's [code workspace](/docs/sandbox), which ships BLAST+, or run them on your own machine. For a hosted search with no commands, see the [BLAST quickstart](/docs/blast/quickstart).

## CPU and threads

```bash
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.