CCU count and rooms count in stats more than real number?

Very often I sees some strange things with the statistics. It shows two rooms when there is only one and 4-5 CCU when there are 3 players in game. How could it be?
The room is created with all default parameters, i.e. emptyRoomTtl is 0

Comments

  • For example, this screenshot of the stats screen:

    https://drive.google.com/file/d/1f3_zHj17LX9T5SHWmEz7s3uNCJRbyvMv/view?usp=sharing

    It shows 18! CCU and 4 rooms max when there actually was 2 rooms max and 7-8 players
  • Hi @ufnv.

    Is there any chance that your players just closed their clients, when leaving a room?

    When the client does not do a regular opLeaveRoom() or disconnect() call, then it will still appear online until the timeout kicks in. If the clients already connects with a new user ID during that time, then it will account for 2 CCU for a a couple of seconds.
    The graph shows the peak CCU and not the average, so it can easily be affected by something like this, when you have very low amounts of players like during development.

    You said that the emptyRoomTtl is 0.
    However the unexpectedly high CCU indicate that the rooms are not empty yet, so the emptyRoomTtl should not be relevant for these rooms yet.
  • >Is there any chance that your players just closed their clients, when leaving a room?
    Don't think so. From logs they clearly do opLeaveRoom() and then disconnect()

    Maybe some extended logging could help to understand what is going on?
  • Kaiserludi
    Kaiserludi admin
    edited June 2020
    Hi @ufnv.

    I assume you don't connect multiple LoadBalancing::Client or Photon::PhotonPeer instances from one physical client in parallel? Each of those connections would count against the CCU individually.

    Can you reproduce the observed behavior with one of demo apps?
    If yes, then please provide reproduction steps and if not, then please track down which of the differences between your app and the demos is causing this.
    Maybe some extended logging could help to understand what is going on?
    You could increase the logging level of the LoadBalancing::Client instance by a call to Client::setDebugOutputLevel().