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 coherence.io? 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.
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.
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.
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.
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?
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>();
tag.Add(_currentSimulationRoom);
List<LobbyFilter> lobbyFilters = new List<LobbyFilter>();
findLobbyFilter.WithTag(FilterOperator.Equals,tag);
lobbyFilters.Add(findLobbyFilter);
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");
lobbySession.Result.LobbyOwnerActions.StartGameSession(LobbyStartGameSession);
}
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.
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:
9838523
9838510
Since I was trying to debug lobbies and I was printing out all the connection info.
