Learn Aria2 - Performance & Optimization

#Introduction

In episode 16 you controlled the daemon through a dashboard and browser extensions — every road into aria2 is now open. The next question is no longer how to control it, but how to make it as fast as possible without breaking anything else. Episode 17 covers performance tuning: choosing the right numbers for parallel connections and chunk size, limiting speed to be a good neighbor, and managing the daemon's light resource usage.

An important point before we start: speed isn't about raising every number to its maximum. It's about choosing the right numbers for your network and server — and understanding why.

#The Two Speed Screws: `-x` and `-s`

The two most misunderstood options are the pair -x and -s:

-x (--max-connection-per-server) — how many parallel connections open to one server. Default 1, maximum 16.
-s (--split) — into how many chunks the file is split. Default 5.

Imagine a cake that must be moved. -s decides how many slices the cake has; -x determines how many plates are used to carry them simultaneously. The total you can move at once is the number of slices that actually have a plate — which is why the two work as a pair, not independently.

#Calculating the Right Numbers

The ideal numbers depend on your network's and server's character, not on how boldly you push the sliders:

Fast, stable network, large files — exploit the bandwidth: -x 16 -s 16 makes a real difference on gigabyte-sized files.
Slow or unstable network (mobile, long distance) — many connections just add handshake overhead and failures; -x 2 to -x 4 is wiser than 16.
Small files — raising -s is pointless if chunks never form (see --min-split-size).

fast-download.sh

aria2c -x 16 -s 16 -k 1M https://cdn.example.com/iso-mini.iso

The highway analogy: the width of the server's and network's road determines how many lanes are useful. Adding lanes to an already-jammed road only lengthens the queue — that's why raising -x from 8 to 16 sometimes changes nothing when the bottleneck is the server or ISP (remember the DNS discussion in episode 12).

#`--min-split-size`: When Chunks Form

aria2 doesn't split files smaller than this threshold. The default 20M means a 50MB file splits into at most five chunks — so setting -s 16 on a 50MB file doesn't produce 16 connections. To force more chunks on medium-sized files, lower the threshold:

small-split.sh

aria2c -x 8 -s 8 -k 1M https://cdn.example.com/distro-mini.iso

--min-split-size=1M lets a 50MB file split into up to 50 chunks — and with -x 8, eight chunks can be downloaded at once. The rule of thumb: -k must be small enough that the chunks you want actually form, but not so small that overhead dominates.

#`--max-download-limit`: Being a Good Neighbor

A greedy download that eats all the bandwidth is an unwelcome neighbor. The same home connection is usually shared with video meetings, games, or other people's work. Two options curb that appetite:

--max-download-limit=5M — the speed limit per download.
--max-overall-download-limit=20M — the total limit across all the daemon's downloads.

speed-limit.sh

aria2c --max-overall-download-limit=20M \
  --max-download-limit=5M \
  -j 8 https://cdn.example.com/repo/

--max-overall-download-limit=20M guarantees the daemon never seizes the entire bandwidth, no matter how many downloads there are. The per-download limit keeps one giant download from monopolizing the share that should be split among others. This isn't a sacrifice — it's network etiquette that keeps you on good terms with people and servers alike.

#Many Downloads at Once: `-j`

-j (--max-concurrent-downloads) sets how many downloads run simultaneously, default 5. The interesting part: the number of downloads in the queue is unlimited — aria2 runs the top five, the rest wait their turn. Through RPC (episode 15), queues of hundreds of downloads are routine; the daemon handles the rotation, and -j keeps it from being overwhelmed.

#Light on Resources

aria2 is one of the most frugal downloaders around: about 4-9 MiB RAM per process, even while pulling many connections. Imagine the difference from opening dozens of browser tabs — each eating hundreds of megabytes. The practical consequence: a download daemon can be left running for hours or even days, with a long queue, without disturbing other work on the same machine. That's what makes aria2 ideal as a background service (we'll build the production setup in a later episode).

#`--file-allocation`: Fighting Fragmentation

How a file is prepared on disk affects long-term disk health. aria2 offers several methods:

prealloc (default) — reserves the file's entire space up front, before the download starts.
falloc — reserves space instantly on modern filesystems (ext4, XFS).
trunc — creates a sparse file; saves space, but fragments more.
none — reserves nothing; fastest to start, but the file is laid out piece by piece.

file-allocation.sh

aria2c --file-allocation=prealloc -x 8 -s 8 https://cdn.example.com/big.tar.xz

The restaurant analogy: prealloc reserves the whole table in advance, none reserves chairs one at a time while eating. A table reserved up front lets everyone sit neatly; chairs reserved one by one scatter the guests randomly — just like a file split across many disk sectors.

Tip

On modern filesystems like ext4 and XFS, --file-allocation=falloc gives nearly instant allocation speed while reducing fragmentation — the best combination for large files. If the filesystem doesn't support it, prealloc remains a safe choice.

#One Configuration for Everything

All the numbers discussed should live in one file, not be rewritten on every command line. An example aria2.conf for high-speed downloads:

aria2-fast.conf

max-concurrent-downloads=8
max-connection-per-server=16
split=16
min-split-size=1M
file-allocation=prealloc
max-overall-download-limit=0

With this config file (invoked via -c or placed at the default location), every invocation uses the same tuning — consistent, easy to change, and easy to review. The most valuable optimization isn't the highest number; it's the number that's documented and consistent.

#Closing

Episode 17 tuned aria2's engine: understanding the -x and -s pair as two screws that work together, lowering --min-split-size so chunks form, limiting speed with --max-download-limit and --max-overall-download-limit, setting -j for parallel downloads, leveraging the light daemon (4-9 MiB RAM), and choosing --file-allocation to fight fragmentation.

The key thing to remember: speed isn't the maximum number — it's the right number for the context. Screws turned blindly can damage a healthy engine; screws that are understood produce a consistent one.

In the next episode, episode 18, we stop turning screws manually and hand the work to scripts: scripting & automation — automating downloads, queues, and post-download actions with reliable scripts. See you then!