perf: optimization for homepage referral activity tracking#991
perf: optimization for homepage referral activity tracking#991ankushchk wants to merge 3 commits intoalphaonelabs:mainfrom
Conversation
👀 Peer Review RequiredHi @ankushchk! This pull request does not yet have a peer review. Before this PR can be merged, please request a review from one of your peers:
Thank you for contributing! 🎉 |
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughQuery performance optimization in the homepage view that consolidates N separate click-count queries into a single batched database query, then computes click totals in memory rather than issuing individual LIKE-scans per referral code. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@web/views.py`:
- Around line 294-309: The current substring matching of referral codes
(variables all_codes, combined_q, matching_paths, click_counts) misattributes
clicks for codes that share prefixes and includes empty codes; fix by first
filtering out empty/None codes from all_codes, then build exact-match conditions
using path boundaries (e.g., require "/ref/{code}/" or "?ref={code}" followed by
end-of-string or "&") or use a regex-based Q (path__regex) that enforces
whole-code boundaries so "ABC" won't match "ABC1"; remove the fragile
first-match break and instead rely on the precise match to count each path to
the correct code when populating click_counts.
What does this PR do?
The previous implementation of the index view ran a separate database query for every single top referrer to calculate their click counts. This is a classic N+1 query problem.
Furthermore, because these queries used
path__contains(a SQLLIKEscan) on theWebRequesttable which is not indexed for text containment and grows rapidly, the homepage load time would degrade exponentially as the site traffic increased.Fix:
Qexpression.Checklist
Summary by CodeRabbit