This page is a work in progress and could be pending updates.
server | v5 switch to V4  

Performance Tips

性能是將多人遊戲組件流暢、無縫地整合到您的應用程序中的重要部分。 因此,我們整理了一份使用Photon開發時應注意的提示清單。

If you are running a local Photon Server and noticed a bad event rate then this is most likely caused by logging. For instance, we noticed that enabling both Photon Server logging and Windows Defender may cause the event rate to slow down considerably. That is why we recommend disabling all virus scanners and firewalls when enabling Photon logging so you can have the expected events rate. You can re-enable the virus scanners and firewalls once you stop logging on Photon Servers.













You can usually send less to avoid traffic issues. Doing so has a lot of different approaches:


Don't Send More Than What's Needed

Exchange only what's totally necessary. Send only relevant values and derive as much as you can from them. Optimize what you send based on the context. Try to think about what you send and how often. Non critical data should be either recomputed on the receiving side based on the data synchronized or with what's happening in game instead of forced via synchronization.


  • In an RTS, you could send "orders" for a bunch of units when they happen. This is much leaner than sending position, rotation and velocity for each unit ten times a second. Good read: 1500 archers.

  • In a shooter, send a shot as position and direction. Bullets generally fly in a straight line, so you don't have to send individual positions every 100 ms. You can clean up a bullet when it hits anything or after it travelled "so many" units.

  • Don't send animations. Usually you can derive all animations from input and actions a player does. There is a good chance that a sent animation gets delayed and playing it too late usually looks awkward anyways.

  • Use delta compression. Send only values when they changes since last time they were sent. Use interpolation of data to smooth values on the receiving side. It's preferable over brute force synchronization and will save traffic.


Don't Send Too Much

Optimize exchanged types and data structures.


  • Make use of bytes instead of ints for small ints, make use of ints instead of floats where possible.
  • Avoid exchanging strings at all costs and prefer enums/bytes instead.
  • Avoid exchanging custom types unless you are totally sure about what get sent.

Use another service to download static or bigger data (e.g. maps). Photon is not built as content delivery system. It's often cheaper and easier to maintain to use HTTP-based content systems. Anything that's bigger than the Maximum Transfer Unit (MTU) will be fragmented and sent as multiple reliable packages (they have to arrive to assemble the full message again).


Don't Send Too Often

  • Lower the send rate, you should go under 10 if possible. This depends on your gameplay of course. This has a major impact on traffic. You can also use adaptive or dynamic send rate based on the user's activity or the exchanged data, this is also helping a lot.

  • Send unreliable when possible. You can use unreliable messages in most cases if you have to send another update as soon as possible. Unreliable messages never cause a repeat. Example: In an FPS, player position can usually be sent unreliable.



與 "流量 "主題相關的問題是,只生產可以在接收端消耗的數據量。 如果性能或幀率跟不上傳入的事件,它們在執行之前就已經過時了。

在最壞的情況下,一方產生如此多的數據,以至於破壞了接收端。 在開發時要注意您的客戶端的隊列長度。



即使一個客戶端有一段時間沒有調度傳入的消息(例如在加載時),它仍然會接收和緩沖所有的東西。 根據其他玩家的活動情況,客戶端可能會有很多東西需要跟進。

為了保持精簡,客戶端會自動將不可靠的消息削減到一定長度。 這樣做的目的是讓您更快地得到最新的信息,缺失的更新信息將很快被新的、最新的信息所取代。





這1200字節包括所有來自報頭(見"二進制協議")、大小和類型信息(見"Photon中的序列化")的過度負載,因此實際純有效載荷的數字會低一些。 事實上,即使它因數據結構的不同而不同,我們也可以有把握地認為,低於1kb的純有效載荷數據可以裝入一個數據報。

大於1200字節的操作和事件會被分割成碎片,並在多個命令中發送。 這些會自動變得可靠,接收方只有在收到所有碎片後才能重新組合和分配這些更大的數據塊。

更大的數據 "流 "會大大影響延遲,因為它們在發送前需要從許多包中重新組裝。 它們可以在一個單獨的通道中發送,所以它們不會影響一個(較低)通道號碼的 "實時 "位置更新。



C#客戶端通過OnEvent(EventData ev)接收事件。默認情況下,每個EventData都是一個新的實例,這給垃圾收集器帶來一些額外的工作。


To Document Top