Module Execution Time Calculator
Estimate execution time for a specific Ansible module across a batch of hosts, using module-specific speed profiles.
Inputs
Module being executed — different modules have very different per-host cost profiles.
Number of hosts the task targets.
Concurrency limit.
Optional — set above 0 to override the module's default per-host time with a measured value.
Total Execution Time
0.15min
Per-Host Time for This Module
1.80seconds
Batches
5batches
Speedup from Parallelism
20.0×
Step by step
Per-host time for this module
copy (slow, checksum + transfer)
= 1.80s/host
Batches: ceil(hosts / forks)
ceil(100 / 20)
= 5 batches
Total time: batches × seconds/host
5 × 1.80s
= 9.00s (0.15 min)
Speedup vs. fully sequential
180.0 / 9.0
= 20.0×
How it works
Different Ansible modules have very different per-host cost profiles: `command`/`shell` execute directly and return quickly, `copy` and `template` must checksum and transfer file content, `apt`/`yum` cost depends heavily on whether the package cache is warm, and `git` involves a full network clone or fetch. This calculator applies representative per-host timings for common modules, then batches them by forks the same way any other task is batched.
Formula
total_module_time_sec = invocations × avg_module_duration_sec
- invocations
- Total module invocations across all hosts
- avg_module_duration_sec
- Average time per module execution (seconds)
Frequently Asked Questions
Why is `apt`/`yum` marked as 'variable'?
Package manager modules can be nearly instant if the desired package is already installed (a no-op check), or take many seconds if it needs to update the cache and download/install — the default value here assumes a mixed, realistic average.
How accurate are these default per-host times?
They're representative starting points, not measurements of your specific environment — network latency, file sizes, package mirror speed and target host performance all shift the real numbers, so use the override field with your own measured timings when possible.
Why is `git` the slowest profile listed?
Unlike most modules that operate on local state or make a single API call, `git` typically has to negotiate a network transfer proportional to repository size, which dominates its execution time compared to simpler state-check modules.
Does this account for `async` tasks?
No — this models synchronous execution. Tasks run with `async` and `poll: 0` return immediately and don't block the batch, which would need a different model (fire-and-forget plus a separate job-status check).