Spinning up a new GenServer for each room

I have been learning from the videoroom demo and I have a few questions.

# meeting.ex
  @impl true
  def init(%{name: name, jellyfish_address: jellyfish_address}) do
    Logger.metadata(room_name: name)

    client = Jellyfish.Client.new(server_address: jellyfish_address)

    with {:ok, room, jellyfish_address} <- create_new_room(client, name) do
      peer_timeout = Application.fetch_env!(:videoroom, :peer_join_timeout)

      client = Jellyfish.Client.update_address(client, jellyfish_address)

      Logger.info("Created meeting room id: #{room.id}")

      {:ok,
       %State{
         client: client,
         name: name,
         room_id: room.id,
         peer_timers: %{},
         peer_timeout: peer_timeout,
         jellyfish_address: jellyfish_address
       }}
    else
      {:error, reason} ->
        Logger.error("Failed to create a meeting, reason: #{inspect(reason)}")
        raise "Failed to create a meeting, reason: #{inspect(reason)}"
    end
  end

# meeting.ex
  @impl true
  def init(%{name: name, jellyfish_address: jellyfish_address}) do
    Logger.metadata(room_name: name)

    client = Jellyfish.Client.new(server_address: jellyfish_address)

    with {:ok, room, jellyfish_address} <- create_new_room(client, name) do
      peer_timeout = Application.fetch_env!(:videoroom, :peer_join_timeout)

      client = Jellyfish.Client.update_address(client, jellyfish_address)

      Logger.info("Created meeting room id: #{room.id}")

      {:ok,
       %State{
         client: client,
         name: name,
         room_id: room.id,
         peer_timers: %{},
         peer_timeout: peer_timeout,
         jellyfish_address: jellyfish_address
       }}
    else
      {:error, reason} ->
        Logger.error("Failed to create a meeting, reason: #{inspect(reason)}")
        raise "Failed to create a meeting, reason: #{inspect(reason)}"
    end
  end

I am wondering what the overhead would be for starting a GenServer for each room at a large scale and if there is a better way? My first impression which may not be correct or smart, is that we could skip the overhead of GenServers and interface directly with the jellyfish sdk directly without a GenServer. All of the nice state like peer_timers could be put into a in-memory key-value store would it work to store a single map in an in-memory key-value store of the form

%{
"jelly_address_1": %Jellyfish.Client{ ... }
"jelly_address_2": %Jellyfish.Client{ ... }
}

%{
"jelly_address_1": %Jellyfish.Client{ ... }
"jelly_address_2": %Jellyfish.Client{ ... }
}

This way a jellyfish client is only created once for each jellyfish instance instead of creating one for each room or is this a bad idea? Is it wrong / a bottle neck if many rooms try to use the same jellyfish client?

0 Replies

No replies yetBe the first to reply to this messageJoin

Gaming

Programming

Spinning up a new GenServer for each room