我在NoJitter上读到了一篇很有意思的文章，是讨论Cisco部署Spark的方法。通过把媒体服务器铺设在离用户近的数据中心内，Cisco希望所有参与用户的延迟都保证在150毫秒之内。
仿照Dag-Inge的博客中讨论TURN服务器决定连接设定时间，我也在考虑我们是不是也能通过连接时间的长短来告诉我们TURN服务器是部署在正确的地点，或者我们是否需要改善我们的部署状态。毕竟，就像我之前写过的，这类运行设备是WebRTC服务中最重要的方面之一。
我们目前在appear.in的部署策略是基于负载的。在所有我们能够使用的AWS数据中心，我们都部署了至少一个TURN服务器，检测着流量以及当一个实例太过于拥挤的情况下启用其他实例。之后我们通过路由器53来将客户路由到最近的TURN服务器。
但是这样部署到底有多快多高效呢？
对于端到端的连接，从TURN服务器收集中继候选所花费的时间可以非常好地体现client和TURN服务器之间的往返时长。通过RTCPeerConnection.setLocalDescription调用和第一次icecandidate事件之间的延时来测量上面所说的时间。大概就像这样
同时不会因为客户跨区域而影响。实时上，浏览器会要求TURN服务器产生一个分配，返回一个未授权错误并且再次要求授权信任。所以这会来回进行两次往返（除非过程中发生了丢包）。在候选中的中继地址也给了我们关于所使用的中继服务器的参数。我们之前并没有收集它们，但是很容易添加的。
因为数据中包括了很多异常值，所以我们只取5000毫秒内的数据：
直觉上我们知道在用户近的地点运行TURN服务器是非常合适的。需要注意的是，我们测量的是两个来回的路径，所以我们可以将其除二来粗略的估计端到端延时。
我们可以利用这些指标来判断是否需要再部署另一个TURN服务器来改善延时，或者我们是否需要再另一个数据中心内启用其他服务器。上图中的新加坡和孟买的数据中心就是两个例子。
有一个奇怪的事情是，Firefox收集候选的延时要比Chrome多20毫秒。所以Firefox还是有空间来提升的。
