Feature idea: measure and expose socket latency

Phoenix Forum Proposals/Suggestions
, ,
1

(re-post of: Feature idea: measure and expose socket latency · Issue #1890 · phoenixframework/phoenix_live_view · GitHub)

This is related to the following PR: buunguyen/topbar#15

Would LiveView developers be open to the idea of measuring the user’s latency, which could then be used to show loaders of any kind? With a pure timer, you still have a slice of users who can have a “negative experience”; with a 500ms cut-off, the most obvious slice would be the ones who have a 500-700ms latency. Latency-based loaders are better in this sense, since they use an actual signal to provide feedback to the user. To the user with a latency of 550ms, you can actually show the loader for 550ms, instead of for 50ms. Considering that the LiveView socket stays open, it provides an amazing opportunity to provide such feedback, with minimal drawbacks.

There is of course variance involved in various ways, but a decent implementation can account for it. It also relieves developers of having to measure latency manually (which I do in my projects).

3 Likes
2

Check the LiveBeats source. Latency detection is very easy to add yourself. I thought about adding it to LiveView, but you often will want to access the latency calc on the server as well (as we do in LiveBeats), so it’s better left to user land in my opinion:

11 Likes
3

Thanks. That’s how I’ve done it so far :slight_smile:. It’s quite rudimentary and works, but with LiveView one could even predict page load time ahead of time with a slightly smarter approach. E.g. if you can predict a page load will take ~300ms, you can show a loader immediately, without delaying it. Delaying the loader in my view effectively just pushes the problem further back and only improves the experience for a subset of the users. Measuring latency with various payloads in LiveView can give you a very good signal for how long an action might take.

Of course, alternatively there could be some sort of a plugin for this, not sure in which form though. Just food for thought, as I happened to spot the PR.

2 Likes
4

Right, but you can do all this with the linked code above :slight_smile: I agree you can do all kinds of interesting things with average latency calculations over the previous X period. You could even do this for buffer/quality calculations for media streaming. To handle the prediction usecase you mention, all you need to do is store the average latency in a reachable javascript object, then reference that in your progress bar code to determine whether or not to display a loader. I’ve been meaning to write a blog post on this, but the LiveBeats code gets you 95% of the way there in like a dozen lines of code total.

5 Likes
5

This is really useful! I’m measuring the latency to my Nerves device and it works great. My one question is, can I turn off logging for the “ping” event handler?

I created a live_session with hooks attached on mount to have the ping event handler on all pages within the session, as shown below. I really just want to remove the ping event from the logs, since it shows up once per second and Nerves doesn’t store a very large log history.

I did notice that in LiveView modules you can disable the log with some overrides in the macro: use Phoenix.LiveView, log: false. But I didn’t find an equivalent for hooks, or individual events for that matter.

Thanks!

defmodule FirmwareUiWeb.CommonHooks do
 alias Phoenix.LiveView

 def on_mount(_name, _params, _session, socket) do
   socket = 
     socket
     |> LiveView.attach_hook(:ping, :handle_event, &handle_ping/3)

   {:cont, socket}
 end

 def handle_ping("ping", _params, socket) do
   {:halt, LiveView.push_event(socket, "pong", %{})}
 end

 def handle_ping(_name, _params, socket), do: {:cont, socket}
end

defmodule FirmwareUiWeb.Router do
 use FirmwareUiWeb, :router

 # ...

 scope "/", FirmwareUiWeb do
   pipe_through :browser

   live_session :default, on_mount: FirmwareUiWeb.CommonHooks do
     live "/", HomeLive.Index
     live "/settings", SettingsLive.Index
     # ...
   end
 end

 # ...

end

And in the logs:

15:07:41.138 [debug] HANDLE EVENT "ping" in FirmwareUiWeb.SettingsLive.Index
  Parameters: %{"rtt" => 10}

15:07:41.139 [debug] Replied in 247µs

15:07:41.138 [debug] HANDLE EVENT "ping" in FirmwareUiWeb.SettingsLive.Index
  Parameters: %{"rtt" => 10}

15:07:41.139 [debug] Replied in 247µs

15:07:41.138 [debug] HANDLE EVENT "ping" in FirmwareUiWeb.SettingsLive.Index
  Parameters: %{"rtt" => 10}

15:07:41.139 [debug] Replied in 247µs
6

note that there has been a phoenix channels level (so phoenix.js) feature for socket.ping(rtt => console.log("rtt", rtt))

From LV you could do liveSocket.getSocket().ping(rtt => ...)

2 Likes
7

Amazing, thanks for the quick response! That clears up my logs a lot :slight_smile:

For anyone else who wants a client-only ping hook:

Hooks.Ping = {
  mounted() {
    this.timer = null
    this.ping()
  }, 
  reconnected() {
    clearTimeout(this.timer)
    this.ping()
  },
  destroyed() { 
    clearTimeout(this.timer) 
  },
  ping() {
    liveSocket.getSocket().ping(rtt => {
      this.el.innerText = `Ping: ${rtt} ms`
      this.timer = setTimeout(() => this.ping(), 1000)
    })
  }
};
1 Like