Page MenuHomePhabricator
Create Task
Maniphest T60926

Several issues in round-trip test server
Closed, ResolvedPublic
Actions

Description

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.
  1. 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.

Version: unspecified
Severity: normal

Details

Reference
bz58926

Event Timeline

• bzimport raised the priority of this task from to High.Nov 22 2014, 2:23 AM
• bzimport added a project: Parsoid-Tests.
• bzimport set Reference to bz58926.
• GWicke created this task.Dec 24 2013, 1:06 AM
gerritbot added a comment.Dec 24 2013, 1:10 AM

Change 103514 had a related patch set uploaded by GWicke:
Bug 58926: Cache perfStatsTypes

https://gerrit.wikimedia.org/r/103514

gerritbot added a comment.Dec 24 2013, 1:14 AM

Change 103514 merged by jenkins-bot:
Bug 58926: Cache perfStatsTypes

https://gerrit.wikimedia.org/r/103514

Dzahn added a comment.Dec 24 2013, 1:15 AM

note for bug wrangler: doesn't sound like _that_ RT.

• GWicke added a comment.Dec 24 2013, 1:20 AM

(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 ;)

• marcoil added a comment.Dec 24 2013, 12:08 PM

(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…

• GWicke added a comment.Dec 25 2013, 5:34 AM

(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.

gerritbot added a comment.Jan 14 2014, 11:29 AM

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

gerritbot added a comment.Jan 15 2014, 1:33 AM

Change 106672 merged by jenkins-bot:
Bug 58926: Keep track of known commits in rt server

https://gerrit.wikimedia.org/r/106672

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL