Per-request or timed rotation: which to choose

Per-request rotation

Every call leaves from a new address. This suits independent requests: product listings by direct URL, cards by known identifier, position checks across a query set. Load is spread across the pool as widely as possible, and each individual address carries the fewest requests.

Timed rotation

The address is held for a set interval, and every request inside it leaves from the same IP. You need this wherever the server links steps together through a cookie or session token.

• Sign-in: the session is issued to one address, and the next request arrives from another — the session is invalid.
• Pagination inside results: page two is often bound to the same session as page one.
• Multi-step forms and carts, where state accumulates between requests.
• Platforms that issue a cookie first and only then serve content.

Choosing the interval

The interval has to cover your longest chain of linked requests with room to spare. If sign-in plus collection takes ninety seconds, set no less than three minutes: too short an interval breaks the chain midway, while too long merely reduces address variety.

A practical rule is to start at twice your longest chain and shorten it if data comes back clean. Increasing the interval after failures costs more, because some of the data has to be collected again.

Mixed workloads

If one project contains both — authenticated collection and bulk checks of public pages — it is usually better to split them across two plans with different modes than to compromise on one. A 50-thread plan costs 650 ₽, and two narrow ones almost always beat a single universal setup.

How to tell a task is session-based

The tell is almost always the same: a single request works correctly, but a sequence of two or three steps breaks — and at a different step each time. That is the chain coming apart: each step leaves from a new address, and the server sees unrelated requests from different clients.

You can check without writing code. Run the sequence by hand through one static address: if it completes that way, rotation is the cause, not the site and not your response parsing. If it fails by hand too, the problem is elsewhere and changing rotation mode will not help.

• Sign-in issues a cookie and the next request arrives from a different IP — the session is invalid.
• The second results page is bound to the same session as the first.
• A cart or multi-step form accumulates state between requests.
• The platform issues a token first and only then serves content.

Choosing the interval without redoing the work

The interval must cover your longest chain with room to spare. A convenient way to size it: time a full pass over one object from first request to last, then double it. Too short an interval breaks the chain midway; too long merely reduces address variety and moves behaviour closer to static.

Raising the interval after failures costs more than allowing headroom up front: some data has to be collected again, and it is not always clear which — a broken chain often returns not an error but an empty or partial response.