StressTest & CPU occupancy [resolved]

Options
800eg
800eg
edited June 2022 in Photon Server

I am using a photon server and 6 game servers.


We are doing a stress test with the goal of opening 3000 CCU and 1500 rooms.



For testing, I created a Unity project that connects 1000 loadBalancingClients per computer to create 500 rooms, and 2 people participate and send one message to each other as updates.


As a result, there is a problem that the CPU share of the game server is too high.


The screenshot shows the number of messages and traffic for each room.

I used the PhotonStatsGui function as it is.


Average's message sum is 500msg per room and is recommended.

Is it the same number of messages?


I wonder if this is the correct way to do a stress test like this.


Best Answers

  • Meep
    Meep ✭✭✭
    Answer ✓
    Options

    What sort of specs are these Photon Servers running on? You should be able to house 3,000 CCU on 2 GameServers quite reliably... not 6 of them unless you have a hefty plugin.

    Testing on one computer is not a good way to test really since each of those connections has maybe 2 threads allocated to it, so it is unreliable in a real testing scenario.

  • chvetsov
    chvetsov mod
    Answer ✓
    Options

    hi @800eg

    1000 peers per generic computer is too much to get any reliable results for RTT but in general it might work if all you need is creation of connections. as @Meep wrote this way you create too many threads and OS spends too much time to manage them

    From my experience 500 is ok. (although it depends on your CPU)

    In regard of GS I can not say much - it all depends on Hardware and your plugins code.

    best,

    ilya

Answers

  • Meep
    Meep ✭✭✭
    Answer ✓
    Options

    What sort of specs are these Photon Servers running on? You should be able to house 3,000 CCU on 2 GameServers quite reliably... not 6 of them unless you have a hefty plugin.

    Testing on one computer is not a good way to test really since each of those connections has maybe 2 threads allocated to it, so it is unreliable in a real testing scenario.

  • chvetsov
    chvetsov mod
    Answer ✓
    Options

    hi @800eg

    1000 peers per generic computer is too much to get any reliable results for RTT but in general it might work if all you need is creation of connections. as @Meep wrote this way you create too many threads and OS spends too much time to manage them

    From my experience 500 is ok. (although it depends on your CPU)

    In regard of GS I can not say much - it all depends on Hardware and your plugins code.

    best,

    ilya

  • 800eg
    Options

    thank you for the reply!


    The exact hardware specifications of the server computer are not known.

    But the message is only sending a rise event of string per each client once per frame.


    Which method is more efficient?


    Reduce the number of peers and create a room for one computer,

    Is the other computer more correct way to join the room?

  • chvetsov
    Options

    Which method is more efficient?

    not sure what are you asking here?

    >Is the other computer more correct way to join the room?

    no


    best,

    ilya

  • 800eg
    Options

    @chvetsov

    I'm sorry my English is not good

    @meep say that

    Testing on one computer is not a good way to test really since each of those connections has maybe 2 threads allocated to it, so it is unreliable in a real testing scenario.

    <-- I saw this and asked for a better way

  • 800eg
    Options

    The problem has been resolved.

    The server's log is in debug mode, which significantly impacts performance.

    Even with 3000 connections, it still works well.

    The Photon Server is best.

    thank you

    Logging / log4net.config:

    - Make sure that you are using the "INFO" log level in all log4net.config files.

    - Excessive logging on the "DEBUG" level has a hugh performance impact and needs to be avoided!

    - Learn more about logging here: https://logging.apache.org/log4net/release/config-examples.html