Photon——Performance Tips 性能技巧

 

Performance Tips 性能技巧

     Performance is a vital part for providing a fluid and seamless integration of multiplayer components into your application. So we assembled a list of tips you should keep in mind when developing with Photon.

     性能是多层组件与你的应用继承的至关重要的部分，以下是我们的建议。

 

     Call Service Regularly 定期调用服务

     The client libraries rely on regular calls to LitePeer.Service, to keep in touch with the server. Bigger pauses between the service calls could lead to a timeout disconnect, as the client can’t keep up the connection.

     客户端类库是依赖于调用 LitePeer.Service，来保持与服务端的连接。更大的服务调用可能导致超时断开连接，因为客户端不能保持着连接。

 

     Loading data is a common situation where less updates per second are done in the main loop. Make sure that service is called despite loading or the connection might suffer and be closed. If overlooked, this problem is hard to identify and reproduce.

     加载数据是一个常见的情况，在主程序循环中每秒执行几次更新。确保服务是被调用加载或是连接受阻和断开连接。如果被忽略，这个问题是很难被识别的。

     Updates vs. Bandwidth 更新与带宽

     Ramping up the number of updates per second makes a game more fluid and up-to-date. On the other hand, used bandwidth might increase dramatically. Keep in mind that possibly each operation you call will create events for other players.

     增加每秒更新的数量使得游戏是最新的和更加流畅，另一方面，使得带宽可能会显著的增长。记住可能每个操作你都可能会创建事件给其他玩家。

 

     On a mobile client 4 to 6 operations per second are fine. In some cases even 3G devices use pretty slow networking implementations. In fact, it might be faster to send fewer updates per second.

     在移动客户端，每秒4到6次更新是比较好的。在某些情况下3G设备使用的是相对慢的网络。事实上，他可能是每秒发送更少的更新。

 

     PC based clients can go a lot higher. The target frame rate should be the limit for these clients.

     基于PC的客户端可以高一些，对于这些客户端目标是限制帧率。

     Producing and Consuming Data 产生与使用数据

     Related to the bandwidth-topic is the problem of producing only the amount of data that can be consumed on the receiving end. If performance or frame rate don’t keep up with incoming events, they are outdated before they are executed.

     相关的问题是数据传输的带宽。如果性能与帧率不被限制在发送事件中，他们在执行前就过时了。

 

     In the worst case one side produces so much data that it breaks the receiving end. Keep an eye on the queue length of your clients while developing.

     最坏的情况是数据破坏了接收端。注意客户端的队列长度。

     Datagram Size 数据报大小

     The content size of datagrams is limited to 1200bytes to run on all devices.

     数据报在所有的设备上都被限制为1200字节。

 

     Operations and events that are bigger than 1200bytes get fragmented and are sent in multiple commands. These become reliable automatically, so the receiving side can reassemble and dispatch those bigger data chunks when completed.

     操作和事件的数据大于1200字节则分发在多个命令中。这样是可靠的，客户端可以重组数据报。

 

     Bigger data “streams” can considerably affect latency as they need to be reassembled from many packages before they are dispatched. They can be sent in a separate channel, so they don’t affect the “throw away” position updates of a (lower) channel number.

     更大的数据流可能造成延迟，造成他们需要重发，他们可以发送在独立的频道，这样他们不会影响一个较低频道的“throw away”的位置更新