转---关于时间膨胀（Time Dilation或简称TiDi）

theninth1985

转---关于时间膨胀（Time Dilation或简称TiDi）

开发日志】关于时间膨胀（Time Dilation或简称TiDi）EVE ONLINE2012年05月22日 作者：CCP Veritas 译者：CCP Albo 　　常言说，与卡机延迟之间的战争我们是一定赢不了的，因为玩家总是可以叫更多的舰船来。这个说法从根本上看是正确的，而正视这个事实也对Gridlock小组的工作有重要的意义。除了之前的一些优化工作之外，我们还想着手解决战斗时卡装备的问题，这样当服务器不堪重负时，它也能比较合理地去应对。这就是本篇开发日志要讲的内容。不过，在理解我们的做法之前，你先要明白我们目前的处境。现在，当服务器负载过高时，它并没有明确的机制去解决这一问题，负责常规操作的机制只是按照它自己的步调前行。游戏中某些有趣的现象正是出于这个原因。不过在进一步阐述这个问题之前，我需要先对一些术语做出定义。 小任务(tasklet)，调度程序(scheduler)和让步(yielding) 　　基本上来讲，EVE的服务器运行着一系列的任务——可能是对客户端命令的回应，也可能是维持着装备（不止装备，几乎所有的内容）的正常状态。它们被称为小任务——你不需要知道为什么这么叫。但只要我们使用电脑，在特定某一时间内就只能运行一个小任务，而且我们需要一种软件来决定运行哪个小任务，这个就叫做调度程序。 　　调度程序分为不同的形式，负责EVE中的小任务运行的那种很简单，是一种循环合作式多任务调度程序。“循环”意思是每一个小任务都有机会运行，直到所有的小任务都运行了一遍为止，没有优先级，没有特殊待遇，非常公平不是吗，谁都有机会。合作式多任务意思是每个小任务在执行过程中都不会受到来自外部的干扰，它会一直运行下去直到运行完毕，或是走一种特殊的步骤，发出信号给调度程序，表明它希望让其它小任务现在来运行。这后一种情况就叫做让步。 　　所以这个系统就像这个样子： 　　你可能会自言自语“为什么有小任务会让步呢？”这个……如果它们很自私的话，它们当然不会让步，而是会把自己的一切全部搞定之后再把机会让给别的——往往也是不那么重要的任务。不过这样做并不好，因为独享CPU资源可不是个好主意。正因为如此，当我们在编写可能会用比较长的时间来执行的程序时，我们会在合适的地方添加让步指令，这样它和别的程序之间就能和谐共处了。 　　小任务会做出让步的另一个常见原因就是，它可能在等待来自其它地方——比如数据库的指令输入。一直停在那里等待返回指令并没有任何意义，我们可以让别的任务先来，而我们继续在一旁等待。（嗯没错，这个就是基于I/O完成指令的暂停状态。） 好吧伙计，那你怎么处理它们呢？ 　　非常抱歉，下面我要涉及一些计算机科学方面的专业内容了，它会解释清楚小任务在高负载下的主要运行方式。当服务器负载过高时，它在让步之后至少5秒钟才会开始下一个流程，这就导致任务无论是否顺利执行，都会花费非常长的时间才能完成，因为它一直在等待执行的流程。爆船就是个很好的例子——它会多次访问数据库，所以频繁地进行让步，这就把整个完成时间拖得很长。同样地，装备的运算流程有时会非常滞后，因为处理它们的小任务会在进行100毫秒的执行之后做出让步。 　　上面说了那么多都是为了下面这句做铺垫： 　　EVE的服务器应该将小任务等待执行时的队列时间降至最短——降到零最好。 　　这就是时间膨胀的意义所在。 　　要想在维持服务器正常运行的情况下实现这一目标，我们的选择并不多。基本上可以归结为两点：降低负载或是提高运算能力。 　　Gridlock小组花了很多时间，试图通过优化的方式达到降低负载的目的。我们可以，而且也很有可能继续为此而努力，而且也已经搞定了这方面的一些简单工作。使用多线程是提高运算能力的一种方法，它可以提高每秒钟的处理能力，但其实并没有人们想象的那么多。总有一天我们可以实现，但是现阶段它所需的工作量要远大于实际收益。 　　调节负载现在看来是势在必行了，因为我们已经完成了一大堆简单的优化工作。我们已经制定了几个不同的可行方案，最为大多数人认可的一个方案，是将Destiny——我们的物理模拟器——进行升级，这样当过载时它的每秒物理解析度将会降低。这样做可以帮助我们减少实际的模拟工作量，不过只能降低5%-10%的负载，所以也不怎么划算。 　　另一个普遍的观点是延长装备的循环时间，相应地提升效率与消耗。这样我们会有更多的自由空间，但是会极大地改变游戏的设计，改变的程度取决于负载的高低，这样可不行。现有的卡装备现象已经会改变游戏机制，所以为了不让事情变得更糟，我们不予考虑这种方法。 　　不过谢天谢地，我们终于找到了一种在不改变游戏设计的前提下有效控制负载的方法：将时间的流逝放缓。大型会战中很大一部分负载与时间计算有关——装备激活、物理模拟、飞行及跃迁等——这些都是在一定的时间内完成的，所以将时间分割开来将会相应地按比例降低他们的负载消耗。因此，我们的方法是将游戏时间放慢，尽量减少小任务执行时的等待时间，而当负载回归常态时，再将时间恢复正常。这个过程的执行将是动态的，并且有较细的档位划分，比如说，如果负载较轻的话，我们完全可以将时间调到正常的98%来运行。 　　好吧，那么在大型战斗中它的表现如何？ 　　以下是我对它在大型会战（比如1600人）中的表现的预想。当敌人的舰队跃迁进来时，服务器负载一下子变得很高（跃迁来去和放出无人机这类行为非常占用资源），于是游戏内的时钟也大大放缓，只有正常的5%左右。当这些运算都处理完毕后，服务器将允许时间恢复到正常的30%，这个时候战斗打响了。我们要面对1600个同时发生的战斗行为，他们的处理请求将迅速而平等地由服务器进行处理，只不过要花费比平时长三倍的时间。玩家们将会感受到舰船界面中装备循环变慢了，爆炸的动画也变慢了。伴随着一阵烟花，舰船减少到1200艘了，那么我估计时间将恢复到正常的60%。这时候一方的指挥官觉得大势已去，呼叫撤退。跃迁是很占资源的，所以随着舰船的离开，时间又大大变慢，到了正常的10%。最后战斗结束了，失败者也逃掉了，服务器负载变得很低，所以时间就恢复正常了。 　　当然这里面还有些很棘手的设计问题，比如说计时器遭遇时间膨胀会怎样。我觉得大多数情况下这个问题容易解决——如果增强模式计时器也能够被膨胀的话，那么玩家就可以在增强模式快结束的时候进行移动，这和我们的设计初衷相悖，所以增强模式计时器是不可以随着时间膨胀的。而另一方面，护盾的回充是持续性的，在战斗中具有重要意义，所以它必须要随时间膨胀而膨胀。基本原则就是，如果某件事情是偏重于现实中的时间的，那么它就不可以被膨胀。如果你觉得哪些情况不应该牵涉到时间膨胀，请在官方论坛中留言。 合理预期！ 　　时间膨胀并不是万能的。有些负载和时间毫无关联，所以我们不能处理规模不确定的战斗。我今天提到的应该已经涵盖了所有的常见情况。不过，我觉得我们应该为时间膨胀设定一个硬性的限制。在某个星系中出现0.1%的时间流速毫无意义，因为时间几乎静止，你什么都干不了。我不知道这个临界值将是多少——具体的还要等看看今后的部署效果再说。如果实际战斗中总是会突破这个临界值的限制，那我们就又回到现在这种服务器无响应而且时不时抽风的状态了。一切等待时间检验吧。 　　这篇日志很长，而且谈论的是一项试验性的内容。时间膨胀这个想法我早已有之，但直到今天也没有实际上投入太多的工作。我们去年八月做过一个试验品来测试游戏是否能够处理得了膨胀的时间，之后直到今天再无建树。我在全球玩家聚会上得到了大量的积极反馈，再加上星际管理委员会（CSM）将此作为他们最强烈的愿望，这些都激励了我，让我觉得是时候将其推出了。这可是一项大工程，所以2011年夏天你们就不要想看到它了。一切顺利的话，在秋季上线还是有希望的。 太长了，总结一下吧 　　时间膨胀的作用是将时间放慢，这样服务器就有足够的时间来处理你的请求。我们将会开始着手进行这项工作，如果一切顺利，它将在一段时间后与玩家见面。

银离子

国服那种渣渣服务器，时间膨胀根本不够，大型会战都要申请服务器资源专门调配……有些时候一过星门就是一堆拦截泡，总览直接卡死……

xu695622238

的确，服务器要强才是王道