Subversion Repositories SmartDukaan

Last modification

• Rev 37448 2026-08-28 12:08:39
• Author: amit

• Log message:

  Daily re-check for all brands; Oppo back to parallel pools
  
  Two changes.
  
  1. Re-check window 4 days (secondary) and 2 days (tertiary) -> 1 day everywhere.
  Daily demand becomes the full universe rather than a fraction of it:
  
  Oppo 4,798 + 4,040 = 8,838/day
  Vivo 9,407 + 675 = 10,082/day (doing 15,345 -- fine)
  Realme 1,973 + 1,081 = 3,054/day
  
  2. Oppo's two pools run in PARALLEL again, reverting the merge in r37447 for that
  brand only. Realme stays merged.
  
  The merge was a straight trade of throughput for memory and oppo could not
  afford it. Measured over 32 minutes and again over an hour the next morning:
  3,555 then 3,456/day against 5,280 before merging. Batch cadence settled at a
  very regular ~15.5 min per cycle, so a 30-imei merged batch takes ~10.5 min =
  ~21s/imei, against the 10.2s it managed unmerged. At 21s the ceiling is
  86400/21 = 4,114/day even with zero idle, so no batch size and no shorter
  fixedDelay could have reached 8,838. Serialising simply costs more per imei
  here than running two browsers does.
  
  Realme keeps the merge: it needs 3,054/day and delivers 2,952 merged, so a
  small size bump covers it without a second browser.
  
  Sizes: oppo 25 per pool (2 jobs in parallel), realme 12+12 merged, vivo 50+10
  unchanged. Vivo has already cleared its entire secondary backlog -- the pool
  reads 0 and both lists come back empty -- which is what the batch of 50 was for.
  
  Cost: oppo goes back to two concurrent drivers, so the fleet is 3 rather than 2,
  roughly +700MB. Acceptable against the ~2GB freed today by reaping orphaned
  browsers and capping retries, but it is the reason realme was left merged.
  
  Sizes are a starting point, not a final answer: oppo's per-imei time differs
  markedly between merged and parallel modes, so re-measure before tuning further.