Coherence instantiation and webgl

We recently did a pseudo stress test on a webgl build, we noticed that after a certain number of users connected, we stopped getting avatars instantiated for those users. Are there any soft caps or caps for the default instantiation for users?

For setup this is on Coherence 1.1.4, Unity 2023.2, Current coherence sync object settings:

I have the room setup set to 100 users. As for numbers it seemed be as we approached 20 concurrent users avatars stopped spawning around 15.

Would switching to object pooling do anything? I couldn’t find anything about it going back to the minimum and on webgl I would like to be able to manage that due to memory concerns. Or is this something that we need to implement our own instantiation monobehavior.

Hi Michael - can you share your project ID and a little more about your setup? Are you using a local webGL build or one uploaded to Are each client joining the room immediately upon creation from e.g. a lobby or are you starting each client individually with e.g. multiple browsers? We will investigate what might be going on. One thing we have noticed is that backgrounded chrome tabs behave differently - are you perhaps starting multiple tabs in the background?

The project ID is Virbela I think. We are hosting this ourselves. The multiple tabs might be a thing. Our pseudo stress test is basically opening many tabs to log in to see what the behavior is like. It’s not really in the background since we have to click in to log in and then load unity. But we don’t join the coherence room until the scene is done loading. Not sure what other data you would need.

1 Like

In my experience, WebGL is severely limited when it goes in a background tab, like Brit mentioned. I don’t know how much we can do about it (but I might be wrong).
Is it possible that you’re relying on a command that is somehow never received?

If you can test it again, try running the same but instead of having the instances as tabs in the same window, open them as new windows. Even if they are not visible, they will not be throttled by Chrome so you might have completely different results.

It could be useful to isolate the issue.

Yup, please give it a try with a new window per client and let us know if that fixes your issue. What you may be seeing when you’re only seeing ~15 or so clients is that old browser tabs are “falling off” - they have stopped sending their heartbeat so the RS times them out and removes their client connection.

So we had another test today and it seemed like people got split into different instances of the same room, looking at the Rooms list there were several instances.

The specific ids are:
9640698, 9640687

Right now the flow, based on me following the example project is:

  • Wait for the coherence bridge to connect to the coherence backend
  • Async call to get the regions
  • Get the current rooms from the region
  • For loop through all the returned rooms, I do a string compare on the room name
  • If it exists join that room, otherwise create the room.

Is there a way to guarantee that users join the same instance of a room? Or is there a possible race condition where if I have multiple users trying to log in at the same time that they would create 2 rooms since the list could be empty?

It sounds like there is indeed a race happening, yes. Although it’s more complex does your use case include the need for the concept of a “Lobby”? We have a Lobby API, with FindOrCreate functionality: Lobbies | SDK 1.1 | Unity Multiplayer SDK Documentation | coherence

This would allow your players to be entered into a lobby based on your game code, which could then automatically start the game session (and room) as well.

No, in our case the flow is that we have a predetermined list of room names for that user. And anyone that is on the same list would join the same rooms. A lobby doesn’t work for what we are doing in this case.

Is this something that a simulator can handle? Essentially have an authority on creating rooms? Since it seems like we would need 1 spot that manages the creation of rooms.

Or is your suggestion that we can use a lobby and immediately create the room to guard against this scenario?

The simulator would not help in this scenario as simulators only connect after a room is created, and so could not manage rooms.

The lobby API is a layer on top of rooms for filtering, queueing, tagging and organizing which players and any metadata like teams will join a room, so I think it’s a good fit for what you are wanting to do. It can be completely transparent to the end player (like you are doing with rooms) and can be your own application logic managing this.

In a future update, we plan to support FindOrCreate for rooms, using a string ‘tag’ value, which can be a proxy for your room name, and avoiding the race condition. So if that is your only need perhaps that can fit your use case (and you can work around race conditions with temporary logic). We will be sure to update you once FindOrCreate is working in the rooms API.

Here are the lobby docs:

Yeah that FindorCreate for rooms that I can have a single source of truth would be perfect. Is there a time frame for that?

I’ll look into lobbies in the meantime. I’m just concerned about added complexity/timing since a user can bounce between rooms fairly often and if there is a Lobby creation(or joining) → room creation every time they do that it could slow things down.

Our current goal is to get this into a 1.2.1 release - I don’t have an exact time frame on that, but it’s actively being worked on.

So I might be hitting a wall with lobbies. My understanding is lobbies stay open when the session starts? Or is that a setting that I’m missing?

Basically what I’m trying to do now is:
User A is the first to connect
I call FindOrCreateLobby with the tag being the roomname I want. I’m not setting any other attributes at the moment.
Response I get is that User A is owner of the lobby, so I immediately start the session.

UserB seems to go through the exact same process and creates a new lobby + new game session.

I didn’t think the lobby closed after, or do I need more unique or specific attributes set to guarantee that User B finds the same lobby?

Do you want the game session to start immediately, or are you looking to wait until everyone joins the lobby?

Can you share some code you’re using to formulate your lobby request?

People will be joining and leaving at will and I need a way to guarantee that they join the same room. So I can’t wait for everyone to join a lobby before a session starts.

So I need the session to start immediately but keep the lobby open, unless there is another way to guarantee that the room a user joins is unique.

This is what I’m using to call FindOrCreateLobby:

FindLobbyOptions findLobbyOptions = new FindLobbyOptions();
            LobbyFilter findLobbyFilter = new LobbyFilter();
            // At the moment we are just using the room name to be unique to filter lobbies.
            List<string> tag = new List<string>();
            List<LobbyFilter> lobbyFilters = new List<LobbyFilter>();
            findLobbyOptions.LobbyFilters = lobbyFilters;
            CreateLobbyOptions createLobbyOptions = new CreateLobbyOptions();
            createLobbyOptions.Tag = _currentSimulationRoom;
            createLobbyOptions.Region = region;
            createLobbyOptions.MaxPlayers = 100;
            createLobbyOptions.Unlisted = false;
            _coherenceCloudService.Rooms.LobbyService.FindOrCreateLobby(findLobbyOptions, createLobbyOptions, LobbyJoined);

And the callback when a lobby is joined:

if(lobbySession.Status == RequestStatus.Success)
                if (lobbySession.Result.LobbyOwnerActions != null)
                    Debug.Log("Lobby Owner starting game session");
                else if (lobbySession.Result.LobbyData.RoomData != null)
                    Debug.Log("RoomData is not null: " + lobbySession.Result.LobbyData.RoomData.Value.UniqueId);

I believe the issue is that with StartGameSession there are some additional parameters, and by default we unlist the lobby (it can’t be found by future players, but remains open)

Give it a try with unlist set to false, and the lobby should remain listed for other players to join:

Yep that was it, thank you. I don’t know if this is related or if I need to make a new post but starting today we’ve been getting these webrtc with webgl builds errors.

There was a period where everything was working well and I had up to 8+ connections done and I could see everyone. But now with a new build I’m getting these errors consistently.

I seem to be getting this when another user connects to the session.

Can you send along one of your RoomIDs where this happened? I see quite a few of your rooms created, most of them empty with no connections.

Did anything change in your build from one to the other?

No, this was also happening on our dev version which was working fine on Thursday. And of course now that I try to reproduce today it isn’t showing up. I’ll try to catch logs/room ids if/when it happens again. It kind of shut us down for dev work all day Friday though. I do know it was happening with the ids:

Since I was trying to debug lobbies and I was printing out all the connection info.