Alertmanager: Receiver search box eats typed characters

Created on 20 Dec 2018  路  6Comments  路  Source: prometheus/alertmanager

What did you do?

Typing fast in the _Receiver:_ search box in a setup with many receivers.

What did you expect to see?

Typed characters appearing in the search box

What did you see instead? Under which circumstances?

Some typed characters don't show up.

Environment

  • System information:

    Linux 4.4.10+soundcloud x86_64

  • Alertmanager version:

    alertmanager, version 0.15.2 (branch: HEAD, revision: d19fae3bae451940b8470abb680cfdd59bfa7cfa)
    build user: root@3101e5b68a55
    build date: 20180814-10:53:39
    go version: go1.10.3

I totally understand that the autocomplete will be sluggish in a large setup. However, if I know what to type, I should just be able to type, ignoring autocomplete. I cannot do this. Instead, I find myself editing the URL directly because I can just type there.

@mxinden @w0rm as the Elm experts, perhaps you have an idea why the autocomplete is destructively interacting with the stream of typed characters?

areusability componenui kinbug

All 6 comments

I've attempted to improve the situation with https://github.com/prometheus/alertmanager/pull/1664

The issue is, each time a key is pressed, multiple asynchronous functions fire, such as the value of the text box. Because of the inefficiency/slowness of the function responsible for filtering the receiver search box, when you type "p-r", the code executes based on "p", and renders the values based on that.

The PR above is a "step in the right direction", but debouncing the input with i.e. 200ms delay between typing and doing the filtering would be even better.

I've added a debouncer in the above pr as well.

Just saying that with the current 0.16.0-beta.0, I can type as fast or as slowly as I want/can, I haven't seen a single eaten character since.

That's great. That's part of the upgrade to the latest version of elm.

Adding a debouncer and/or pagination and/or collapsed groups should improve performance, which I'm hoping to do for the next release.

Can this be closed, and a new issue "improve receiver box performance" be added? We have several ideas how to do this, and it would probably be good to move on to a new issue.

I'll close this. I'm not even sure if we need an issue for the "performance improvement" thing just for the receiver box. Feel free to do so if it helps tracking your own work.

Was this page helpful?
0 / 5 - 0 ratings