Last modified: 2014-01-15 10:34:41 UTC
There are some issues in the RT test server: 1) A client working on an older revision causes the rt test server to hang for all other clients. We should reject requests for anything but the last revision. 2) The query 'SELECT DISTINCT type FROM perfstats' takes minutes each, and causes the entire rt server to block. It seems to be a very inefficient way to figure out the (essentially static) list of stats we are collecting. As more stats are collected and the stats table does not fit into RAM any more, this is getting *really* slow.
Change 103514 had a related patch set uploaded by GWicke: Bug 58926: Cache perfStatsTypes https://gerrit.wikimedia.org/r/103514
Change 103514 merged by jenkins-bot: Bug 58926: Cache perfStatsTypes https://gerrit.wikimedia.org/r/103514
note for bug wrangler: doesn't sound like _that_ RT.
(In reply to comment #3) > note for bug wrangler: doesn't sound like _that_ RT. Changed the summary so that you folks not checking the product are not confused ;)
(In reply to comment #0) > 1) A client working on an older revision causes the rt test server to hang > for > all other clients. We should reject requests for anything but the last > revision. It may be due to reloading a title batch. If a client request comes from a different commit than the last one, the current batch is discarded, as the set of electable pages could be different. Unfortunately, commit hashes are not time-ordered, and we presupposed that clients would move forward. We could reject incoming requests if they are not from either: - The latest recorded commit hash, or - A completely new commit hash that we didn't know about. That would introduce a delay, though…
(In reply to comment #5) > Unfortunately, commit hashes are not time-ordered, and we presupposed that > clients would move forward. Our commits table has a timestamp for each commit (IIRC based on the actual commit timestamp even). This makes it possible to determine what the last known commit is. > We could reject incoming requests if they are not > from either: > - The latest recorded commit hash, or > - A completely new commit hash that we didn't know about. > > That would introduce a delay, though… We can just store the hashes we know about and the latest hash in variables. Checking those is cheap and should not add any appreciable delay.
Change 106672 had a related patch set uploaded by Marcoil: Bug 58926: Keep track of known commits in rt server https://gerrit.wikimedia.org/r/106672
Change 106672 merged by jenkins-bot: Bug 58926: Keep track of known commits in rt server https://gerrit.wikimedia.org/r/106672
