Optimize Messages per second
Options
As in the documentation messages per second are calculated the following way:
That is, for 30 players / room:
30 players x (1 incoming request + 1 outgoing response + 29 events to other players) x 4 msg/s
30 x (1 + 1+ 29) x 4 = 30 x 31 x 4 = 3720 msg/s
==> This is way above the 500 msg/s limit and also one client will receive about 120 packets from other clients and maybe cannot handle that much!
1.) So why not pack all movements into one array?
Is there a possibility the photon server can pack all user movements into one array so that every user gets only one message from the server with all user data and not messages from all other clients in the room?
As in the above example the optimized version would look like:
30 players x (1 incoming request + 1 outgoing response) x 4 msg/s
30 x 2 x 4 = 240 msg/s
This looks good from the server side and also the client only has to handle 4 ingoing and outgoing messages to the server.
2.) Cull Area
I have seen the demo example with the cull area. My question is where can I set the updates to either 1 per second or 0, that means not rendered at all for players more far away
With cull area it may be possible to reduce the amount to 1/10 so the above example will come below 500 msg/s.
3.) No updates when no movements
This is already possible with the Observe option UreliableOnChange, is this right? This should also save about 70% of traffic but depends on game how often the players are idle.
4.) Updates per second
With cull are active I see the possibility to reduce the traffic much, but what happens if all 30 players meet at one point? Then maybe we have to lower the updates per second to 1-4. This will get very laggy but it should not happen so often. Best would be imho if there would be an option that the photon server handles the updates per second automatically to keep below the 500 msg/s.
That is, for 30 players / room:
30 players x (1 incoming request + 1 outgoing response + 29 events to other players) x 4 msg/s
30 x (1 + 1+ 29) x 4 = 30 x 31 x 4 = 3720 msg/s
==> This is way above the 500 msg/s limit and also one client will receive about 120 packets from other clients and maybe cannot handle that much!
1.) So why not pack all movements into one array?
Is there a possibility the photon server can pack all user movements into one array so that every user gets only one message from the server with all user data and not messages from all other clients in the room?
As in the above example the optimized version would look like:
30 players x (1 incoming request + 1 outgoing response) x 4 msg/s
30 x 2 x 4 = 240 msg/s
This looks good from the server side and also the client only has to handle 4 ingoing and outgoing messages to the server.
2.) Cull Area
I have seen the demo example with the cull area. My question is where can I set the updates to either 1 per second or 0, that means not rendered at all for players more far away
With cull area it may be possible to reduce the amount to 1/10 so the above example will come below 500 msg/s.
3.) No updates when no movements
This is already possible with the Observe option UreliableOnChange, is this right? This should also save about 70% of traffic but depends on game how often the players are idle.
4.) Updates per second
With cull are active I see the possibility to reduce the traffic much, but what happens if all 30 players meet at one point? Then maybe we have to lower the updates per second to 1-4. This will get very laggy but it should not happen so often. Best would be imho if there would be an option that the photon server handles the updates per second automatically to keep below the 500 msg/s.
0
Comments
-
Yes. you're right. The main problem in which we encounter in the photon cloud is the synchronization of the network data of a set of objects per second.1.) So why not pack all movements into one array?
I recently created such a synchronization of movement. But only for a lot of scene objects. Saving traffic - Reduced their number of commands 9-10 times, reduced the transmitted number of bytes per second by 2.5 times.
It is interesting that in this method there is no scatter(~16 %) of network data. We collect all the commands in a huge command-array and therefore there are no commands that could unite.0
