Cnzw 发表于 2024-5-26 13:53:06

服务器配置文件优化 —— 让测试数据来说话吧!TPS最高提升100% (CPS)

本帖最后由 Cnzw 于 2024-5-26 13:56 编辑


[*]原作者:EmptyLava(本文已获得原作者转载授权)
[*]原文地址:https://www.mcbbs.com/thread-1082459-1-1.html
[*]镜像地址:https://bbs-archive.github.io/thread.html?t=1082459
[*]最后更新时间:2021-2-19


@Cnzw
因XF不支持上标注释(tooltip)省略了所有上标注释。
优化了部分文案和格式。
因本论坛不支持折叠标签(),故做保留方便读者识别哪些是折叠内容。

前言

[*]这篇教程的意义?
目前站内的100%关于配置文件的优化教程,大多都是凭借前人经验与个人感觉,而实际的优化效果可能欠佳,不但优化效果差,还会严重影响玩家体验。而本篇教程就是为了在配置文件中找出最有效的配置项,以及最佳优化效果时的数值,并结合形成整个配置文件。
[*]你的测试数据怎么让我们信服?
我们每次测试都会记录下测试数据,然后公布在腾讯文档上(以后可能会发布在pastebin上),每一次测试都可以寻找到spark链接和当时的TPS/Chunks/Entities/Tiles,不可能出现造假的情况,同时我们会尽量减小测试的误差。
[*]测试平台是?
Windows Server 2016 / Intel Xeon E5 2689 2 Cores / 6GB
服务器进程的内存分配为4000M
启动参数为 java -jar -Xmx4000M -Xms4000M server-1618.jar
服务器版本在测试时会有说明,大部分为1.12/1.13,也有1.13/1.14内容 服务器种子为114514(防止地图建筑等对 测试的影响)
其他参数如未说明,均为默认参数
数据采样使用Spark,仅一次使用Timings
[*]为什么不用Timings?你是不是歧视它不好用?
对,就是不好用
①由于核心为Paper,Timings的数据收集至少需要3分钟,这给测试带来了许多不便
②Timings在对照条件下根本就没!法!用!随随便便生成的Timings报告都有400%的tick,肯定是不符实际的,我怎么知道它是正确的还是错误的呢
当然,极少数情况我们也可能会选择Timings
[*]我服务器是1.7.10/1.13+的,看你的这篇教程有用吗?
对于1.7.10,您可以大胆参考,不需要有任何担心
对于1.13+,测试内的Chunks/Entities/Tiles是不会变的,变的只是TPS和优化效果,而优化效果看的是被测事物本身,比如我要测服务器内100区块和200区块的占用情况如何,优化效果的多少在1.12和1.13+是接近的,即使单个区块的占用变了,优化效果也不会变化多少。并且我们也对1.13+的内容进行了测试,让数据更加准确。
[*]其他
在鸽(zuo)了在鸽(zuo)了,具体进度请查看腾讯文档,本教程比腾讯文档晚更新
结论的表格中的“综合提升”有一定参考价值,在实际生产环境中的提升效果会有一定折扣(除非服务器没有插件占用),‘针对提升’是针对某些单一方面的(看针对提升的效果时,请注意这个配置项测的是什么),同时针对提升一般反映的是这项配置的最大优化能力,请勿把针对提升当做此配置的真实优化水平!
由于某些原因,我不可能会去多次测试取平均值,所以测试结果会有一定误差(但是误差会在可接受范围内)


Server.properties
适用服务端:所有

1. View-distance
(Test ID:2-7) (服务器允许的最大视野距离,单位:区块数,默认=10,低于9的数值还会减少刷怪量)
测试内容:
    ①玩家移动800格的服务器状况(有区块回收)
    ①玩家在出生点时,不同数值时的服务器状况
    附加参数:
       ①在bukkit.yml/paper.yml内,并且将区块加载速度设置为1000000(实际测试中,由于网络问题,区块加载速度约50~85块/秒)[仅测试①需要]
       ②还需要设置spigot.yml内的view-distance,因为spigot.yml优先于server.properties[仅1.13-需要,后面的spigot.yml中view-distance默认为default,即根据server.properties]

①:

View-distance数值Thread.sleep(越大越好)TPS/Chunks/Entities/Tilesdoticktickentity综合提升|针对提升
1091.68%19.98/1491/296/262.82%2.26%         ------
892.55%19.97/952/257/142.33%2.25%10.50%|17.58%
693.62%19.97/913/265/111.87%1.64%23.31%|23.84%
494.72%19.97/703/233/111.11%1.34%36.50%|36.78%
394.32%19.95/611/116/81.25%1.32%31.70%|46.00%

②:

View-distance数值SleepForTick(越高越好)TPS/Chunks/Entities/Tiles/mspttickentityChunkProviderTick综合提升
878.02%20.00/529/111/16/7.89.23%7.34%---
683.38%20.00/289/111/11/5.88.52%3.10%25.02%
487.76%20.00/169/105/7/5.76.77%1.48%35.62%
386.04%20.00/121/111/5/5.68.34%1.40%37.85%
1279.93%20.00/841/149/19/8.58.20%8.33%-8.83%
1676.24%20.00/1369/252/28/10.68.88%10.50%-21.99%

测试时可能碰到了一个特性:
在1.13-的服务器内区块加载规则是加载玩家周围的[(2n+1)^2]个区块(n=view-distance数值),这个和一般对view-distance的解释是吻合的。但是在1.14的区块加载数变为了[(2n+3)^2],1.15变成了[(2n+5)]^2。
这显然和之前的机制不同,个人猜测外围多加载的区块可能是"缓冲区",跑过去才会接收到区块,但是不算新加载的区块,这种机制可能是用来降低TPS的波动。因此在1.14或更高版本的服务器中要格外注意这一部分额外加载的区块,你完全可以比1.12的推荐数值小1~2。
在view-distance=3~5时,优化效果最佳且玩家体验较好。
同时在测试的时候发现,当view-distance设置为2时,是可以看到3视距的,说明最低只能是3,再往低就没有意义了。


Bukkit.yml
适用服务端:Bukkit,CraftBukkit,Spigot,Mohist,Paper,Catserver等基于Bukkit的服务端

1. ticks-per
(Test ID:15-19|126-130)(多少tick执行一次事件,spawn的事件是生物的生成;autosave是世界保存,默认值animal-spawns[动物]=400 monster-spawns[怪物]=1 water-animal-spawns[水生动物/1.16+]=1 water-ambient-spawns[水下环境生物/1.15+]=1 ambient-spawns[环境生物/1.15+]=1 autosave=6000)
这项配置只测试ticks.per-monster-spawns,其他数值和monster-spawn大同小异,且刷新数量较少,不进行测试。autosave测试结果不精准,同样不测试
测试内容:
    ①不同ticks-per.monster-spawns数值时,玩家在出生点以16的视野距离挂机60秒后的服务器状况
    ②不同ticks-per.autosave数值时,世界保存的占用
    ①不同ticks-per.water/amibient-spawns数值时,玩家在出生点以8的视野距离挂机60秒后的服务器状况
   附加参数:
      ①禁用区块回收
      ②View-distance=16
      ③不限制bukkit.yml内的spawn-limits(此配置项会限制玩家周围的最大刷怪量,因此测试时需取消限制)

①:

Monster-spawns数值Thread.sleep(越高越好)TPS/Chunks/Entities/Tilesdoticktickentity针对提升
126.85%15.90/1089/5110/115.10%61.91%---
373.92%19.59/1223/1785/113.32%17.98%23.70%
576.73%20.00/1089/1248/114.45%14.34%25.61%
1083.38%19.87/1089/605/113.69%8.69%28.99%
3088.15%19.90/1089/247/113.61%4.86%30.71%

②:

ticks-per.autosave数值Thread.sleep(越高越好)TPS/Chunks/Entities/Tiles世界保存占用针对提升
6000(default)92.04%19.97/1089/66/130.69%---
1200092.62%19.96/1089/63/130.46%33.33%
2400093.02%19.96/1089/63/130.47%31.99%
240092.97%19.85/1089/65/130.62%10.15%
60093.74%19.98/1089/66/130.55%20.29%

③:

water/ambient-spawns数值SleepForTick(越高越好)TPS/Chunks/Entities/Tiles/mspttickentity针对提升
10.00%11.71/529/2588/16/82.677.56%---
351.29%20.00/529/1103/16/30.835.39%20.90%
562.93%20.00/529/537/16/22.825.60%24.13%
1079.16%20.00/529/365/16/14.312.83%27.56%
3089.63%20.00/529/125/16/7.73.09%30.22%


结论
在限制spawn-limits.monsters后,服务器的实体数量在300~500左右,不会更高。monster-spawns=1时服务器异常卡顿,继续测试可能会崩溃,在设置为3以上后,TPS回升很多,但是entities依然可怕。
ticks-per.autosave在表格中看似有一点优化效果,但这一点点(1玩家+1300chunks+200实体情况下降低了0.2%的tick,自己服务器可类比)的意义太小了,还可能导致服务器在意外崩服时回档时间更长。
建议
如果您不对bukkit.yml--spawn-limits或spigot.yml--mob-spawn-range进行修改,ticks-per内的生物生成配置在玩家不加载区块时,修改它可能没什么影响。如果玩家有跑图的行为,服务器内的刷怪量可能是可怕的(1000区块有1500实体+),因此推荐water-animal-spawns,water-ambient-spawns。ambient-spawns至少设置为40/80,如果觉得这三种生物还是刷得多,还可以直接设置为与animal-spawns相同数值。monster-spawns推荐直接修改为10~200的数值(根据服务器情况,低于5的数值几乎没有意义)。animal-spawns可选择修改,默认值足够高了,设置为默认值的2~3倍也可。
ticks-per.autosave推荐最多设置为12000(10分钟),超过这个数值会让服务器异常关闭时回档严重,而且测试的时候也没有见到提升这个数值能显著减少自动保存占用。


2. spawn-limits
(Test ID:20-24|144-148)(每个玩家在所在世界中能刷出多少怪物,默认:monsters:70 animals:15/10 water-animals:5/10 ambient:15 water-ambient=20)

猜想①:与视野距离有关
   猜想②:与玩家数有关
   猜想③:与加载的区块量有关
   
①和②很好测试,①是错的,②是正确的,
猜想③在测试过程中发现会受到被卸载的区块中实体的干扰,而且这一部分实体无法被kill,也不会计入服务器实体的数据中。因此在测试中,禁止区块回收并使用循环命令/tp @p ~ ~ ~-1 将玩家平移2000格后,会到起点并kill所有实体,并重复循环命令移动2000格。
结果:
【图片丢失】
因此,在跑图的时候,服务器内的实体满足这个公式(这个似乎是bukkit官方给的,海螺也说是这个公式,只不过图中的256应该为289)
【图片丢失】

结论(spawn-limits的解释):
①当已被卸载的区块加载时,满足 生物≤spawn-limits内对应数值*(当前世界区块数/289)
②当已被卸载的区块加载时,满足 总实体≤spawn-limits内各数值之和*(当前世界区块数/289)

此外我们还发现了一个离谱的现象[仅1.13或更低版本]:
只要所在区块被kill @e或killall了,短期情况(也许是几小时,也许....是永久)下实体不可能恢复原样,随后经过排除,我们发现是spigot.yml内的mob-spawn-range影响的,默认值为4,导致刷怪量大大减少
所以,你的服务器刷怪少也许是因为mob-spawn-range导致的

测试内容:
   ①:参数不同时玩家在出生点的时候服务器状况
   ②:参数不同时玩家在出生点的时候服务器状况
   附加参数:
      ①View-distance=16
      ②需要在spigot.yml内设置mob-spawn-range为等同于视野距离的数值,否则会影响此参数的效果导致不刷怪
      ③测试时spawn-limits的默认值为正常的10倍,模拟10人时的情况

①:

该参数的倍率Thread.sleep(越高越好)TPS/Chunks/Entities/Tilesdoticktickentity针对提升
1037.97%19.93/1378/812/524.35%55.29%---
203.61%19.01/1378/1635/524.76%86.81%-57.00%
400.65%11.82/1378/2935/523.34%93.48%-69.07%
566.63%20.00/1378/475/523.34%28.04%50.71%
280.32%20.00/1378/188/524.20%13.71%75.21%

②:

该参数的倍率SleepForTick(越高越好)TPS/Chunks/Entities/Tilesdoticktickentity针对提升
1018.55%19.83/497/1073/16/37.173.26%60.09%---
200.00%14.22/304/2037/14/59.192.97%81.17%-70.16%
400.00%6.54/309/4014/14/131.994.07%84.70%-81.90%
556.21%20.00/399/533/16/20.840.31%31.75%47.17%
279.27%20.00/396/221/15/10.217.27%12.05%79.95%

当服务器为10人左右时,将此配置项设置为原来的一半(即35/7/3/7)最多可以降低50%的实体数量,降低为原来的1/5可能会引起玩家的愤怒(平均每个人周围只有19实体.这会导致玩家周围基本不刷怪),如果你的服务器内玩家超勇,并且你用了较好的CPU,设置为原来的1.5~2倍,然后提升monster-spawns的数值,也不会影响多少TPS。

因此,推荐您将各数值设置为原来的30%至原来的75%。[推荐1.14+的版本降低的更多,经测试,1.15.2中500区块平均会产生一千多个实体]


3. chunk-gc
(Test ID:33-36)
chunk-gc.period-in-ticks (多少tick回收一次区块,默认值=600,即30秒。修改此项同时也要修改paper.yml内的delay-chunk-unloads-by,或者禁用其中一项)
chunk-gc.load-threshold (两次区块回收之间,需要加载多少区块才能进行下一次区块回收,默认=0)
这两项数值不会影响很多性能
这是测试chunk-gc.period-in-ticks在不同情况下的性能占用:

(耗时1h)
①:在出生点时,不加载额外区块,区块回收占用
②:匀速移动200格后,区块回收占用

chunk-gc.period-in-ticksThread.sleepprocessChunkGC
600-①92.33%0
600-②49.10%0
1-①90.85%0.80%
1-②60.28%1.05%

默认值时,区块回收占用几乎为0(实际情况是根本找不到区块回收这一项,应该是小于0.01%,采样时间是60s,不可能没记录到),设置为1时,玩家禁止时候区块回收占用略高(0.80%,移动时虽然区块回收占用有1.05%,但是加快了服务器内区块回收,及时减少了区块回收的数量,能挽回区块回收带来的占用亏损,甚至还赚了一些。
但是我们不建议您设置为1,如此频繁的区块回收在服务器玩家过多,区块数量很多时(如大于5000),区块回收占用就很可怕了,因此建议您设置的数值不要低于100。


Spigot.yml
适用服务端:Spigot Paper Mohist Catserver等

1. Mob-spawn-range
(Test ID:25-32)(以玩家为中心的半径多少区块内可以刷怪,默认1.12-=4,1.13+默认值=8)
⚠️数值设置大于9,也不会在9区块外刷怪,因为原版刷怪机制为:生物离玩家最多128格,否则刷出的怪物将被删除
⚠️数值低于8时,服务器内刷怪量低于或远低于正常刷怪量[仅1.13或更低版本]
在1.13或更低版本的服务器上,较低的数值会导致刷怪量急剧减少,这是因为bukkit.yml内的spawn-limits限制了平均一个区块内能生成多少生物,而mob-spawn-range会阻止较远的区块生成怪物,两项配置的共同作用使得刷怪数量远低于正常水平
测试内容:
   ①修改mob-spawn-range,bukkit内spawn-limits为原来的3倍时候,服务器内生物刷新的状况
   附加参数:
      ①view-distance=16



mob-spawn-range数值Thread.sleep(越高越好)TPS/Chunks/Entities/Tilesdoticktickentity针对提升
490.92%19.97/1089/25/95.04%1.64%---
590.63%20.00/1089/39/94.87%1.51%5.56%
690.19%19.97/1089/59/94.59%2.33%-25.05%
889.94%19.96/1089/93/94.69%2.41%-29.23%
1090.28%19.97/1089/99/94.53%2.02%-15.10%
391.02%19.93/1089/17/94.68%1.35%8.34%
290.69%19.88/1089/8/95.03%1.15%16.20%
190.03%19.99/1089/3/95.82%1.37%13.13%

在1.14或高版本的服务器上,mob-spawn-range的作用类似bukkit.yml中的生物生成配置,测试时设置为3的刷怪速度只有设置为8刷怪速度的10%左右,不过不会影响刷怪量
不过为了配合ticks-per,推荐将这项数值修改为3~4
在1.14以下版本的服务器上
mob-spawn-range会使刷怪量大幅减少
将mob-spawn-range设置为9以上,每名玩家大约会额外降低至少1%的服务器线程睡眠占比
将mob-spawn-range设置为1,还是能见到刷怪,但已经很少了
如果您真切需要这0.5%的占用(换算成事件耗时的话最多为5%,这5%是真实的优化),或者您的服务器内玩家很多,此项配置可改为3(但是较低的mob-spawn-range数值会导致刷怪塔的性能不能被完全榨干)
如果您想让您的服务器回归bukkit/原版刷怪机制,修改到8或10也是一个不错选择,而且带来的服务器负担也不是很多(0.8%,换算为事件耗时约为8%)


2. entity-activation-range
(Test ID:37-42)(以玩家为中心,生物距离玩家多少格内才被激活/每秒被激活的数量限制,默认值在下方,已折叠)


entity-activation-range:
      #1.15新增,设置对村民的飞行怪物的激活范围
      villagers: 32
      flying-monsters: 32
      #1.15新增,设置工作的村民的激活范围
      villagers-work-immunity-after: 100
      villagers-work-immunity-for: 20
      villagers-active-for-panic: true
      #1.14新增,设置对袭击怪物的激活范围
      raiders: 32
      #设置为动物/怪物/掉落物/水流的激活范围
      animals: 32
      monsters: 32
      misc: 16
      water: 16
      #1.14新增,和不活跃村民有关,具体意义不明
      tick-inactive-villagers: true
      #1.14新增,设置对生物被激活的速度限制
      wake-up-inactive:
      animals-max-per-tick: 4
      animals-every: 1200
      animals-for: 100
      monsters-max-per-tick: 8
      monsters-every: 400
      monsters-for: 100
      villagers-max-per-tick: 4
      villagers-every: 600
      villagers-for: 100
      flying-monsters-max-per-tick: 8
      flying-monsters-every: 200
      flying-monsters-for: 100


测试内容:
    ①不同entity-activation-range.monsters数值时,玩家绕500只分散的僵尸移动时,服务器占用
    附加参数:
       ①:禁用区块回收
       ②:将paper.yml内的despawn-ranges.soft设置为128(否则服务器内的怪物会被缓慢删除,影响测试效果)
       ③:view-distance=16



entity-activation-range.monsters数值Thread.sleep(越高越好)TPS/Chunks/Entities/TilestickentityEntityZombie针对提升
3282.96%19.99/1513/501/212.66%7.02%---
2884.95%19.96/1513/501/212.67%5.40%17.38%
2485.40%19.96/1513/502/212.66%4.95%21.90%
2087.70%19.96/1513/501/212.73%3.82%36.70%
1688.34%19.98/1514/500/212.44%3.09%44.78%
1289.50%19.97/1514/499/213.39%2.62%50.53%


当entity-activation-range.monsters为默认值一半的时候,怪物的耗时降低了一半多,但是16这个数值对于玩家是几乎无法游玩的(看到的怪物大多都没有激活,玩家没有游戏体验),设置到24的时候,怪物的占用也有30%的降幅。
而animals/villagers等其他配置的优化效果和monsters是一样的,可以根据表格内的优化效果修改,且动物对于玩家的影响不大,改为12也没什么关系。
村民被激活时的寻路AI占用了大量的tick。
flying-monsters貌似仅仅是指幻翼。
misc是指掉落物,如果你的服务器内有很多生成掉落物的机器(如:用岩浆块杀死怪物的刷怪塔,地毯机,0t机器),可以适当降低此项,但不能设置为1或更低,否则会出现实体无法捡起等一系列奇妙的bug
water这一项此项还是不动最好。
wake-up-inactive的修改意义不大,大型服务器可能还要增加这些数值
因此,如果您的服务器是养老生存服,且大型机械非常多,玩家又喜欢养动物,可以设置为viilagers:16 flying-monsters:18~24 monsters: 18~24animals: 8~12 misc:2~4 water:16wake-up-inactive设置为原来的50%
如果您的服务器是RPG服,这几项只能微调。
注意:过低的monsters数值会导致刷怪塔效率降低,甚至不工作!(经过测试,monsters的数值是指怪物与玩家的水平距离,与竖直距离无关)


3. max-tick-time
(Test ID:48-52)(在服务器的两个tick之间,实体/方块实体最多允许被计算多长时间,单位毫秒,默认tile:50,entity:50)
默认数值已经足够了,如果你的服务器实体/方块实体占用极高,降低这两项数值可能会有显著的提升。如果实体/方块实体占用不高如果设置太低,实体/方块实体会跳过计算,可能会导致玩家体验下降/漏斗分类机堵塞之类的bug。
测试内容:
①使用Spigot核心(因为paper禁用此项),在不同max-tick-time.entity数值的情况下,1400只实体的占用,以及玩家怪物计算被跳过的情况
(由于tile很难达到50ms/tick,因此不测试max-tick-time.tile,且max-tick-time.entity的规律适用于tile)
附加参数:
   ①View-distance=16
   ②/gamerule doMobSpawning false(禁止生物自然生成)
   ③使用timings v1进行数据收集,而不是spark(spark对于低tps时的采样效果不好)


max-tick-time-entity数值Full Server TickTPS/Chunks/Entities/Tilestickentity实体计算被跳过状况针对提升
50109.38%16.92/1127/1437/25100.75%中等---
4090.71%19.95/1123/1435/2580.81%中等最高20%
3070.97%19.88/1123/1431/2560.83%中等最高40%
1538.83%19.92/1123/1430/2530.65%严重最高70%
518.17%19.92/1123/1411/2510.72%极为严重最高90%

max-tick-time.tile同理
针对提升中的“最高”指的是当服务器内实体/方块实体达到100% tick占用时(即50ms 达到了默认值的阈值),但是大多数服务器都无法达到这个数值,所以您需要使用Timings进行采样(输入/timings on 三分钟后输入/timings paste),然后在输出结果的网页内内找到"tickentity"一项的Pct Tick

如果max-tick-time没有修改过,您又需要优化,您可以将max-tick-time.entity修改为,大约会带来10%的实体占用下降
如果您修改过max-tick-time,且tickentity占用(%)*50≈max-tick-time.entity,就不建议再改了
max-tick-time.tile与max-tick-time.entity同理,只是tile的占用=每一种tile占用的总和,需要自己计算
注意事项:
①此配置项在paper上不生效(已经在paper.yml找过了,没有启用这个配置项的选项,在paper上的数据请看腾讯文档内Test ID:43-47),这好像是Paper官方自己禁用的


PaperSpigot does not offers "max-tick-time"
PaperSpigot 不支持max-tick-time

②降低此项可能会给服务器带来不稳定,特别是RPG服务器,如数据不同步等,但是它带来的优化效果真的很可观


There’s a reason PaperSpigot doesn’t offer it: You shouldn’t use it! That system is fundamentally broken in implementation and can cause inconsistencies with your server.
这就是PaperSpigot不支持它的原因,你就不应该用它!它从源头上破坏了服务器的正常运转,导致了服务器的不同步

翻译自https://aikar.co/2015/10/08/spig ... -use-max-tick-time/ 注:aikar是paperspigot的维护者之一


4. ticks-per
(Test ID:53-58)(漏斗多少tick传输一次,多少tick检查一次,默认hopper-transfer: 8 hopper-check:1)
   hopper-amount(漏斗一次传输几个,默认值为1,此项不影响性能,但是会影响效率)
测试内容:
   ①100个漏斗传输物品时,不同数值下(这三个数值的1倍,2倍,3倍,4倍,5倍),漏斗的占用
其他参数:
   ①/gamerule doMobSpawning false(禁止生物生成,因为测试的时候动用了summon命令生成怪物来生成掉落物)
   ②使用spigot核心

①:
(8,1,1代表hopper-transfer: 8 hopper-check: 1 hopper-amount:1)

各数值倍率Thread.sleep(越高越好)TileEntityHopper针对提升
1x(8,1,1)-传输时95.68%1.07%---
2x(16,2,2)-传输时95.23%0.96%10.29%
3x(24,3,3)-传输时95.68%0.85%20.57%
4x(32,4,4)-传输时96.19%0.67%37.39%
5x(40,5,5)-传输时96.45%0.64%40.19%
1x(8,1,1)-不传输时96.37%0.48%---

不修改数值时,大约每个漏斗会占用0.01%(0.005ms)的服务器tick,但是多个漏斗叠加的占用还是挺多的(一般用到漏斗的大型机器有1000+个,差不多就要占用10%tick了)。按照站内一些教程给的推荐数值(3x;24,3,3), 大概只能降低20%的漏斗tick,属实没劲,即使这个数值设置到全站给过的最高数值(5x;40,5,5),也只能降低40%占用,这是因为Tile与Entity不同,Entity由于受到entity-activation-range的限制,不工作的实体占用几乎为0。而Tile时刻都有一定计算,在不工作的情况(见表格第六行)也有一定的占用。
同时,修改了ticks-per和hopper-amount后,物品每次传输间隔时间和数量都修改了,许多和漏斗有关的机器都可能出现Bug,如抽.奖机,分拣机。hopper-check大于1可能还会导致物品复制的小bug,为了减少或防止这种不同步,hopper-transfer数值最好要是hopper-check的倍数。
因此,对于生存服,如果服务器内的漏斗很多,那还是建议设置为(16,4,2 hopper-check也占用了一定性能,所以多提升了一些),如果漏斗占用不高,只建议更改hopper-check
对于RPG服,且又需要漏斗的,可以考虑直接改为(1,4,32),这样漏斗传输速度很快,传输时间变短,占用会下降很多。
对于Mod服,修改为5x~10x即可。


5. max-tnt-per-tick
(Test ID:122-125)(每个tick最多计算多少个tnt,默认=100)
测试内容:
   ①不同数值时5000余个TNT爆炸时,服务器的状况以及TNT的占用
   ②不同数值时2000余个TNT爆炸时,服务器的状况以及TNT的占用
   附加参数:
   ①view-distance: 16


max-tnt-per-tick数值Thread.sleep(越高越好)TPS/Chunks/Entities/TilestickentityTNT占用针对提升
1001.43%10.96/1094/118/142.55%81.77%---
2033.64%19.87/1089/3904/132.76%59.66%27.04%
560.76%19.34/1089/4766/133.27%29.49%64.94%
183.45%19.84/1089/3728/132.29%10.27%87.45%


max-tnt-per-tick数值Thread.sleep(越高越好)TPS/Chunks/Entities/Tiles/mspttickentityTNT占用针对提升
10052.11%20.00/529/110/16/32.219.54%13.71%---
2066.71%20.00/529/1612/16/15.116.13%9.80%28.52%
576.97%20.00/529/1367/16/10.611.73%3.67%73.34%
179.41%20.00/529/1794/16/9.78.71%1.67%87.82%

在max-tnt-per-tick为默认值时,爆破5000余个TNT时,TPS降低较多,仅能保持9~10,但是TNT的处理速度很快,15秒不到的样子。在max-tnt-per-tick设置到20后,能明显看见了TNT计算滞后,处理很慢。同时实体积压,60秒后还有4000多个实体(已被点燃的TNT)待处理。设置为5和1时,TNT的爆炸处理明显缓慢,周围TNT甚至出现了没有被激活的情况,到最后还有一部分TNT没有被引爆,这样会导致许多需要TNT的大型机器威力下降甚至炸膛(少量TNT复制机器不受影响),这也明显减弱了熊孩子放置大量TNT的威力。
对于任何服务器,设置为20即可(也可设置为10),高于这个数值的优化效果较差,低于这个数值会导致TNT计算滞后。
对于一些正在用TNT清理区块的服务器,可以临时恢复为100。


Paper.yml
适用服务端:Paper

1. world-settings.max-chunk-gens-per-tick(每个世界中每tick最多生成多少区块,默认=10)
world-settings.max-auto-save-chunks-per-tick(每个世界中保存地图时,每tick最多保存多少区块,默认=24)
world-settings.max-chunk-sends-per-tick(每个世界中每tick最多发送多少区块,默认=81)

注:生成≠发送,生成这里指的是从未被加载过的区块,发送指的是已经加载过的区块
这三个配置项放在一起的原因:
    ①它们的功能都相似
    ②它们对于服务器的优化效果不是很明显(除非服务器玩家跑的比香港记者还快/网速感人),但是这三项数值对于提升服务器的稳定性(可以让tps更平滑,减少跑图/世界保存带来的突发tps降低)
    测试内容:
      ①不同数值时,5倍移动速度平稳加载新区块时,服务器tps和CPU占用
    附加参数:
      ①view-distance=16

①:由于world-settings.max-auto-save-chunks-per-tick优化效果很小,且这个数值不会影响性能,所以没放入测试(主要是测不出,强行测的话误差大)

max-chunk-sends/gens-per-tick数值Thread.sleep(越高越好)TPS/Chunks/Entities/TilesdotickCPU占用针对提升
默认值(81,10)0%18.89/992/227/1980.66%84%---
20%20.00/1043/310/3481.60%80%4.80%
171.51%20.00/599/160/923.45%46%45.24%

虽然看着提升很大,但实际肯定不能这样用
①测试的时候是飞行5倍速,速度为54m/s,那么每秒可以移动3.375个区块,同时视野距离为16,那么玩家每移动一个区块就会加载36区块(不考虑斜向)、这样的话每秒就会加载121.5个区块,不考虑网络的情况下(实际上网络没满),max-chunk-sends/gens-per-tick都设置为1时,有80%+的区块被跳过加载了。正常的玩家疾跑速度是5.612m/s,换算下来在16视野距离时,每秒需要加载12.6个区块,如果是-80%的区块(区块只能加载到最大值的20%)加载折扣肯定让玩家无法接受,因此推荐平均每个玩家只能加载到最大值的70%,也就是8.5区块每秒,对应的max-chunk-sends/gens-per-tick就是0.425(当然,max-chunk-gens-per-tick可以更低,如0.35)。
②这是一个世界性选项,作用在整个世界上,而一个世界又有很多玩家,我测试的时候是独自一人的,所以最终数值要乘以服务器玩家。
③玩家加入的时候,会满速加载区块,大概3~5秒就要加载400~1000区块。为了防止这样的突发事件,还要增加max-chunk-sends/gens-per-tick数值

综上所述,max-chunk-sends/gens-per-tick的设置公式={*S/320*P}*0.7+5
                V=view-distance数值
                S=玩家疾跑时的速度,默认=5.612。如果你的服务器玩家普遍加速,这个数值还要上升
                P=服务器内玩家最多的那个世界的平均活跃人数(需要减去挂机人数,这一部分人不加载区块,只要不是核心跑图玩家就都建议去掉)
最终数值一定要取整(取上取下自由选择),同时max-chunk-gens-per-tick可以适当降低

如:某世界平均活跃玩家为30的服务器,view-distance=12,玩家各个拿着+100%移速的屠龙宝刀
数值就应该设置为26*11.224/320*30*0.7+5=24.11,取整后为24
这样每秒最多加载480格区块,平均每个玩家分到16区块;1名玩家正在进入服务器时,每名玩家也能分到12区块。既能保证玩家不流失体验,又可以略降服务器占用(如果服务器玩家频繁进出,效果会更好)


2. Timings.enabled
(Test ID:64-71)(是否开启timings,默认=true)
Timings是一个服务器分析工具,虽然很轻量,但仍然会有一定占用,服务器不会每时每刻都用Timings。
测试内容:
   ①在服务器的不同占用情况下(即每秒tick数不同时),co.aikar.timings.FullserverTickHandler.stopTiming与co.aikar.timings.FullserverTickHandler.startTiming的总占用
附加参数:
   ①在第7/8个测试中,Entity-activation-range和Entity-tracking-range都为128

①: (耗时4h)

是否启用Timings/实体数Thread.sleep(越高越好)TPS/Chunks/Entities/TilesTimings的占用综合提升
flase/4094.06%19.75/1089/42/120.08%---
true/0493.93%19.88/1089/39/120.19%1.85%
false/50090.95%19.98/1089/530/120.03%---
true/50089.93%19.97/1089/534/120.23%2.20%
false/200081.02%19.93/1089/2029/120.08%---
true/200079.14%19.83/1089/2034/120.18%0.52%
false/2000/怪物全部被激活18.09%19.96/1089/2033/120.03%---
true/2000/怪物全部被激活8.05%19.93/1089/2032/120.15%0.14%

即使打开Timings,大约也只会占用0.15%~0.25%的服务器tick,如果关闭此项则可以降低0.1%~0.2%(因为co.aikar.timings.FullserverTickHandler.startTiming[开始Timing的事件]依然存在,不会消失。这0.1%的服务器tick占用可以化作0.1%~2%的TPS提升/mspt降低,这一点提升完全可以不在意。
但是,如果你的服务器内安装了一些可以代替timings的插件,例如spark。那么你完全可以选择关闭这一项选择
如果你偶尔需要使用Timings,又没有替代插件,我还是推荐保留了。
如果你没用过....哦,那没事了,直接关掉吧,不用想。


3. world-settings.anti-xray.enabled
(Test ID:72-81)(是否启用反透视,默认=false。这里不讨论其他配置,因为不会影响性能)
注意:①测试的时候engine-mode=1(也是默认值)似乎是没有用的,但设置为2时可以生效
    ②反透视的原理是服务器修改数据包,让服务器发给玩家的关于区块数据的数据包中都充满假矿,玩家收到数据包后,自己看不见的区域都会变成假矿。如果玩家正在用一些作弊mod透视矿物,他看到的将都是假矿
    测试内容:
    ①开启和关闭反透视的两种情况下,服务器的sleep占比和ServerConnection(绝大部分为数据包交换)的占用,并多次测试求平均值
    附加参数:
    ①前面说过了的world-settings.anti-xray.engine-mode=2

①: (耗时3h,这里只给了求平均值后的结果,没给原值)

是否启用anti-xrayThread.sleep平均值(越高越好)ServerConnection平均值(越低越好)综合提升|针对提升
是(默认值)94.348%0.798%         ---|---
否94.376%0.71%   0.45%|11.03%


如果关闭此项,也许可以给服务器带来0.45%的TPS提升(虽然各测5次,但还是有误差,有可能这是误差原因),同时也也可以降低每个玩家10%左右的占用,如果服务器玩家多了,不开启这一项也能有一点效果。
如果服务器是生存服,有需要反矿透,我建议直接打开,因为没有哪个反矿透插件占用比这个配置还低了。
如果是很多人的商业性质服,开启它有什么意义呢(笑),还不如关掉优化一下给玩家更好的体验。


4.world-settings.despawn-ranges
(Test ID:82-85)(生物离玩家多远将会被删除,soft是缓慢地依次删除[随溢出实体数量增加而变快],hard是直接删除。默认值soft=32,hard=128)
这里的soft不能比hard高,否则高出部分没有意义。而且不建议比spigot.yml内entity-activation-range.monsters低,否则可能怪物对你有仇恨却突然没了
这项数值会尽量保证服务器内的实体回到bukkit.yml内spawn-limits限制的范围以下,除非实体不能再被删除了
测试内容:
   ①新生成的僵尸=服务器内限制生物数量,且生物已经饱和的情况下,不同soft数值下服务器的状况(没有动hard,因为会改变实体机制)
附加参数:无

①: (耗时3h)

world-settings.despawn-ranges.soft数值Thread.sleep(越高越好)TPS/Chunks/Entities/Tilesdoticktickentity针对提升
3290.86%19.97/1089/146/2652.54%3.62%---
2491.20%19.98/1089/123/2653.14%2.61%27.9%
6491.24%19.79/1089/179/2653.29%3.19%11.82%
12889.85%19/99/1089/234/2652.37%4.63%-27.9%

在world-settings.despawn-ranges.soft降低到24后,实体减少了20%左右,最多可以降低27.9%的实体。设置到128后,实体相比32时多了至少50%。
但是真有这么大的变化效果?
实际会比这个小,因为在服务器中,玩家如果不加载区块,通常实体是不会多于限制的。只会有一些刷怪笼或者非自然生成的生物超过这个限制。而despawn-ranges的目的就是删除这些非自然生成的生物。当玩家跑图时,由于加载了新的区块,实体会明显超过限制,world-settings.despawn-ranges.soft的意义就不是很大了,此时world-settings.despawn-ranges.hard才更有用处(但hard对于服务器内一些实体的机制有影响,同时会减少刷怪[服务器内刷怪距离为24~128,比如设置到64时,随机tick刷新的怪物离玩家距离为80,将被直接删除,相当于本次实体刷新尝试失败],因此不建议设置到64以下)
如果你的服务器玩家经常跑图,但是总体实体不是很多,可以适当下降world-settings.despawn-ranges.hard(比如降低到96)。
如果你的服务器内实体特别多,而且你降低过spigot.yml的entity-tracking-range。可以将world-settings.despawn-ranges.soft设置和前面那个数值接近的水平。world-settings.despawn-ranges.soft也可以下降到80~96。
如果你的服务器玩家都很肝,且他们抱怨某些实体总是会消失,那么world-settings.despawn-ranges.soft完全可以设置为64。


5. world-settings.optimize-explosions
(Test ID:86-93)(是否开启paper对于爆炸的优化,死亡的实体会被立即清除等,从而减少爆炸占用。默认=false)
开启后爆炸时的实体将被缓存而不是重复计算,1.15或更高的版本开启此项可能效果不明显
测试内容:
    ①不同数量TNT爆炸时,TNT的占用和睡眠的tick占比
    ②不同数量TNT爆炸时,TNT的占用和睡眠的tick占比
附加参数:无

①: (耗时3h)

TNT数量/采样时间/是否开启该配置项Thread.sleep(越高越好)TPS/Chunks/Entities/TilestickentityTNT的占用针对提升(同比)
336*1/30s/否87.58%19.23/1089/98/126.83%4.67%---
336*3/45s/否74.36%19.82/1089/251/1219.34%15.65%---
336*8/45s/否35.85%17.33/1089/100/1257.08%52.82%---
336*16/45s/否7.72%14.38/1089/168/1288.21%80.87%---
336*1/30s/是91.65%19.92/1089/161/122.80%0.97%79.23%
336*3/45s/是79.88%19.87/1089/150/1213.97%11.57%26.08%
336*8/45s/是49.58%19.58/1089/148/1241.91%37.74%28.55%
336*16/45s/是17.63%14.72/1089/273/1276.91%66.70%17.53%

②: (耗时2h)

TNT数量/采样时间/是否开启该配置项SleepForTick(越高越好)TPS/Chunks/Entities/Tiles/mspttickentityTNT占用针对提升
864*1/30s/false61.12%20.00/235/148/11/7.425.42%13.79%---
864*2/30s/false44.61%19.10/162/134/11/7.439.61%33.68%---
864*4/45s/false24.14%18.73/289/282/15/11.256.14%38.72%---
864*1/30s/true63.82%20.00/242/124/11/7.124.44%17.84%9.36%
864*2/30s/true45.38%19.25/253/137/11/7.431.63%24.83%27.28%
864*4/45s/true41.07%18.25/289/162/15/6.632.30%24.08%28.51%


开启此项后,TNT的占用同比下降了10%~30%。同时TPS有一定幅度的提升
开启此项后,在禁止TNT爆炸的生存服内几乎没有优化效果;在允许TNT爆炸的生存服内,如果使正在使用盾构机等大型机器,会有显著的优化效果(平常的时候没有);在一些使用爆炸效果多的RPG服务器中,开启这一项可以来带稳定的爆炸占用下降。
并且建议所有服务器都打开此项,因为没有副作用。


6. world-settings.hopper.disable-move-event
(Test ID:93-97)(是否禁用漏斗的move事件,禁用后可以降低漏斗占用,但coreprotect,领地插件等可能无法记录或保护漏斗物品)
注意:这个选项上方还有一个push-based[高版本已被移除],可能可以对漏斗进行优化,但有重大BUG[详情见github issue #763 #354],因此在后期版本删除了此项,本贴也不对push-based进行测试
测试内容:
   ①当漏斗传输和不传输时,分别启用和禁用move事件时,漏斗的占用
附加参数:无

①: (耗时2h)

配置项数值/漏斗是否正在传输Thread.sleep(越高越好)TPS/Chunks/Entities/Tiles漏斗占用针对提升
false/是87.49%19.05/1106/98/6561.49%---
true/是89.54%19.65/1106/96/6560.93%37.59%
false/否88.93%19.85/1106/100/6302.11%---
true/否88.69%19.88/1106/105/6311.55%26.55%

将此项配置设置为true后(即禁用move事件),漏斗的占用下降了25%~40%。
但是此项配置不能在以插件玩法为中心的生存/RPG服中开启(通常安装了领地插件/CoreProtect等,会导致漏斗不被保护),只能在以原版内容为中心的生存服中开启。因此启用此项前请三思,考虑是否要对漏斗move事件进行监听。


7. use-faster-eigencraft-redstone
(是否启用theosib的红石优化算法,启用后对于红石的优化巨大。仅1.13~1.15可用,默认=false)
注:由于Mojang在1.16大改红石机制,原算法的作者还没有更新适配1.16的新算法,因此这一项在1.16被移除了
测试内容:
   ①:启用这项后对于红石计算的优化效果
附加参数:
   ①:view-distance=8(以后高版本除特殊情况外,默认=8,因为性能差异问题会影响结果)


配置项数值/测试次数Thread.sleep(越高越好)TPS/Chunks/Entities/Tiles/MSPTdotick机械运动的占用(包括红石)综合提升
false/1st76.31%19.42/289/225/14/4.77.04%11.43%---
true/1st88.52%19.98/289/212/14/4.72.96%0.94%71.66%
false/2nd77.86%19.15/289/218/12/4.16.91%10.29%---
true/2nd87.71%19.87/289/213/14/4.33.33%1.13%66.75%

启用后,对于红石的优化可以达到90%(活塞一类的优化很小),总体能达到70%的优化效果。
强烈建议服务器都开启这一项,除非启用后红石机器出现问题。


8.keep-spawn-loaded-range
(Test ID:117-121)(出生点加载区块的范围,加载区块数=[(数值*2+1)^2],默认值=4)
   keep-spawn-loaded(是否加载出生点区块,默认值=true)
keep-spawn-loaded-range:0 和keep-spawn-loaded: false的区别:前者会加载出生点的1区块,后者不会加载出生点区块。除非玩家加入服务器并加载了区块。并且keep-spawn-loaded的部分是无法被卸载的
另外,在2019年2月22日之前构建的paper.jar,在玩家加载出生点前,出生点区块不会被加载,请悉知(论核心更新的重要性)
测试内容:
   ①无玩家进入时,不同数值的keep-spawn-loaded-range能减少多少的tick占用
   ②无玩家进入时,不同数值的keep-spawn-loaded-range能减少多少的tick占用
   附加参数:无

①: (耗时3h)

keep-spawn-loaded-range数值Thread.sleep(越高越好)TPS/Chunks/Entities/Tilesdoticktickentity综合提升
895.90%19.87/289/24/71.50%0.22%---
497.27%19.94/81/13/00.99%0.15%1.37%+
298.01%19.98/25/2/00.31%0.03%2.11%+
0(测试时直接关闭加载了,实际0区块loaded)97.86%19.98/0/0/00.23%0.00%1.96%+
1690.42%19.79/1089/61/136.33%0.55%-5.58%+

②: (耗时2h)


keep-spawn-loaded-range数值SleepForTick(越高越好)TPS/Chunks/Entities/Tiles/msptdoticktickentity综合提升
893.18%20.00/361/114/15/2.53.96%1.24%---
495.62%20.00/121/44/5/1.41.40%0.26%2.44%+
297.32%20.00/49/10/0/0.70.20%0.00%4.14%+
0(测试时直接关闭加载了,实际0区块loaded)96.48%20.00/0/0/0/0.40.00%0.00%3.30%+
1678.54%20.00/1225/335/24/9.118.20%7.32%-14.64%+


关闭keep-spawn-loaded或设置keep-spawn-loaded-range为0后,服务器内的Tick至少下降了2%(要看主城周围的实体/方块实体多不多,多的话这个优化效果会更好;如果服务器玩家经常蜗居在出生点,可能效果会变差一些)。
如果关闭这一项,对服务器的优化可能是显著的(出生点实体多的情况下)。
但是这可能会导致生存服中出生点的机器无法循环工作(如刷沙机,这样就要多点人了),或者multiverse插件小概率出现无法用/mv tp命令传送到别的世界失败的问题。
所以,不建议把keep-spawn-loaded设置为false,但是可以把keep-spawn-loaded-range设置为0(至少加载1区块,防止mv的bug),如果需要常加载的生存服可以选择把这一项设置为2或4。


9. chunk-tasks-per-tick
(1.15+可用,每个tick最多能执行多少次区块的任务,默认=1000)
官方称降低此项数值可能对区块渲染和区块生成有帮助,但在实际测试中(1.15/1.16),无论设置为多少数值,都无法看见因这项配置带来的区块渲染/生成速度变化,也没有减少实际占用。我目前也不推荐降低此项数值以进行优化。

Global.conf
适用服务端:Sponge

注:文件在服务端目录\config\sponge\global.conf中,这是sponge最主要的配置文档
测试时服务端核心是API7.2.0/SpongeForge,由于本配置文件的配置项较多,还会写出配置项所在第XX行
另外global.conf中有大量内容与server.properties/bukkit.yml/spigot.yml/paper.yml重合,这一部分将不会进行测试

1. deny-chunk-requests
(Test ID:98-101/第630行)(设置为true后,所有未加载区块内的请求都会被拒绝。它可以提升一定性能,但它是实验性设置。默认值=false)
启用它可能会导致一些问题,如果这些问题出现了并确定是该项配置导致的,可以根据严重程度考虑关闭它
测试内容:
   ①玩家不移动和玩家跑图时,开启/关闭此项时的服务器状况
   附加参数:
      ①view-distance=16

①:

deny-chunk-requests/是否跑图Thread.sleep(越高越好)TPS/Chunks/EntitiesTPS提升综合提升
false/否48.95%20.00/1089/363------
true/否57.72%20.00/1089/365017.18%
false/是4.73%18.58/2377/818------
true/是15.30%19.49/2607/8560.9110.10%

启用此项后,有显著的性能提升,并且在TPS能提升接近1。但是测试时(8次启动)中有一次崩溃了,看上去是区块生成的时候导致卡线程,可能和这个配置项有关
但我还是建议你启用此项,配置文件中建议也比较中肯,只是说出现问题后才建议关闭。


2. panda-redstone
(Test ID:102-105/第479行)(使用panda4944的红石算法以提升性能,默认值=false)
这项配置在spongeForge服中可能效果不好(MOD服谁用红石啊),但是如果你是用SpongeVanilla(并且是生存服),那么这一项的优化效果绝对是显著的。
测试内容:
   ①:不同红石数量不断更新(并更新周围方块)时,开启/关闭此项配置时红石更新的占用和服务器状况
   附加参数:
      ①这次使用了SpongeVanilla。稳定性更好同时数据更精确

①:

panda-redstone配置/测试次数Thread.sleep(越高越好)TPS/Chunks/Entities周围方块更新的占用针对提升
false/1st27.40%19.47/1089/34730.54%---
true/1st55.36%20.00/1089/3561.27%67.18%
false/2nd25.56%19.76/1089/36529.49%---
true/2nd52.59%20.00/1089/3591.37%65.89%

开启此项后,仅关于红石周围的方块更新优化就达到了95%左右,整体的红石占用也能降低65%左右,而且测试时发现,开启此项后红石更新更加流畅了,并不会损失特性。
对于这种副作用小的选项,我是建议一定要启用的。如果出现了大型机器失效后,可以尝试关闭此项(sponge也修复了一些原版的bug,机器失效时也要注意这些。


3.eigen-redstone
(Test Id:106-112/第432行)(是否启用theosib的红石优化算法,同样可以提升性能,默认值: enabled=false vanilla-decrement=false vanilla-search=false)
enabled决定这个算法是否启用
vanilla-decrement决定了是否使用原版的红石能量等级计算,默认值即为使用优化算法
vanilla-search决定是否使用原版的方块更新机制,默认值即为使用优化算法
测试内容:
   ①启用这项后对于红石计算的优化效果
   ②子配置项内两个选项对于红石计算的优化效果
   附加参数:
      ①还是用SpongeVanilla啦



是否启用/测试次数Thread.sleep(越高越好)TPS/Chunks/Entities针对提升
false/1st37.92%19.55/1089/351---
true/1st61.31%19.88/1089/36567.36%
false/2nd41.65%20.00/1089/360---
true/2nd62.48%20.00/1089/36461.40%



工作的红石优化算法Thread.sleep(越高越好)TPS/Chunks/Entities针对提升
都不工作(即完全使用原版)34.56%19.77/1089/356---
vanilla-decrement50.40%19.94/1089/36048.42%
vanilla-search63.36%19.88/1089/36388.02%

启用此项后,优化效果与之前的panda-redstone差不多,可能还会略差一些,红石周围的方块更新优化也能达到90%左右,整体的红石占用也能降低60%左右。但是这一项配置可以单独设置启用给的部分,比如使用优化算法会导致某机器无法使用,这样的话你可以设置为使用原版红石能量更新/使用原版方块更新,能保留另一个,同时又有一定的优化效果。


4. mob-spawn-range
(同spigot.yml,默认值=4)
但是sponge中,此项修改通常不会影响刷怪上限,修改数值有微弱的实体占用变化(对实体优化不会超过5%),不过会降低刷怪速度
由于优化效果几乎很小,所以不测试

总结
以下根据结果总结了server.properties/bukkit.yml/spigot.yml/paper.yml/global.conf中的所有配置项
如果你需要自己对配置进行修改,可以查看下面的内容
如果你只需要一个能优化的文件,直接拉到最下面白嫖配置文件即可

优化效果:极好>好>较好>一般>较差>差>极差>特别差


[*]极好:在任何情况下都能让占用至少减半/TPS提升巨大
[*]好:在多数情况下都能减少40%以上的占用/TPS提升很大
[*]较好:一般情况下都能减少客观的占用/提升一定的TPS
[*]一般:优化效果不是特别好,在特定情况下才有明显优化
[*]较差:看不到明显的优化效果,在特定情况下才有较小优化
[*]差:几乎看不到优化效果,在特定情况下才有较小的优化
[*]极差:用debug/timings/spark都很难看出优化效果,跟不用说实际情况了
[*]特别差:挂名配置文件,改了也更没改差不多


副作用:无>极小>小>中等>较大>大>极大


[*]无:副作用为零
[*]极小:副作用几乎不用考虑,根本不会影响游玩体验
[*]小:副作用小,在一些特定情况会影响游玩体验
[*]中等:有一定的副作用,偶尔会影响游玩体验
[*]较大:时常会影响游玩体验,玩家可能会发现显著的区别
[*]大:常常会影响游玩体验,玩家会发现显著的区别并抱怨
[*]极大:严重影响游玩体验,玩家会发现显著区别且有时无法游玩下去(例如CS:GO变成了回合制游戏)


分界线上方是已经测试过的内容,同时有中等或更好的优化效果

分界线下方是未测试过的内容,这些配置项绝大多数优化效果都特别小

注:由于帖内宽度的问题,有一部分配置项没有写完全
对于实体,有18项配置项可以进行优化,其中10项优化效果较好

配置文件配置项优化效果副作用
server.properties+spigot.yml➟view-distance较好中等
bukkit.yml➟spawn-limits好小
bukkit.yml➟ticks-per.monster-spawns好极小~较大
bukkit.yml➟ticks-per.animal-spawns一般极小
spigot.yml➟entity-activation-range较好小
spigot.yml+global.yml➟mob-spawn-range一般无
spigot.yml➟max-tick-time.entity较好(paper除外)较大
paper.yml➟despawn-ranges较好小
paper.yml➟optimize-explosions较好极小
global.conf➟living-hard-despawn-range一般中等
global.conf➟living-soft-despawn-range一般中等





spigot.yml+paper.yml+global.con➟max-entity-collisions极差无
spigot.yml➟squid-spawn-range差无
spigot.yml➟arrow-despawn-rate特别差无
spigot.yml➟merge-radis差极小
paper.yml➟experitence-merge-radis极差极小
global.yml➟item-merge-radis差极小
global.conf➟item-despawn-rate较差中等
global.conf➟living-soft-despawn-minimum-life较差较小


对于方块实体,有1项配置项可以优化,此项优化效果较好

配置文件配置项优化效果副作用
spigot.yml➟max-tick-time.tile好(paper除外)中等


对于红石,有3项配置项可以优化,这3项优化效果较好

配置文件配置项优化效果副作用
paper.yml➟use-faster-eigencraft-redstone极好小
global.conf➟eigen-redstone极好小
global.conf➟panda-redstone极好小

注: paper.yml内use-faster-eigencraft-redstone和global.conf内eigen-redstone为同一个算法

对于区块,有12项配置可以优化,其中8项优化效果较好

配置文件配置项优化效果副作用
server.properties+spigot.yml➟view-distance极好中等
bukkit.yml➟chunk-gc一般无
paper.yml➟max-chunk-sends-per-tick较好较大
paper.yml➟max-chunk-gens-per-tick较好较大
paper.yml➟delay-chunk-unloads-by一般极小
global.conf➟chunk-gc-load-threshold一般极小
global.conf➟chunk-unload-delay一般极小
global.conf➟deny-chunk-requests较好一般





bukkit.yml➟ticks.per-autosave较差极小
paper.yml➟max-auto-save-chunks-per-tick差中等
global.conf➟auto-save-interval较差极小
global.conf➟max-chunk-unloads-per-tick一般较小


对于漏斗,有5项配置可以优化,这5项优化效果较好

配置文件配置项优化效果副作用
spigot.yml➟ticks-per.hopper-transfer一般较小
spigot.yml➟ticks-per.hopper-check较好极小
spigot.yml➟hoppper-amount一般较小
paper.yml➟hopper.disable-move-event较好较大



关于其他类型的优化,有1项配置可以优化

配置文件配置项优化效果副作用
paper.yml➟Timings.enabled较差极小


更改配置文件虽然能大幅提升性能,但它不是万能的,如果你需要对服务器进行更好的优化,请打开折叠部分

首先需要知道服务器内什么东西会进行tick
Full Server Tick大致=区块+实体(不包括玩家)+方块实体+玩家+插件占用+Mod占用
配置文件通常只能对区块,实体,方块实体进行优化
而玩家和数据包传输这两个部分是几乎不能优化的,但是可以通过其他方式减少它们的占用

玩家的话,可以考虑开bungeecord服,设置几个子服对玩家进行分流,并同步数据。这样既能减少玩家占用也能减少一定的区块/实体/方块实体占用
MOD的事件占用几乎无法减少
但是插件的事件占用可以通过更换轻量插件/减少不必要的粒子或GUI 从而大幅减少它们的占用
比如crazycrates插件,抽奖时的跑马灯式GUI,你完全可以不用它而用其他抽奖插件
再比如mythicmobs插件,当怪物的粒子效果较多时服务器会严重卡顿,你当然可以减少粒子效果从而降低mm插件的占用

查看数据包和玩家的占用,可以通过Spark或者Timings
Spark:
net.minecraft.network.NetworkManager(玩家)
net.minecraft.network.PacketThreadUtil(数据包传输,主要是插件和MOD)
(不同版本可能有差异,如果搜不到可以只搜索net.minecraft.network)
Timings:
Connection Handler(玩家,v1/v2都有)
Minecraft: Packet(数据包传输,貌似仅v2有)
v1的插件事件占用会单独显示

找到关键字后展开内容,spark可以通过看包名(就是net.minecraft这一串)找到是什么东西的事件,timings里面已经给出的事件的来源。不一定需要你全部看懂,只要你知道大致是什么事件,来源是谁即可。找到了占用较高[如果只是一点点占用就不用管了]的插件/MOD,再按照之前黑体字给的方法即可


更多
https://pump.goatcounter.com/count?p=www.mcshuo.com/thread-2289-1-1.html&r=www.mcshuo.com&q=utm_campaign%3D%E6%9C%8D%E5%8A%A1%E5%99%A8%E9%85%8D%E7%BD%AE%E6%96%87%E4%BB%B6%E4%BC%98%E5%8C%96
如果本贴有格式/语法问题,或者你希望我搬运更多教程文章,欢迎联系我!

搬运催更 & 问题反馈:快速响应问卷 或在下方留下评论。
https://s21.ax1x.com/2024/05/23/pkQQcZR.png
页: [1]
查看完整版本: 服务器配置文件优化 —— 让测试数据来说话吧!TPS最高提升100% (CPS)