How many threads to set in a scraper for your proxy plan: A-Parser, Key Collector, ZennoPoster, Netpeak

Threads add up; they do not come from one setting

A-Parser's documentation states it outright: the total thread count in the parser equals the sum of running tasks and enabled proxy checkers that are checking proxies. Its own worked example is 20 + 100 + 100 + 15 = 235 threads, and the same page says that sum has to fit your proxy tariff. Our billing model, described by a third-party vendor.

The practical consequence: look not at the active task's setting but at the sum of everything running at once.

A-Parser: the proxy checker spends your plan quietly

The proxy checker's “Check threads” parameter defaults to 15. That is fifteen concurrent connections leaving your paid plan for as long as the checker is enabled — even while the main task is doing nothing. On a 50-thread plan that is nearly a third.

Key Collector: the ceiling is your account count

The Yandex.Direct parsing settings say the number given is the total thread count, not a per-account one, and that you cannot set more threads than the number of Yandex accounts configured and activated. So the limit here is not the proxy plan: buying more threads will not buy speed until you add accounts.

Separately, the docs recommend not using more than one thread per IP address. That is written for lists of individual addresses, where an address is bound to a thread; with a rotating gateway the addresses are supplied on our side, but the recommendation is still worth keeping as a guide to how aggressive to be.

KeyAssort and licence ceilings

KeyAssort's manual is explicit: the number of simultaneous threads cannot exceed the number of added proxies plus the main IP. With one gateway line that is two threads, and the plan has nothing to do with it. Netpeak Checker's limit is in the licence: 10 threads on Freemium and Lite against 200 on Pro and above, with threads on the general settings tab and proxies on a separate list tab. ZennoPoster sets threads per project via “Максимум потоков”, and the free LITE edition is capped at one thread.

The inverse case: the plan is already oversized

Not every program wants many. Screaming Frog crawls at 5 threads by default, changed under Configuration → Speed. Datacol's FAQ calls 5–10 threads optimal. For work like that the entry 50-thread plan is oversized several times over, and the honest conclusion is that there is nothing to upgrade: the bottleneck is not the address count.

The easiest way to learn how many threads a job really creates is to measure before buying: run it on a short sample and see how many concurrent connections the process holds. That beats guessing from the number in a setting — especially where helper modules spend threads of their own.

Turning all of this into a plan

• Add up the threads of every task that runs at the same time, then add the helper modules — proxy checkers first of all.
• Compare the sum against the ceilings the program or its licence imposes: if the limit is there, a proxy plan will not change your speed.
• Take a plan no smaller than that sum. If the plan has fewer threads, some connections will wait for a free slot — the program will not crash, it will just run slower than configured.
• Start at 50 and raise it when you hit the ceiling: there is no reason to pay for threads you do not use.

# What to add up before choosing a plan
Task “SERP collection”          40 threads
Task “Card check”               30 threads
Proxy checker (Check threads)   15 threads
                               ------------
Concurrent                      85 threads  -> a 100 plan, not a 50

If the sum exceeds the plan, the program will not tell you clearly: some connections simply wait for a free slot and the task runs slower than it is configured to. From the outside that reads as “the proxies are slow”, when what you hit was your own setting.

What is billed is concurrency, not the number of addresses: how many IPs the pool puts out in that time does not matter, and traffic on rotating plans is not metered.