Project

General

Profile

Actions

Patch #43208

closed

Reduce requests sent for issue numbers, usernames, and Wiki page name autocompletion

Added by Katsuya HIDAKA 2 days ago. Updated about 19 hours ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Performance
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Background / Purpose

Currently, autocompletion for issue numbers (#123), usernames (@username), and Wiki page names ([[wiki page name]]) sends a request for every keystroke.

For example, when typing aaaaaaaaaa quickly after # in an issue description, the endpoint /issues/auto_complete is called 10 times:

Started GET "/issues/auto_complete?project_id=ecookbook&q=a" for ...
Started GET "/issues/auto_complete?project_id=ecookbook&q=aa" for ...
Started GET "/issues/auto_complete?project_id=ecookbook&q=aaa" for ...
(snip)
Started GET "/issues/auto_complete?project_id=ecookbook&q=aaaaaaaaaa" for ...

In practice, a single request with the final input (aaaaaaaaaa) is sufficient.

Although a single /issues/auto_complete request is lightweight, sending many in quick succession can consume processes and DB connections, potentially degrading performance.

This patch introduces debounce to all autocompletion requests to reduce unnecessary traffic.

Details

  • Implemented a debounce() function
  • Applied a 300ms debounce to all autocomplete requests

Verification

  • All tests pass, including test/system/inline_autocomplete_test.rb
  • Verified that the number of requests decreases
    • When typing #aaaaaaaaaa quickly, only ONE request is sent
    • Also confirmed that the total number of requests in test/system/inline_autocomplete_test.rb decreased from 19 to 12
  • Verified that autocompletion for issue numbers, usernames, and Wiki page names works as before


Files

Actions #1

Updated by Go MAEDA 2 days ago

I also felt that sending a request for every keystroke when fetching autocomplete suggestions could become a performance issue, so thank you for posting this patch to address it.

I have one suggestion: the current debounce delay is set to 300ms, but would it be possible to reduce it to 200ms? With 300ms, I feel there is a slight wait before the list of suggestions appears.

Actions #2

Updated by Katsuya HIDAKA 1 day ago

Thank you for your feedback.

I tested again with the debounce delay changed to 200ms, and it looks good.

200ms also reduces load compared with the current behavior, and it is closer to the current timing of suggestions.

I have also attached an additional patch (0002). Please squash 0002 into 0001 when applying the patches.

Actions #3

Updated by Go MAEDA 1 day ago

  • Target version set to 6.1.0

Setting the target version to 6.1.0.

Actions #4

Updated by Go MAEDA about 19 hours ago

  • Status changed from New to Closed
  • Assignee set to Go MAEDA

Committed the patch in r23978. Thank you.

Actions

Also available in: Atom PDF