nevzheng commented on PR #13553: URL: https://github.com/apache/gravitino/pull/13553#issuecomment-5880971357
**Container count is real and verified; the speed story is small, inconsistent in direction, and there's a bigger unmerged win upstream of this PR.** Ran the same before/after comparison on two independent machines: a 14-CPU/48GB Mac (already posted to gravitino-enterprise#2289) and a Cloud Workstation matched to `gcp-arc-runners-large` (8vCPU/31GB — this repo's actual CI runner class). | Backend | Mac: Before→After | Speedup | Runner-class: Before→After | Speedup | |---|---|---|---|---| | H2 | 52.5s → 54.6s | 0.96x | 1m27s → 1m25s | 1.02x | | MySQL | 819.6s → 753.5s | 1.09x | 26m25s → 27m53s | 0.95x | | PostgreSQL | 332.2s → 370.0s | 0.90x | 7m10s → 6m59s | 1.03x | | **Total** | 20m13s → 20m49s | **0.97x** | 35m02s → 36m17s | **0.97x** | 0 deadlocks / 0 lock-waits in any run, either machine — correctness is solid. **Two findings worth flagging before this goes further:** 1. **MySQL and PostgreSQL flip direction between machines** (MySQL faster on Mac, slower on the runner-class box; PostgreSQL does the opposite). Only the **total** number is consistent (~3% slower on both machines, independently) — that's the one number I'd trust; the per-backend deltas look like they're within run-to-run noise (n=1 per condition per machine). 2. **Container count is confirmed via logs**: exactly 1 `Started shared MySQL/PostgreSQL test database container` line per backend in the shared-container run, vs the pre-patch design's one container per fork by construction. That part of the claim holds cleanly. **Bigger context**: dug into the stack (`#6505` → `#13518` → `#13530` → this PR) and #13518 (fixture reuse — stop restarting the DB per test-template invocation) reports a **4.15x speedup on H2** (backend inits 460→48, 89.6% fewer) — that's the real "minimize restarts" win, and it's still open/unmerged with MySQL/PostgreSQL numbers not yet posted. This PR's container-*count* change is a much smaller, later slice on top of that, and on the data above it's roughly a wash-to-small-loss on wall clock in exchange for halving container footprint. **Next step, before deciding whether to ship as-is**: testing whether the ~3-5% MySQL slowdown is a tuning problem, not an architecture problem — the shared container is running MySQL's default (production-durability-oriented) config against 2x the concurrent DDL/DML load. `innodb_flush_log_at_trx_commit=0`, `sync_binlog=0`, and larger buffer/log-buffer sizes are all safe for a disposable test container and may close or reverse the gap without touching the container-sharing design at all. Will report back with results. **Recommendation as of now**: hold on merging until (a) #13518's own MySQL/PostgreSQL numbers land — that's where the real payoff is, and (b) the tuning experiment above tells us whether this PR's tradeoff is fixable cheaply. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
