Multithreading in BAS: How Many Threads to Run and Why More Is Not Faster

Multithreading is the reason most people pick BAS in the first place: the same script runs as several parallel copies, and work that would take a day finishes in an hour. But thread count is not a “go faster” slider. It is the way you divide a finite resource, and past a certain number your bot gets slower.

What a thread is in BAS

A thread is an independent copy of your script running in parallel with the others. Independent is the operative word: each thread has its own browser, its own profile and fingerprint, its own cookies, its own proxy, and its own variable values.

That is why multithreading in BAS buys more than speed - it buys parallel work across separate accounts. Thread 3 knows nothing about who thread 7 is logged in as.

What a thread does not get

The isolation is not absolute. These stay shared:

• Files on disk - two threads writing to one file will interleave and corrupt each other.
• Resources - one shared queue, and you decide the hand-out rule.
• The database - the built-in storage is one store for all threads.
• External limits - an API quota or a per-IP rate limit does not double because you doubled threads.

Hence the rule: anything shared between threads must be either read-only or protected against races. Twenty threads appending to a single log file is the classic way to end up with shuffled lines.

Sizing the ceiling

Size it by memory, not by feel. One browser thread in BAS takes roughly 150-400 MB of RAM - the spread depends on how heavy the site is: a plain form sits near the bottom, a page full of video and images lands at the top.

The arithmetic is simple:

threads = (free RAM - 2 GB headroom) / 400 MB

On an 8 GB VPS that is about 10-15 browser threads. If you do not need a browser and work through the HTTP client instead, the picture changes completely: per-thread cost drops to megabytes and a hundred threads is unremarkable.

CPU is the second ceiling. Page rendering is CPU-bound, and on weak cores you will hit the processor limit before the memory one.

How to tell you have too many

The symptoms are recognisable:

• Timeouts climb - actions start failing on wait that used to pass.
• The success rate in your statistics drops while total speed does not improve.
• Captchas appear far more often - the site sees one IP producing an unnaturally uniform rhythm.
• The machine starts swapping, and every thread slows at once.

That last one is treacherous because the degradation is not gradual. Below the threshold everything is fine; above it, everything is bad simultaneously.

Finding the working number

Do not guess - measure. The method that works:

1. Run on one thread and time a full iteration.
2. Raise to 5 and time it again - the per-iteration time should stay about the same.
3. Keep doubling until the time of a single iteration starts to rise.
4. Step back one level and take another 20% off. That is your operating point.

The thing you actually care about is not thread count but total throughput. Twenty threads where each iteration takes three times longer perform worse than eight healthy ones.

Handing out resources and proxies

Under multithreading, how you feed data matters more than the thread count itself. If every thread pulls a line from a shared list, make sure a line cannot go to two threads at once - otherwise you process the same account twice and get it wrong both times.

Proxies are the same story. One IP behind twenty threads cancels out all your profile isolation: the site sees twenty “different” browsers from a single address. Multithreading only pays off when distinct addresses sit behind the threads.

When threads will not help

Multithreading speeds up work that is bound by waiting: page loads, network latency, pauses. It does nothing for work bound by the other side - if a site allows 10 requests a minute, thirty threads just get you banned faster than ten would.

Before raising the thread count, look at where the time actually goes. Trimming dead waiting inside an iteration is often the better move: cutting 30% off an iteration buys what a third more threads would, and costs nothing in resources.