CodeImportSchedulerApplication:CodeImportSchedulerAPI timeouts
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Unassigned |
Bug Description
https:/
https:/
Branch: launchpad-rev-9760
Revno: 9760
SQL time: 7502 ms
Non-sql time: 9025 ms
Total time: 16527 ms
Statement Count: 5
The key bit is this:
4. 29 7474ms SQL-launchpad-
5. 16518 9ms SQL-launchpad-
Notes: one 7.5 second update (bad)
and a further 8 seconds unallocated - and we've check the code; there is almost nothing there. Its highly likely this is a scheduler issue and a single-threaded appserver will mitigate it. We need to find out in a controlled way whats up with the 8 second gap, but its not the fault of this code, so filing a separate bug. This bug is about the 7.5 second update.
tags: | added: pg83 |
Robert and I talked through this for quite a while today.
CodeImportJobSe t.getJobForMach ine (lp.code. model.codeimpor tjob) is where the fun happens.
The heartbeat update is happening in shouldLookForJo b(worker_ limit)
machine.
After the heartbeat, the only things are comparing a local db field with an enum, and comparing two integers. Neither of these would trigger the flush (we think). The next thing that happens is the CodeImportJob. selectOne call, which does trigger the flush. It is between the flush which sets the heartbeat, and the execution of the select that we are losing a lot of time.