Opened 7 years ago
Closed 7 years ago
#52750 closed defect (worksforme)
/changeset/:commitid/:repo is very slow for changes that do not exist
| Reported by: | neverpanic (Clemens Lang) | Owned by: | admin@… |
|---|---|---|---|
| Priority: | High | Milestone: | |
| Component: | server/hosting | Version: | 2.3.4 |
| Keywords: | Cc: | ||
| Port: |
Description
Crawlers seem to be accessing our copy of Trac and try to access changesets from the GitHub changeset module that no longer exist.
One such example is
- https://github.com/macports/macports-ports/commit/671c5d2885aad2df28c916e68f98a143e06bdf48 vs.
- https://github.com/macports/macports-ports/commit/ac26746154eb37fa1413e57f9f082bc2e37b9f22
Only the latter is still relevant, the former is still available at GitHub from a previous push, though. We should try find find out how to get rid of it.
One possibility to avoid the slowdown would be to just avoid validating whether a commit ID is valid in Trac and redirect to GitHub right-away. We need to figure out if anybody in Trac uses short commit IDs (if nobody does, we can drop the validation).
Here are IDs to test that:
Change History (2)
comment:1 Changed 7 years ago by neverpanic (Clemens Lang)
comment:2 Changed 7 years ago by neverpanic (Clemens Lang)
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
Cannot reproduce, seems fast at the moment.
Note: See
TracTickets for help on using
tickets.
Problem seems to be that checking whether a commit is in a repository is very slow with PyGit, due to shelling out to the git command line binary, see https://github.com/edgewall/trac/blob/1.0-stable/tracopt/versioncontrol/git/PyGIT.py#L700