What happened:
I have a big github repository that has thousands of pull requests in it. When I open a new pull request in that repository, it takes tens of seconds to process webhook and sometimes ends with timeout by github webhook service (30s).
What you expected to happen:
Each webhook is processed in a few seconds.
How to reproduce it:
References
I had a quick look into this issue and found some points that we might be able to fix.
Webhook plugin runs pipeline.sync operation every time after PR is opened, synced or closed. I think it doesn't needed for these events. Is it enough to call pipeline.syncPR?
https://github.com/screwdriver-cd/screwdriver/blob/5c6c4870f539a04ae829926ba52c642d70bfb4f0/plugins/webhooks/index.js#L210
https://github.com/screwdriver-cd/screwdriver/blob/5c6c4870f539a04ae829926ba52c642d70bfb4f0/plugins/webhooks/index.js#L267
https://github.com/screwdriver-cd/screwdriver/blob/5c6c4870f539a04ae829926ba52c642d70bfb4f0/plugins/webhooks/index.js#L296
This is related to 1.
pipeline.jobs operation fetches all jobs stored in database and creates/instantiates them even if there are thousands of archived jobs. pipelines.jobs is called by pipeline.sync and this issue got happen.
Can we avoid scanning all records for jobs? for instance skipping archived: 1 records
https://github.com/screwdriver-cd/models/blob/412f74eb2cdf6db5b65f2f940e3cb6505bab25c3/lib/pipeline.js#L639
https://github.com/screwdriver-cd/models/blob/412f74eb2cdf6db5b65f2f940e3cb6505bab25c3/lib/pipeline.js#L875
The most heaviest function call during fetching jobs is here:
https://github.com/screwdriver-cd/datastore-sequelize/blob/9c396a178a9e3254887720488b4d48a40483d847/index.js#L458-L459
The second time accessing pipeline.jobs should be faster since it already has jobs instances but it costs a lot because of the number of instances.
https://github.com/screwdriver-cd/screwdriver/blob/master/plugins/webhooks/index.js#L309
Currently webhook plugin waits for 1.8 seconds on every PR webhooks.
I have read the original issue and found it occurs only when synchronized event. Should we run it only when event type is synchronized?
We should check if a result of listFiles API includes the desired SHA or not instead of putting 1.8sec wait so that webhook endpoint will be faster for most cases and every PR build ensures the latest changed files are reflected to github.
https://developer.github.com/v3/pulls/#list-pull-requests-files
edit: key sha in a result of listFiles API doesn't represent a commit object 馃槥
No.2 is being fixed via #1603
@catto one other issue I see is wrt scm.getBranchList() https://github.com/screwdriver-cd/screwdriver/blob/master/plugins/webhooks/index.js#L174
We have that for branch filtering feature for identifying triggered pipelines. However we could refactor it such that it does not reach out to Git and instead query our database for triggered pipelines.
By not calling git we are more resilient against Git errors.
https://github.com/screwdriver-cd/screwdriver/pull/1643/files addresses my previous comment
Last work has been done at https://github.com/screwdriver-cd/screwdriver/pull/1653/files which addresses https://github.com/screwdriver-cd/screwdriver/issues/1468#issuecomment-460035553
Reopening the issue because "3. magic wait for 1.8 secs every time" I wrote is probably fixable now. Also sometimes I see issues like screwdriver.yaml not found because of magic branch is not updated. #593
Let's replace 1.8 sec wait with polling pull_request API.
https://developer.github.com/v3/git/#checking-mergeability-of-pull-requests
according to GitHub doc,
mergeable is null, wait a sec and retrymergeable is true, we can use merge refs to get yaml.mergeable is false, we were discussing the other day https://github.com/screwdriver-cd/screwdriver/issues/1769
current thought process is that we are doing too many processing during webhooks and should push heavy processing to an offline flow
@jithin1987 Yes I read the issue #1769. However there are two problems around webhooks.
In this ticket, we will focus on fixing problem 2 so that the performance and stability can be improved by trimming 1.8s wait and ensuring existing of magic branches.
Does it make sense?
@catto agree. Let's tackle both angles.
Closing this one since we already have #1769 to tackle pending performance improvements for webhook API