Project

General

Profile

Actions

Patch #43208

open

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

Added by Katsuya HIDAKA about 8 hours ago. Updated about 7 hours ago.

Status:
New
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 about 7 hours 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

Also available in: Atom PDF