perf: refactor migrate_to_stripe to use asyncio for concurrent Stripe API calls.#374
Open
vincerevu wants to merge 1 commit intostripe:mainfrom
Open
Conversation
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.
What: The script
init_products.pynow usesasyncio.gatherandstripe.*.create_asyncmethods to perform product/price and coupon/promo code creation operations concurrently, rather than sequentially. The results are gathered, and standard output format and local database updating operations are maintained sequentially to ensure stability and compatibility with sqlite.Why: The original implementation performed API calls sequentially in a loop resulting in an N+1 performance bottleneck heavily gated by network latencies. Parallelizing these external calls significantly speeds up migration.
Measured Improvement: I wrote a test benchmark (
benchmark.py) mocking network latencies (0.5s network delay per api call simulating typical conditions) and measured performance across 10 products and 5 coupons. The performance went from ~15s down to ~2s (as expected due to the two parallel execution blocks: 1s max for products/prices, and 1s max for coupons/promos).