Quick answer: MachineryTrader Equipment Scraper ships with defaultMemoryMbytes: 512 and turns one keyword search into 150 structured heavy-equipment rows in about 14 seconds for $0.007729 settled — call it $0.05 per 1,000 rows of platform cost. 84% of that ($0.006502) is residential-proxy transfer, not compute. And yet our own QA harness had been certifying this Actor at 4096 MB — 8x the memory a customer actually gets — because it was reading a config key that doesn't exist anywhere in our fleet.
| Memory read | What it proves | |
|---|---|---|
| Our QA harness's certification run | 4096 MB (fallback constant) | An over-provisioned run passed |
| A customer's actual run | 512 MB (the shipped default) | Never once tested at this size |
Why did a passing QA run prove nothing about the Actor customers actually get?
The harness was reading defaultRunOptions.memoryMbytes to decide how much RAM to hand a certification run. That key is absent from all 264 Actor manifests in this fleet — every manifest sets memory as a top-level defaultMemoryMbytes instead. So the lookup silently fell back to a hardcoded 4096 MB constant on every single Actor it ever certified, this one included. The certification ran generously provisioned, passed cleanly, and told us nothing about the 512 MB container a real customer's run actually boots into.
A test harness that over-provisions fails silently by construction — it only ever makes things pass.
That's the trap with over-provisioning as a default: an under-provisioned harness at least has a chance to fail and get noticed. An over-provisioned one can't fail on memory at all, so nothing about the mismatch ever surfaces on its own.
Where does the actual cost go, if it isn't the CPU?
$0.007729 settled for 150 rows breaks down almost entirely into proxy egress — $0.006502 of it, or 84% — with compute making up the rest. At $0.05 per 1,000 rows of total cost, the number worth watching on this Actor isn't runtime or memory footprint; it's the residential-transfer line. That's also the number that tracks demand for the target's own bot-check, not our code.
Why does this default to a residential exit pinned to the US?
Because we measured the alternative. Same build, same query (keywords=excavator), same hour: a bare, groupless proxy config resolves to a shared datacenter pool and cleared the target's edge check on only 4 of 8 runs (50%). Switching the default to a residential exit pinned to country=US cleared 8 of 8 (100%), every run landing real, US-located rows with billing confirming genuine residential transfer on each one. The fingerprint-rotation layer underneath (rotating Chrome/Firefox/Safari TLS profiles) was unchanged across both cells — this was a proxy-tier defect, not a fingerprint one, and it's why the country pin isn't optional: a geo-random residential exit on a US-only marketplace would return a plausible wrong-region 200, not a visible error.
What do you actually get back?
One row per listing card: title, manufacturer, category, price (or null for "Call for Price"), meter hours, model year, location, seller, phone, and the listing URL — paginated automatically up to whatever cap you set, with fault isolation so one bad card doesn't sink the run.
MachineryTrader Equipment Scraper walks MachineryTrader.com's search-results pages by keyword and/or manufacturer and returns clean, typed rows for every listing it finds — no public API to lean on, so this is the only wire in. Pricing is Pay-Per-Event: a $0.20 start fee plus $0.004 per listing row, so 1,000 results run about $4.20. Apify gives every new account free trial credit, no card required.
👉 https://apify.com/DevilScrapes/machinerytrader-equipment-scraper
Captchas are our cardio; memory math is apparently our cheat day. 😈
Top comments (0)