Support proxy mode - #304
Open
AdrianAtZyte wants to merge 44 commits into
Open
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #304 +/- ##
==========================================
+ Coverage 97.50% 99.62% +2.12%
==========================================
Files 15 19 +4
Lines 2404 2936 +532
Branches 439 530 +91
==========================================
+ Hits 2344 2925 +581
+ Misses 31 5 -26
+ Partials 29 6 -23
🚀 New features to boost your workflow:
|
…on and original plan
3 tasks
…ng if missing a header
AdrianAtZyte
marked this pull request as ready for review
June 26, 2026 08:05
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I have manually tested the changes, and in a simple books.toscrape.com spider things work both with http and proxy transport very similarly.
Too similarly, in fact. I was hoping for a simple, ~30 requests with 1 concurrency to show a lower wall time with proxy mode, but it was the opposite, although by a small margin.
Opus then run a better benchmark (interleaving http and proxy, 3 runs each, concurrency 8, 211 requests each run) that did show proxy mode to offer ~43% lower wall time and ~46% lower latency. Did not measure network, but it should be a given that proxy mode is better there due to the base64 encoding of non-browser requests.
Caveats:
I have discarded implementing proxy mode support in python-zyte-api. However, it may be worth considering. It would definitely simplify stat handling.
I have kept out of scope compatibility and a migration path from scrapy-zyte-smartproxy. Besides this PR being complex enough as it is, I feel like we should wait for proxy mode here to prove itself for a while, improving it based on user feedback, and only once we feel this is the best way to use proxy mode, make migrating from scrapy-zyte-smartproxy as easy as possible (e.g. make it so that simply uninstalling scrapy-zyte-smartproxy automatically makes scrapy-zyte-api take over, being functionally equivalent, with no mandatory changes [only migration warnings]).