#3599 Optimize the /pull-request/ready internal API endpoint 
Closed: Fixed 5 years ago Opened 5 years ago by karsten.

In Pagure 5, the button to open a PR is on every page related to a git repository. The JS function related to that button calls the /pull-request/ready internal API endpoint. This endpoint calculates diffs of all branches against the main branch of the displayed repo and returns a response, from which the JS functionality creates a dropdown with all possible PRs to be created (this is called twice, once for the branches in the displayed repo and once for user's fork, if it exists).

The problem with this approach is that we have repos with a lot of branches, so even 2 or 3 people doing this at the same time can kill the server.

Ideas:
- Don't block the response of /pull-request/ready until the task is finished - this will occupy one httpd worker thread; rather return task id.
- Use the /task/<taskid> internal API endpoint to get the results of the task.
I'm not sure how this works exactly, but I think the task results will actually stay in redis until someone collects them. We need to make sure that if the user leaves the page and the polling JS code is terminated, the results get eventually removed from redis.


Metadata Update from @karsten:
- Issue assigned to karsten

5 years ago

with the current code the /pull-request/ready endpoint gets called each time a page with a PR button gets opened, even if creating a PR is not the intention for visiting that page. I'd propose a simple fix to calculate all the diffs of the branches to whenever the user clicks on the PR button.
A POC is at https://pagure.io/fork/karsten/pagure/branch/optimize_PR_ready

Login to comment on this ticket.

Metadata
Related Pull Requests
  • #3604 Merged 5 years ago