Server specs


I recently discovered Photon and made a proof of concept for my Corona SDK game and im very pleased with it!
The game logic integrated in Photon Cloud was a very good fit for my game and I had no problem implementing it.
As an addition I would like to add leaderboards, but I found out this was not possible with the Cloud version of Photon.
I did some research and it looks like this CAN be done with Photon Server (Correct me if i'm wrong)

I have very little experience with servers, that's what I choose Photon Cloud in the first place.
I would like to know which server specs are needed to support my game.
The game is a "battle game", the battles look something like those in the Pokémon games.
There is little communication except creating a room, finding a room, sending "executeMove" commands every 5 - 30 sec.

For example with 500 CCU, which server should I pick best?
And for 1000 CCU or 2000 CCU?

Would love to know something more how to pick a server,
Thank you in advance



  • Maybe there is someone who can give me an example of how their server is running?
    What server they use and how many CCU they have
  • Hi Fr3eZer.

    Please be aware that realtime multiplayer gaming uses lots of traffic.

    From our experience 1.000CCU cause about 10 Tera(!)byte of traffic per month.
    As you can see at this results in immense traffic costs with Cloud hosting.
    Therefor you are usually much better of with renting bare-metal servers for the main user load and only using a cloud service for reacting to eventual short time load spikes.

    These threads may help you:
  • Thank you for your advice! I will sure look into bare-metal servers.
    I am sending very little data through the network though. Only calling client:service() 10 times a sec or so and sending 3 strings once between like 5 and 30 seconds.

    Is this very different than your example? or will I still create huge loads of traffic?

  • Kaiserludi
    Kaiserludi admin
    edited July 2015
    Well, lets do some math:

    As you can read at
    - UDP needs 28 byte per packet
    - Enet needs 12 byte per package
    - Enet needs additional 12 bytes per reliable command (or 16 bytes per command for unreliable commands)
    - the operation header needs another 8 byte
    - the operation itself needs another 2 byte + 1 byte per key, so for three strings this means 5 bytes
    - then we have 3 bytes per string value for length and type information, that means another 9 bytes
    - finally we have the payload of your strings itself, let's assume that each string is 20 characters long and your are only using characters that can be encoded in a single byte each -> another 60 bytes

    So in sum that means an overall message size of 28+12+12+8+5+9+60==134 bytes per message.

    So each client sends out such a 134 bytes message every let's say 10 seconds.

    Now lets say you have 8 players per room and every player has to receive the execute move messages of every other player in the same room.

    That means 1 message from a move executing client to the server triggers 7 messages from the server to the other clients in the same room. As every client sends a message every 10 seconds that means we actually have (1+7)x8==64 messages every 10 seconds

    That means 64x134== 8,576 bytes per room every 10 seconds or 51,456 bytes per minute per room.

    So with 8 players per room 1,000 CCU means 125 rooms, so 1,000 CCU will cause 125x51,456==6,432,000bytes per minute for 1.000 CCU.

    A 30 day month has 30days x 24hours x 60 minutes == 43,200 minutes, so 6,432,000 bytes per minute result in 6,432,000 x 43,200 == 277,862,400,000 bytes per month.

    277,862,400,000 bytes == 271,350,000 KB == 264,990.2 MB == 258.8GB Traffic per month per 1,000 CCU.

    With less player per room or without the need to send to everyone else in the same room you could get away with a lot less traffic due to the fact that when everyone needs to send to everyone else in the room the traffic increases squared to the number of players per room.

    So thanks to the fact that your sendrate of 6.4 messages per second for an assumed 8 players per room is very low compared to the average realtime or even turnbased game (for reference: Photon Clouds allows up to 500 messages per room for the Realtime and 100 for the Turnbased subscriptions), your overall traffic should not be huge.

    Disclaimer: Of course it is strongly recommended that you do some loadtests that are close to what real players will send as possible to make sure the load test traffic is in the same magnitude as the calculated values.
  • Wow thank you for this very clear explanation! It's really helpful
    Now I've got a good indication of the expected traffic in my game and can start comparing some cloud/bare-metal providers.

    Our game has 1v1 rooms, so the data traffic will be even lower :smile: of course I will do some load tests too later one when I have implemented full logic of my multiplayer.

    Again, thanks for the crystal clear explanation/calculation!