Optimise publication crosslinks

[finlay-jisc]

The purpose of this PR was to optimise the slowest query I could find in octopus. This was the full text filtering part of the getPublicationCrosslinks function. I looked into what prisma was doing in SQL and attempted to improve it. The main improvement is using a union to collect all the crosslinks (to and from a publication, as they can be either way) into one group.

This results in fewer queries:

• Getting mixed crosslinks reduced from 20 to 7 queries
• Getting recent/relevant crosslinks reduced from 11 to 4 queries

I collected some timings to see if it was an improvement in speed. I tested each case 5 times and collected an average before working out the difference between the new method's average time and the old method's average time. The margins are quite low because the seed data is not massive, but the new method is consistently quicker (times in ms):

• Get recent crosslinks
  • Total request time: -28.2 (-4.2%)
  • Total query time:-6 (-40.5%)
  • Service function duration: -6.4 (-25%)
• Get recent crosslinks with "analysis" text filter
  • Total request time: -53.2 (-7.2%)
  • Total query time: -4 (-4.5%)
  • Service function duration: -16.8 (-16.6%)
• Get recent crosslinks owned by requesting user
  • Total request time: -9.2 (-1.4%)
  • Total query time: -3.4 (-24.3%)
  • Service function duration: -4.6 (-25%)
• Get mixed crosslinks
  • Total request time: +4.8 (+0.7%)
  • Total query time: -9.6 (-40.3%)
  • Service function duration: -12.6 (-47.6%)

On average across these 4 tests:

• Total request time was 3% quicker
• Query time was 27.4% quicker
• The service function was 28.6% quicker

---

Checklist:

• Local manual testing conducted
• Automated tests added
• Documentation updated

---

Tests:

API

E2E

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
octopus	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 16, 2024 9:16am

[adwearing-jisc]

I wonder if all this conditional stuff lends to stored procedures being a better solution? This is quite difficult to read and follow. I've had a similar style of query in a project I worked on in the past, it was a bit of a nightmare trying to build the query up to test it outside of the api.