One Proxy Project Never Starts? Test Queue Isolation Before Adding Capacity

Two approved projects share proxy workers. Project A keeps completing work, while B waits and has not yet sent a request. An account-wide success rate can hide this problem. Before buying more proxy capacity or rotating exits, determine whether B is waiting inside your own dispatcher.

This guide tests project isolation in a small owned staging workload. It does not measure provider capacity or promise an SLA. The goal is to make local admission, dispatch and completion visible for each project, then verify that a slow project cannot consume every locally protected execution slot.

1. Give waiting and execution different timestamps

Assign a stable project ID, logical job ID and unique attempt ID before admission. Record enqueue, dispatch eligibility, execution start and completion using an appropriate monotonic clock within one process. Do not subtract unrelated machine clocks without a documented synchronization method.

Report queue wait separately from execution time. If the HTTP library has its own connection-acquisition queue, measure or label that boundary too: “worker started” does not always mean bytes left the client. A task with no dispatch event should not be classified as a slow proxy response.

2. Define the isolation policy and its limits

Document the global in-flight cap, each project's active limit, finite queue size, maximum queue age and overflow action. Use currently approved client, provider and destination limits as hard constraints. Per-project budgets must not multiply into a total exceeding those constraints.

Choose whether idle reserved capacity may be borrowed and how new arrivals regain eligibility. Do not promise instant preemption of an already running request. State which project gets the next eligible slot and how expired or cancelled queued jobs are removed. A permanently full queue needs a visible reject, defer or expire outcome, not unlimited memory growth.

The 98IP dynamic residential IP product page identifies the route product for authorized jobs; verify actual account options and limits before testing. The API configuration documentation helps check documented access setup. Neither page establishes that your application has project-aware scheduling or that separate credentials provide independent provider capacity.

3. Build a two-project deterministic fixture

1. Create two synthetic projects with known harmless responses on an endpoint you own or are authorized to test at the agreed load.
2. Make A deliberately slow through the owned fixture or a local worker test adapter. Keep B's work short and its expected content known.
3. Use a small fixed arrival sequence and a fixed total budget. Record all queued, started, rejected, expired and completed jobs by project.
4. Define the expected dispatch order or eligibility rule before running. Do not derive fairness from aggregate throughput after the fact.

An illustrative local configuration might reserve one execution slot for each of two projects under a global cap of two. If A occupies its own slot, an eligible B task should still be able to use B's free slot, subject to all other declared gates. These numbers are a synthetic scheduler example, not a recommended proxy limit or a measured performance result.

4. Inspect the shared resources that remain

Separate application queues are insufficient if both lanes still wait behind one exhausted HTTP pool, semaphore, event loop or result writer. Trace B from eligibility to actual request start and then to validated output. A hidden global resource can reintroduce starvation after the dispatcher appears fair.

Decide which shared resources need enforceable partitions or bounded access, using controls actually supported by the runtime. Account for their overhead. Logical isolation cannot guarantee independent bandwidth, exits or provider quotas. If a downstream bottleneck blocks both projects, report that boundary instead of claiming project isolation from queue names alone.

5. Charge retries and cleanup to the same project

A retry retains the logical project's identity and consumes its approved attempt budget. Delayed retries must re-enter through the same eligibility policy rather than jumping ahead as untracked new work. A job waiting for its retry time should not hold an active execution slot unless that behavior is explicitly intended and tested.

Release a slot when the owned operation's actual lifecycle permits it, not merely when the user interface stops waiting. Conversely, remove a queued job that expires before dispatch so it cannot later run unexpectedly. If a cancelled operation continues underneath, record the outstanding work and do not allocate fictional free capacity.

6. Rehearse isolation and recovery

Propose four staging cases: A remains slow while B arrives; A's queue reaches its bound; an A attempt fails and schedules a retry; and an A queued job expires before a slot opens. Verify B's dispatch eligibility, the global cap, per-project outcomes and slot cleanup in every case. These are proposed exercises, not executed measurements.

Then allow A to recover. Confirm that expired jobs stay expired, deferred work follows the declared order and resumed retries do not create a burst above the total budget. If borrowing is enabled, test a B arrival while A occupies borrowed capacity and report the actual waiting behavior rather than claiming immediate reservation recovery.

Keep a ledger of arrival order, project, job, attempt, eligibility, queue age, active counts, terminal outcome and content check. For a small fixture, inspect the full sequence; averages can hide one project that never starts. Do not call the test passed because total completions rose.

FAQ and acceptance checklist

Will more IPs cure a task that never dispatches? Not by themselves. Establish where it waits before changing network resources.

Is equal completion count the definition of fairness? No. Different job durations and approved weights can produce different counts. Verify the documented eligibility and protection rules, plus each project's required service objectives.

• Queue wait, HTTP pool wait and execution are distinguishable.
• Every project has bounded admission and explicit overflow behavior.
• Project limits stay under the shared global and authorized destination caps.
• Retries, expiration and cleanup preserve project ownership.
• Slow-project and recovery cases preserve the promised dispatch protection.
• Remaining shared bottlenecks and untested cases are disclosed.

Use only approved targets and small synthetic workloads. Stop at the agreed request and resource limits, redact secrets, and avoid production traffic floods. Isolation is a client-side control to validate, not permission to bypass destination throttling or an assurance of provider-level independence.