1. 使用Versant对象数据库的大型多人在线游
戏性能
Versant 白皮书
作者：Derek Laufenberg
© Versant Corporation
255 Shoreline Drive, Suite 450
Redwood City, CA 94065
email: info@versant.com
Main: (650) 232 2400
Fax: (650) 232 2401
web: www.versant.com

2. 摘要
详细的游戏模型和机器模拟被用来生成对数据库服务器的真实负载。收集到
的计时数据证明了测试硬件的能力，并且指明了数据库服务器所能够支持的玩家
数量的上限。引入“玩家—分钟”这个概念是为了将性能的数据规格化，推断出
最大在线玩家负载。
使用价格低廉的硬件和 250 个玩家的测试负载，收集到的计时数据显示，服
务器的性能要比实时要求快上成百上千倍。 只要服务器的性能比实时要求快就可
以支持新增的玩家，这也证明了支持七万多名玩家所必须的系统带宽。
概述
这个例子使用的是一个非常详尽的持久性对象模型。 该模型不严格地建立在
当今非常盛行的拥有大量玩家—角色数据的大型多人在线游戏上（例如 WoW，
EverQuest）。这个模型的设计目标是要对游戏服务器在数据库服务器上运行的
一系列操作进行测试。测试客户端执行影响游戏角色持久性状态的模拟游戏动
作。被改变的对象和新建的对象会尽快地被传送到数据库，整套操作都会重复进
行。测试客户端可以尽快地运行以试图达到数据库的性能极限。对一组动作收集
的计时数据可以用来衡量一组模拟玩家在线时数据库的性能。
对一个“普通的玩家”来说，在给定的游戏时间单位内会对数据库生成的一
定量的负载。为了使计时数据规格化，所以使用了“玩家—分钟”游戏活动的概
念。玩家—分钟被定义为玩家在一分钟的时间完成的所有的动作以及这些动作的
频率。单个动作的频率各不相同，但是作为一个综合的估算值，所有的动作将能
够代表大量玩家在服务器上施加的数据库负载。 因为有些动作可能一个小时之内
只会出现几次，而另一些动作一分钟内就会出现很多次，所以一些动作会有小数
值。
使用了这个模型以后，就有可能实现其它的负载配置。游戏设计者可以调优
或是测试不同的游戏概念，观察数据库负载的结果。这份白皮书讨论了角色登录
配置以及活跃玩家活动配置。活跃玩家配置假定一个大量创建和删除物品的非常
活跃的玩家。
游戏模型
下面的 UML（统一建模语言）图描述了用 C++来完成的游戏持久化类模型。
玩家及其支持的类都被用来模拟游戏服务器中一个典型的的操作。 当对象通过不
同的玩家动作改变之后，这些对象会被写回到服务器里。因为大多数大型多人在
线游戏都与玩家的装备和行会有关， 所以这些概念可以在模型和用例里得以详细
化。例如，载入一个玩家的性能很大程度上依赖于该玩家拥有的物品数量。

3. 当载入一个玩家时，他所拥有的全部物品也都将被载入。玩家所拥有的对象
会被载入到测试客户端，并在服务器上被锁住，以防止其它的进程改变它。这个
载入和加锁进程可以防止各种游戏问题的出现，比如复制故障。
表 1 游戏模型 统一建模语言
为了进行测试，每一个玩家都会有 100 个物品，但是根据物品创建/删除用
例，物品列表可以增加或缩减。在这个模型中，玩家创建的物品比删除的物品更
多，所以过了一段时间，玩家在他们的物品栏中就会有 200 至 300 个物品。根
据这个模型，每个玩家的角色大约使用 16KB 的空间。这可能要比现在大多数大
型多人在线游戏使用的要详细得多，但是这可以使游戏对象之间进行更多的互
动。

4. 例如，在这个模型中，可以设计成当发生交易时物品能够追踪到它以前的主
人。这可以被用于社交网络游戏机制，或用于某种形式的欺诈侦测。
测试条件
这个测试在一个简单的两台机器组成的配置上进行。一台 Windows XP 笔
记本用来运行测试客户端软件。 另外一台能力稍强的台式计算机则用来运行数据
库服务器。一个专门的 1 GBit 的以太网被用来连接客户端和服务器系统。
客户端机器 服务器机器
Intel T7200 Core2 Dual 2.0 GHz Intel Q6600 Core2 Quad 2.4 GHz
2 GB RAM 4GB RAM
Windows XP 32bit – SP3 Linux 5 64bit
数据库测试群体
测试数据库有 5 万个帐户，每个帐户有 5 个玩家。每个玩家有 100 个物品。
数据库也已创建了 5000 个行会以及随机玩家构成的成员名单。数据库的空间大
小为 8GB，跨两个文件卷。磁盘驱动器则是成本低廉的 7200 RPM SATA 磁盘驱
动器，是台式机系统使用的典型的磁盘驱动器。
Database Population
50000 instances of 'Account'
250000 instances of 'Player'
250000 instances of 'PlayerTaxi'
250000 instances of 'PlayerZones'
250000 instances of 'PlayerBulkData'
250000 instances of 'PlayerHighFreq'
250000 instances of 'Mailbox'
250000 instances of 'Bank'
250000 instances of 'Pet'
250000 instances of 'VISet<Quest>'
25049127 instances of 'Item'
5000 instances of 'Guild'
30000 instances of 'GuildRank'
5000 instances of 'Quest'
10004 instances of 'ItemDescriptor'
登录测试案例
通常登录和角色选择进程是由不同的服务器， 甚至可能是由不同的数据库服
务器来处理的。因为 Versant 能够跨不同的数据库引用对象，所以，很自然可以

5. 将帐户数据放进它自己的数据库，然后使用 LOID（逻辑对象标识）引用已选中
的角色进行载入。 这个测试的目的就是要通过将动作限制在登录进程所包含的动
作中--查询、角色选择和更新帐户信息，来重现登录时的情况。
登录功能对一个随机产生的用户名进行查询。该用户名和测试数据库的 5
万个帐户里的某个用户名相匹配。用户的帐户对象随后被载入测试客户端，对象
被修改后，排队等候被写入服务器。一个角色的 LOID（逻辑对象标识）也会被
放入玩家的载入队列中，所以玩家的角色就能够被载入。这在在线系统中是非常
典型的操作。在这个例子中，没有玩家被实际载入，所以登录进程的带宽是可以
估算的。
启动一系列的测试客户端将负载加到客户端机器和数据库服务器上。 每个测
试客户端在每个样本周期都会执行 1000 次登录。每个客户端都会计算所有的登
录和所用的时间。可以用 Windows 任务管理器和 Linux 的“iostat”命令来记录
CPU 的利用率，通过测试客户端来计算吞吐量（登录次数/秒）。
登录测试结果
登录客户端的数量不断增加，直到客户端计算机的 CPU 的利用率达到 80%。
对于这个硬件配置，可以在客户端的机器上运行总共 8 个登录客户端。
Login Processing
5000
4000
Login/sec
3000
2000
1000
0
0 2 4 6 8 10
Clients
表 2：每秒钟登录数量
登录进程包括将每个帐户对象及登录事件产生的更新信息写回到数据库。没
有创建任何新的对象，但是本次测试中依然包括查询、读取和更新这些负载被加
到数据库上。因为写回到服务器上的数据量很少，所以本次测试主要是受到服务
器上 CPU 的限制。

6. Login Processing Server CPU
60
50
Server CPU%
40
30
20
10
0
0 1 2 3 4 5 6 7 8 9
Clients
表 3 数据库服务器上 CPU 的利用率
即使使用这样十分有限的硬件，也可以实现每秒钟 4000 多次登录。看看服
务器上 CPU 的使用情况，我们就可以看出到一个相当线形的响应曲线，并且只
使用了 50%服务器的 CPU。任何达到每秒钟 4000 次登录的游戏都将会是非常成
功的游戏，而一个单独的 Versant 数据库服务器可以支持这些登录次数或更多登
录次数。
游戏运行测试
游戏服务器运行测试包括一组玩家的动作，这些动作被连接在一起以模拟当
玩家游戏时，游戏服务器给数据库的负载压力。测试程序根据给定的玩家人数来
决定每一个动作以及玩家的一组动作的执行频率。在一个测试周期内，这些动作
被调用很多次。一分钟的测试周期被作为一个基准，但实际程序并不限定为一分
钟。实际上最终的测试在比一分钟短得多的时间内来完成相当于一分钟的数据库
工作量。这样做有利于在一个较短的时间内完成测试，并将其规格化以预测数据
库服务器能支持的全部负载。
动作的数量是根据玩家在一分钟游戏时间内执行动作的次数来估算的。因为
大多数游戏系统设计为每分钟将数据库和玩家状态同步一次，所以一分钟是一个
合理的测试基准周期。
在测试时，动作列表被不断执行并计时以计算系统的性能指标。下面的表格
描述了 250 个玩家在一分钟游戏时间内所执行的动作及其次数。测试的目的是通
过创建很大的数据库负载来增加数据库服务器的压力，因为正是因为这样，所以
应用程序是不受限制的并且测量时间比一分钟的目标要短得多。

7. 动作 次数/周期 描述
登录 1 随机的帐户查询，玩家检索
玩家载入 1 玩家的图片和物品被载入
金钱更新 500 玩家对象被更新：金钱，经验，位置
行会名册读取 2 行会，等级，成员载入
加入行会 1 玩家离开一个行会，加入另一个
创建物品 250 一个新物品对象被创建并放入物品栏
写入列表 1 将变化的对象写入数据库服务器
删除物品 200 玩家物品被删除
更新物品 500 物品被改变和更新
物品堆栈大小 500 物品的数量被改变（类似于更新）
完成探索 250 玩家的新探索对象被创建
朋友 25 玩家的朋友列表被改变
忽略 25 玩家的忽略列表被改变
玩家退出 1 玩家离开模拟
退出列表 1 退出对象被发送到数据库，并从内存释放
检查点 1 任何其它的新对象/脏对象被写入数据库
在测试程序中，通过修改表格可以调整这些动作的混合比例，以适合游戏服
务器的预期配置。这个负载的对象是 250 玩家-分钟的游戏时间。就是 250 个玩
家在测试“区”中执行一分钟时间的不同动作。 可以把它看成一个很大的测试区。
玩家被随机选取，以避免由于磁盘一起读写协同定位引起的性能偏差。
这个实验所使用的测试动作集在物品操纵上有很大的负载压力， 包括大量的
创建、删除以及对单纯现有物品的更新。可以认为，这些数量大致代表了实际上
超过 250 玩家分钟的游戏活动。这个配置在每个周期有效地更改 1000 个物品，
创建 250 个新物品。同时还在每个周期删除 200 个物品。
在动作表上列出的还有一些数据库专门的操作：写入列表，退出列表，和检
查点。这些动作被用来强制测试客户端把更改的或新建的对象推送到服务器。这
些调用引起网络和数据库的输入输出，占用了客户端的大部分时间。定期检查点
为服务器提供了一个在测试模拟中所有游戏对象的一致状态。当发生检查点时，
任何没有被其它操作显式写入的新对象或脏对象将被发送到数据库。这种模式不
断地将数据流传送到数据库服务器上。
退出列表动作对于客户端的内存管理很重要。当一个玩家离开模拟，这个退
出玩家的对象被从缓存刷新到数据库并将内存归还到堆。登录和玩家载入动作增
加一个新玩家以替代退出的玩家，使测试达到平衡。
游戏测试结果
该测试案例可以运行 1700 多个周期。收集到的计时信息可以用来制作出如
下的表。记住，因为目标负载量是每个周期 250 玩家分钟，所以这个负载代表的

8. 是 250 个玩家 29 个小时的游戏时间。幸运的是，实际上只需要 5 分多钟的时间
来进行测试。
250-player minute periods
4000
3500
3000
2500
Period mS
2000 Period
1500
1000
500
0
16:12:43 16:13:26 16:14:10 16:14:53 16:15:36 16:16:19 16:17:02 16:17:46 16:18:29
wall clock
表4 250 玩家-分钟负载计时样本
在运行的过程中，平均用了 176 毫秒就完成了一个测试周期，或者说一分钟
可以完成 340 个测试周期。目标负载量是一分钟，那么这样做会比实时动作快上
340 倍，这也代表了数据库服务器一般的负载量。
观察一下服务器的统计数字， iostat 显示 30%到 60%的磁盘利用率被用来“等
待”（等待磁盘命令的平均时间），“等待”时间为 3-50 毫秒。而在整个测试
的运行过程中 CPU 的使用率是 40%到 50%。
客户端看到的网络统计数字显示整个过程中使用了 2.5%的网络。同样，这
次在客户端和服务器之间仍然使用的是专门的 1GBit 以太网接口。
如图 4， 一些样本周期比平均的 176 毫秒要长一些，对此需要做出一些解
释。在这些周期里，数据库的服务器要经历一个内部的系统检查点。此时，事务
以及撤消日志被同步到数据卷中。 当一个或者两个日志文件被写满并且必须被清
除时，就会发生这个操作，这是正常的服务器操作的一部分。有些清除工作是在
服务器的后台线程中进行的，但对于一些象本次测试案例用到的那样很大的日
志，剩余的清除工作会花几秒钟的时间。
必须要记住的是，甚至这些周期也能够在几秒钟的时间内完成，并且负载代
表了一分钟的时间。实际操作中，游戏数据会被分散，作为游戏服务器的后台进
程发送出去，所以偶然出现的延迟永远不会被注意到。

9. 这次测试使用的是 64MB 逻辑（事务）和物理（撤消）日志文件。把日志文
件放在独立的磁盘轴上可以减少检查点的次数。 使用更快的磁盘子系统也会达到
同样效果，而增加日志的大小也可以减少检查站点的频率。调优后台刷新缓存的
操作使更多的日志在服务器检查点之前被写入，也会对性能有所改善。
双客户端操作测试
既然服务器和客户资源都没有实现完全饱和，那么另外一个测试程序就可以
在客户端机器上启动。两个测试客户端都使用了 250 个玩家的样本集，和一分钟
内的目标工作量负载。测试结果也与一个客户端测试的结果相类似。见表 5 和表
6 的样本时间。
两个客户端都显示，平均周期时间为 420 毫秒左右。客户端#1 平均周期时
间为 417 毫秒，客户端#2 平均周期时间为 424 毫秒。结果是大约每分钟 280 测
试周期，这要比单个用户端的每分钟 340 测试周期小一些。下降的原因是数据库
服务器上的磁盘的带宽已经饱和。
Client 1 Sample Times
6000
5000
4000
Sample mS
3000
2000
1000
0
16:27:50 16:29:17 16:30:43 16:32:10 16:33:36 16:35:02 16:36:29 16:37:55 16:39:22 16:40:48
wall clock
表 5 500 玩家—分钟负载的定时样本—客户端#1
仔细观察服务器上的 iostat，我们会发现数据库服务器出现检查点时磁盘访
问出现了饱和状态。 磁盘饱和说明在磁盘控制器上会出现更长久的 “等待”时间。
有了两个用户端， 正常周期的等待时长可以从 10 毫秒到 200 毫秒，但是在系
统检查点时会达到 700 毫秒。“等待”时间延长，服务器检查点频率加大会使
整个服务器速度变慢。这个事实证明了使用低成本磁盘子系统的局限性。在这次
测试中服务器 CPU 的利用率达到 65%到 75%，这进一步证明了是磁盘出现了饱
和，而不是处理器的带宽达到了极限。
很明显，这次测试达到了数据库服务器磁盘子系统的极限。

10. Client 2 Sample Times
6000
5000
4000
Sample mS
3000
2000
1000
0
16:27:50 16:29:17 16:30:43 16:32:10 16:33:36 16:35:02 16:36:29 16:37:55 16:39:22 16:40:48 16:42:14
wall clock
表6 500 玩家—分钟负载的定时样本—客户端#2
两个客户端显示了相似的时间和行为。 周期更长还是因为数据库检查点的操
作。记住，数据库服务器支持 500 玩家—分钟的负载，并且平均的周期不到 425
毫秒。
结论
这些测试显示的持续运行速度是用来支持 250 个玩家的活动所需要的
280-340 倍。在真正的游戏服务器上，每个模拟区都会在更长的时间内以更小的
批量发送和要求玩家的数据。这样，数据库就可以为更多的游戏服务器客户端提
供服务，整个网络，磁盘和服务器的 CPU 就会和这里所展示的非限速模式测试
中的相类似。使用规格化数据和一个玩家-分钟负载的假设，这些测试表明一个
单独的 Versant 服务器可以支持 70，000 到 85，000 个这种玩家配置的在线玩家。
必须承认的是，需要增大数据库服务器的内存来恰当地缓存玩家对象，以达到这
样的性能，但是内存的成本是很小的。
根据假定的玩家活动运行假定的负载测试仅仅是一个开始， 但是这却能够让
人们更好得了解到游戏的技术性细节对于系统性能的影响。还原玩家动作对于测
试游戏系统中一些意想不到的行为或者设计缺陷的很有效。这样，游戏设计者就
可尽早的得到关于所需硬件、数据库负载以及游戏设计影响的反馈信息。然后，
随着游戏的更新，更好的玩家配置可以优化游戏模型。利用 Versant 可能轻松地
改变游戏的对象模型，这进一步推动了持久化模型的尽早测试。可以用本文所提
到的测试系统来评估模型变化所带来的影响。
Versant 可以高效地传送对象，对服务器对象进行高速缓存，所以 Versant
对象数据库是适合高性能模拟和计算需求的独一无二的选择。

11. 附件 A—样本数据
该样本数据显示了一小部分从单个 250 个玩家测试客户端上收集来的计时
数据。正如正文的用例概述中所定义的那样，每个样本都代表了 250 玩家分钟的
工作量。这个测试程序每 100 个周期就会打印出一份动作总结。以下是一份这样
的总结。
16:13:19 T_last = 109ms
16:13:19 T_last = 113ms
16:13:19 T_last = 126ms
16:13:20 T_last = 145ms
16:13:20 T_last = 301ms
16:13:20 T_last = 118ms
16:13:20 T_last = 120ms
16:13:20 T_last = 113ms
16:13:20 T_last = 120ms
16:13:20 T_last = 121ms
16:13:21 T_last = 416ms
16:13:21 T_last = 115ms
16:13:21 T_last = 248ms
16:13:21 T_last = 115ms
16:13:21 T_last = 112ms
16:13:22 T_last = 111ms
16:13:22 T_last = 114ms
16:13:22 T_last = 116ms
16:13:22 T_last = 118ms
16:13:22 T_last = 113ms
16:13:22 T_last = 116ms
16:13:22 T_last = 120ms
16:13:22 T_last = 113ms
16:13:22 T_last = 111ms
NAME C/per CALLS T.Time TT/calls mean Tn ms Tn-1 ms
Login 1 100 2mS 0.02 0.03 0.01 0.01
LoadPlayer 1 100 255mS 2.55 2.56 2.33 2.42
MoneyUpdate 500 50000 202mS 0.00 0.01 0.00 0.00
GuildRoster 2 200 5012mS 25.06 25.08 17.97 18.72
Join Guild 1 100 738mS 7.38 7.39 1.24 1.15
CreateItem 250 25000 263mS 0.01 0.02 0.01 0.01
WriteList 1 100 2433mS 24.33 24.34 9.81 9.79
DeleteItem 200 20000 181mS 0.01 0.01 0.01 0.01
UpdateItem 500 50000 182mS 0.00 0.01 0.00 0.00
ItemStkSize 500 50000 180mS 0.00 0.00 0.00 0.00
EjectList 1 100 4394mS 43.94 43.95 194.35 28.31
CompleQuest 250 25000 1424mS 0.06 0.68 0.00 0.01
Friend 25 2500 7mS 0.00 0.00 0.00 0.00
Ignore 25 2500 9mS 0.00 0.00 0.00 0.00
EjectPlayer 1 3 0mS 0.03 0.03 0.03 0.03
EjectList 1 100 38mS 0.39 0.39 0.00 0.00
ChkPt 1 100 6344mS 63.44 63.45 16.47 15.58
Tmean tn tn-1
379.17 270.32 105.60
Periods= 100 Players= 100 Items =10970 GuildLoaded= 200
TotalTime=21.66S avg Tau= 216 mS Logins/sec=4.62 Player/sec=4.62
16:13:23 T_last = 279ms
16:13:23 T_last = 111ms
16:13:23 T_last = 112ms
16:13:23 T_last = 153ms
16:13:23 T_last = 116ms
16:13:23 T_last = 131ms