Overhead of sending many small RPC's
Options
I put a counter in the photonview.RPC() method and found that the game averages 70 RPc's per second, but can get up to about 400 when things get frantic.
Is there a significant overhead in sending many small RPC's per second compared to sending a few larger RPCs per second that aggregate the data?
By 'small' I'm referring to an RPC that has between 1 and 4 primitive parameters.
Is there a significant overhead in sending many small RPC's per second compared to sending a few larger RPCs per second that aggregate the data?
By 'small' I'm referring to an RPC that has between 1 and 4 primitive parameters.
0
Comments
-
When you look at a single RPC or just a few, then the overhead is not that much. Time, photonView, since PUN 1.20 we only use a code instead a RPC name. Aside from type info, this is also put in sequence (another few bytes).
However, if you call this several times a second and by thousands of players, this easily sums up to a lot of extra traffic.
If you send data in intervals anyways, you could try to use less RPCs and put more into each.
If that's not feasible, then maybe you can't help it. This might happen...
You should actually test this under worst conditions. We do have a msg/sec limit per room. Even though it's not a hard limit, you shouldn't bend it too much.
Connections also tend to break more easily when you use them up to their limitations.0 -
Thanks for the quick reply!
Does photon send RPC's immediately, or does it do some sort of internal bundling?If you send data in intervals anyways, you could try to use less RPCs and put more into each.
I would imagine that an advantage of sending smaller RPC's is that if they fail less data needs to be resent.
Can I find out what this limit is somewhere?We do have a msg/sec limit per room0 -
> Does photon send RPC's immediately, or does it do some sort of internal bundling?
It's aggregating everything that's going out to send less packages. The send rate defines when a new package is being filled.
Anything sent unreliably, won't get a resend, no matter if sent with other commands. If you send more individual packages, you get more overhead but potentially have to repeat less if one gets lost. However, if one gets lost, chances are higher another package, sent at about the same time, gets lost too (due to bandwidth issues or whatever).
> Can I find out what this limit is somewhere?
It seems we currently only list this on the pricing page:
https://cloud.exitgames.com/Pricing0
