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

月亮岛

• 原作者：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格的服务器状况(有区块回收)[1.12]
    ①玩家在出生点时，不同数值时的服务器状况[1.15]
    附加参数:
       ①在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/Tiles dotick tickentity 综合提升|针对提升 10 91.68% 19.98/1491/296/26 2.82% 2.26%            ------ 8 92.55% 19.97/952/257/14 2.33% 2.25%   10.50%|17.58% 6 93.62% 19.97/913/265/11 1.87% 1.64%   23.31%|23.84% 4 94.72% 19.97/703/233/11 1.11% 1.34%   36.50%|36.78% 3 94.32% 19.95/611/116/8 1.25% 1.32%   31.70%|46.00% ②: View-distance数值 SleepForTick(越高越好) TPS/Chunks/Entities/Tiles/mspt tickentity ChunkProviderTick 综合提升 8 78.02% 20.00/529/111/16/7.8 9.23% 7.34% --- 6 83.38% 20.00/289/111/11/5.8 8.52% 3.10% 25.02% 4 87.76% 20.00/169/105/7/5.7 6.77% 1.48% 35.62% 3 86.04% 20.00/121/111/5/5.6 8.34% 1.40% 37.85% 12 79.93% 20.00/841/149/19/8.5 8.20% 8.33% -8.83% 16 76.24% 20.00/1369/252/28/10.6 8.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秒后的服务器状况[1.12]     ②不同ticks-per.autosave数值时，世界保存的占用[1.12]     ①不同ticks-per.water/amibient-spawns数值时，玩家在出生点以8的视野距离挂机60秒后的服务器状况[1.15]    附加参数:       ①禁用区块回收       ②View-distance=16       ③不限制bukkit.yml内的spawn-limits(此配置项会限制玩家周围的最大刷怪量，因此测试时需取消限制) ①: Monster-spawns数值 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles dotick tickentity 针对提升 1 26.85% 15.90/1089/5110/11 5.10% 61.91% --- 3 73.92% 19.59/1223/1785/11 3.32% 17.98% 23.70% 5 76.73% 20.00/1089/1248/11 4.45% 14.34% 25.61% 10 83.38% 19.87/1089/605/11 3.69% 8.69% 28.99% 30 88.15% 19.90/1089/247/11 3.61% 4.86% 30.71% ②: ticks-per.autosave数值 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles 世界保存占用 针对提升 6000(default) 92.04% 19.97/1089/66/13 0.69% --- 12000 92.62% 19.96/1089/63/13 0.46% 33.33% 24000 93.02% 19.96/1089/63/13 0.47% 31.99% 2400 92.97% 19.85/1089/65/13 0.62% 10.15% 600 93.74% 19.98/1089/66/13 0.55% 20.29% ③: water/ambient-spawns数值 SleepForTick(越高越好) TPS/Chunks/Entities/Tiles/mspt tickentity 针对提升 1 0.00% 11.71/529/2588/16/82.6 77.56% --- 3 51.29% 20.00/529/1103/16/30.8 35.39% 20.90% 5 62.93% 20.00/529/537/16/22.8 25.60% 24.13% 10 79.16% 20.00/529/365/16/14.3 12.83% 27.56% 30 89.63% 20.00/529/125/16/7.7 3.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[1.16+]，water-ambient-spawns[1.15+]。ambient-spawns[1.15+]至少设置为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[1.12-]/10[1.13+] water-animals:5[1.12-]/10[1.13+] ambient:15 water-ambient[1.16+]=20) 猜想①:与视野距离有关    猜想②:与玩家数有关    猜想③:与加载的区块量有关     ①和②很好测试，①是错的，②是正确的， 猜想③在测试过程中发现会受到被卸载的区块中实体的干扰，而且这一部分实体无法被kill，也不会计入服务器实体的数据中。因此在测试中，禁止区块回收并使用循环命令/tp @p[score_move_min=1] ~ ~ ~-1 将玩家平移2000格后，会到起点并kill所有实体，并重复循环命令移动2000格。 结果: 【图片丢失】 因此，在跑图的时候,服务器内的实体满足这个公式(这个似乎是bukkit官方给的，海螺也说是这个公式,只不过图中的256[16*16]应该为289[17*17]) 【图片丢失】 结论(spawn-limits的解释): ①当已被卸载的区块加载时，满足 生物≤spawn-limits内对应数值*(当前世界区块数/289) ②当已被卸载的区块加载时，满足 总实体≤spawn-limits内各数值之和*(当前世界区块数/289) 此外我们还发现了一个离谱的现象[仅1.13或更低版本]: 只要所在区块被kill @e或killall了，短期情况(也许是几小时，也许....是永久)下实体不可能恢复原样，随后经过排除，我们发现是spigot.yml内的mob-spawn-range影响的，默认值为4，导致刷怪量大大减少 所以，你的服务器刷怪少也许是因为mob-spawn-range导致的 测试内容:    ①:参数不同时玩家在出生点的时候服务器状况[1.12]    ②:参数不同时玩家在出生点的时候服务器状况[1.15]    附加参数:       ①View-distance=16       ②需要在spigot.yml内设置mob-spawn-range为等同于视野距离的数值，否则会影响此参数的效果导致不刷怪       ③测试时spawn-limits的默认值为正常的10倍，模拟10人时的情况 ①: 该参数的倍率 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles dotick tickentity 针对提升 10 37.97% 19.93/1378/812/52 4.35% 55.29% --- 20 3.61% 19.01/1378/1635/52 4.76% 86.81% -57.00% 40 0.65% 11.82/1378/2935/52 3.34% 93.48% -69.07% 5 66.63% 20.00/1378/475/52 3.34% 28.04% 50.71% 2 80.32% 20.00/1378/188/52 4.20% 13.71% 75.21% ②: 该参数的倍率 SleepForTick(越高越好) TPS/Chunks/Entities/Tiles dotick tickentity 针对提升 10 18.55% 19.83/497/1073/16/37.1 73.26% 60.09% --- 20 0.00% 14.22/304/2037/14/59.1 92.97% 81.17% -70.16% 40 0.00% 6.54/309/4014/14/131.9 94.07% 84.70% -81.90% 5 56.21% 20.00/399/533/16/20.8 40.31% 31.75% 47.17% 2 79.27% 20.00/396/221/15/10.2 17.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[1.13-] (两次区块回收之间，需要加载多少区块才能进行下一次区块回收，默认=0) 这两项数值不会影响很多性能 这是测试chunk-gc.period-in-ticks在不同情况下的性能占用: (耗时1h) ①：在出生点时，不加载额外区块，区块回收占用[1.12] ②：匀速移动200格后，区块回收占用[1.12] chunk-gc.period-in-ticks Thread.sleep processChunkGC 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倍时候，服务器内生物刷新的状况[1.12]    附加参数:       ①view-distance=16 ① mob-spawn-range数值 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles dotick tickentity 针对提升 4 90.92% 19.97/1089/25/9 5.04% 1.64% --- 5 90.63% 20.00/1089/39/9 4.87% 1.51% 5.56% 6 90.19% 19.97/1089/59/9 4.59% 2.33% -25.05% 8 89.94% 19.96/1089/93/9 4.69% 2.41% -29.23% 10 90.28% 19.97/1089/99/9 4.53% 2.02% -15.10% 3 91.02% 19.93/1089/17/9 4.68% 1.35% 8.34% 2 90.69% 19.88/1089/8/9 5.03% 1.15% 16.20% 1 90.03% 19.99/1089/3/9 5.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只分散的僵尸移动时，服务器占用[1.12]     附加参数:        ①:禁用区块回收        ②:将paper.yml内的despawn-ranges.soft设置为128(否则服务器内的怪物会被缓慢删除，影响测试效果)        ③:view-distance=16 ① entity-activation-range.monsters数值 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles tickentity EntityZombie 针对提升 32 82.96% 19.99/1513/501/21 2.66% 7.02% --- 28 84.95% 19.96/1513/501/21 2.67% 5.40% 17.38% 24 85.40% 19.96/1513/502/21 2.66% 4.95% 21.90% 20 87.70% 19.96/1513/501/21 2.73% 3.82% 36.70% 16 88.34% 19.98/1514/500/21 2.44% 3.09% 44.78% 12 89.50% 19.97/1514/499/21 3.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~24  animals: 8~12 misc:2~4 water:16  wake-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只实体的占用，以及玩家怪物计算被跳过的情况[1.12]   (由于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 Tick TPS/Chunks/Entities/Tiles tickentity 实体计算被跳过状况 针对提升 50 109.38% 16.92/1127/1437/25 100.75% 中等 --- 40 90.71% 19.95/1123/1435/25 80.81% 中等 最高20% 30 70.97% 19.88/1123/1431/25 60.83% 中等 最高40% 15 38.83% 19.92/1123/1430/25 30.65% 严重 最高70% 5 18.17% 19.92/1123/1411/25 10.72% 极为严重 最高90% max-tick-time.tile同理 针对提升中的“最高”指的是当服务器内实体/方块实体达到100% tick占用时(即50ms 达到了默认值的阈值)，但是大多数服务器都无法达到这个数值，所以您需要使用Timings进行采样(输入/timings on 三分钟后输入/timings paste)，然后在输出结果的网页内内找到"tickentity"一项的Pct Tick 如果max-tick-time没有修改过，您又需要优化，您可以将max-tick-time.entity修改为[tickentity最高时占用(%)*50-5]，大约会带来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倍)，漏斗的占用[1.12] 其他参数:    ①/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的占用[1.12]    ②不同数值时2000余个TNT爆炸时，服务器的状况以及TNT的占用[1.15]    附加参数:    ①view-distance: 16 max-tnt-per-tick数值 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles tickentity TNT占用 针对提升 100 1.43% 10.96/1094/118/14 2.55% 81.77% --- 20 33.64% 19.87/1089/3904/13 2.76% 59.66% 27.04% 5 60.76% 19.34/1089/4766/13 3.27% 29.49% 64.94% 1 83.45% 19.84/1089/3728/13 2.29% 10.27% 87.45% max-tnt-per-tick数值 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles/mspt tickentity TNT占用 针对提升 100 52.11% 20.00/529/110/16/32.2 19.54% 13.71% --- 20 66.71% 20.00/529/1612/16/15.1 16.13% 9.80% 28.52% 5 76.97% 20.00/529/1367/16/10.6 11.73% 3.67% 73.34% 1 79.41% 20.00/529/1794/16/9.7 8.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[1.13-](每个世界中每tick最多生成多少区块，默认=10) world-settings.max-auto-save-chunks-per-tick(每个世界中保存地图时，每tick最多保存多少区块，默认=24) world-settings.max-chunk-sends-per-tick[1.13-](每个世界中每tick最多发送多少区块，默认=81) 注:生成≠发送，生成这里指的是从未被加载过的区块，发送指的是已经加载过的区块 这三个配置项放在一起的原因:     ①它们的功能都相似     ②它们对于服务器的优化效果不是很明显(除非服务器玩家跑的比香港记者还快/网速感人)，但是这三项数值对于提升服务器的稳定性(可以让tps更平滑，减少跑图/世界保存带来的突发tps降低)     测试内容:         ①不同数值时，5倍移动速度平稳加载新区块时，服务器tps和CPU占用[1.12]     附加参数:         ①view-distance=16 ①:由于world-settings.max-auto-save-chunks-per-tick优化效果很小，且这个数值不会影响性能，所以没放入测试（主要是测不出，强行测的话误差大） max-chunk-sends/gens-per-tick数值 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles dotick CPU占用 针对提升 默认值(81，10) 0% 18.89/992/227/19 80.66% 84% --- 2 0% 20.00/1043/310/34 81.60% 80% 4.80% 1 71.51% 20.00/599/160/9 23.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的设置公式={[V*2+4]*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的总占用[1.12] 附加参数:    ①在第7/8个测试中，Entity-activation-range和Entity-tracking-range都为128 ①: (耗时4h) 是否启用Timings/实体数 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles Timings的占用 综合提升 flase/40 94.06% 19.75/1089/42/12 0.08% --- true/04 93.93% 19.88/1089/39/12 0.19% 1.85% false/500 90.95% 19.98/1089/530/12 0.03% --- true/500 89.93% 19.97/1089/534/12 0.23% 2.20% false/2000 81.02% 19.93/1089/2029/12 0.08% --- true/2000 79.14% 19.83/1089/2034/12 0.18% 0.52% false/2000/怪物全部被激活 18.09% 19.96/1089/2033/12 0.03% --- true/2000/怪物全部被激活 8.05% 19.93/1089/2032/12 0.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(绝大部分为数据包交换)的占用，并多次测试求平均值[1.12]     附加参数:     ①前面说过了的world-settings.anti-xray.engine-mode=2 ①: (耗时3h,这里只给了求平均值后的结果，没给原值) 是否启用anti-xray Thread.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，因为会改变实体机制)[1.12] 附加参数:无 ①: (耗时3h) world-settings.despawn-ranges.soft数值 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles dotick tickentity 针对提升 32 90.86% 19.97/1089/146/265 2.54% 3.62% --- 24 91.20% 19.98/1089/123/265 3.14% 2.61% 27.9% 64 91.24% 19.79/1089/179/265 3.29% 3.19% 11.82% 128 89.85% 19/99/1089/234/265 2.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占比[1.12]     ②不同数量TNT爆炸时，TNT的占用和睡眠的tick占比[1.15] 附加参数:无 ①: (耗时3h) TNT数量/采样时间/是否开启该配置项 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles tickentity TNT的占用 针对提升(同比) 336*1/30s/否 87.58% 19.23/1089/98/12 6.83% 4.67% --- 336*3/45s/否 74.36% 19.82/1089/251/12 19.34% 15.65% --- 336*8/45s/否 35.85% 17.33/1089/100/12 57.08% 52.82% --- 336*16/45s/否 7.72% 14.38/1089/168/12 88.21% 80.87% --- 336*1/30s/是 91.65% 19.92/1089/161/12 2.80% 0.97% 79.23% 336*3/45s/是 79.88% 19.87/1089/150/12 13.97% 11.57% 26.08% 336*8/45s/是 49.58% 19.58/1089/148/12 41.91% 37.74% 28.55% 336*16/45s/是 17.63% 14.72/1089/273/12 76.91% 66.70% 17.53% ②: (耗时2h) TNT数量/采样时间/是否开启该配置项 SleepForTick(越高越好) TPS/Chunks/Entities/Tiles/mspt tickentity TNT占用 针对提升 864*1/30s/false 61.12% 20.00/235/148/11/7.4 25.42% 13.79% --- 864*2/30s/false 44.61% 19.10/162/134/11/7.4 39.61% 33.68% --- 864*4/45s/false 24.14% 18.73/289/282/15/11.2 56.14% 38.72% --- 864*1/30s/true 63.82% 20.00/242/124/11/7.1 24.44% 17.84% 9.36% 864*2/30s/true 45.38% 19.25/253/137/11/7.4 31.63% 24.83% 27.28% 864*4/45s/true 41.07% 18.25/289/162/15/6.6 32.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事件时，漏斗的占用[1.12] 附加参数:无 ①: (耗时2h) 配置项数值/漏斗是否正在传输 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles 漏斗占用 针对提升 false/是 87.49% 19.05/1106/98/656 1.49% --- true/是 89.54% 19.65/1106/96/656 0.93% 37.59% false/否 88.93% 19.85/1106/100/630 2.11% --- true/否 88.69% 19.88/1106/105/631 1.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被移除了 测试内容:    ①:启用这项后对于红石计算的优化效果[1.13] 附加参数:    ①:view-distance=8(以后高版本除特殊情况外，默认=8，因为性能差异问题会影响结果) 配置项数值/测试次数 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles/MSPT dotick 机械运动的占用(包括红石) 综合提升 false/1st 76.31% 19.42/289/225/14/4.7 7.04% 11.43% --- true/1st 88.52% 19.98/289/212/14/4.7 2.96% 0.94% 71.66% false/2nd 77.86% 19.15/289/218/12/4.1 6.91% 10.29% --- true/2nd 87.71% 19.87/289/213/14/4.3 3.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占用[1.12]    ②无玩家进入时，不同数值的keep-spawn-loaded-range能减少多少的tick占用[1.15]    附加参数:无 ①: (耗时3h) keep-spawn-loaded-range数值 Thread.sleep(越高越好) TPS/Chunks/Entities/Tiles dotick tickentity 综合提升 8 95.90% 19.87/289/24/7 1.50% 0.22% --- 4 97.27% 19.94/81/13/0 0.99% 0.15% 1.37%+ 2 98.01% 19.98/25/2/0 0.31% 0.03% 2.11%+ 0(测试时直接关闭加载了，实际0区块loaded) 97.86% 19.98/0/0/0 0.23% 0.00% 1.96%+ 16 90.42% 19.79/1089/61/13 6.33% 0.55% -5.58%+ ②: (耗时2h) keep-spawn-loaded-range数值 SleepForTick(越高越好) TPS/Chunks/Entities/Tiles/mspt dotick tickentity 综合提升 8 93.18% 20.00/361/114/15/2.5 3.96% 1.24% --- 4 95.62% 20.00/121/44/5/1.4 1.40% 0.26% 2.44%+ 2 97.32% 20.00/49/10/0/0.7 0.20% 0.00% 4.14%+ 0(测试时直接关闭加载了，实际0区块loaded) 96.48% 20.00/0/0/0/0.4 0.00% 0.00% 3.30%+ 16 78.54% 20.00/1225/335/24/9.1 18.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) 启用它可能会导致一些问题，如果这些问题出现了并确定是该项配置导致的，可以根据严重程度考虑关闭它 测试内容:    ①玩家不移动和玩家跑图时，开启/关闭此项时的服务器状况[1.12]    附加参数:       ①view-distance=16 ①: deny-chunk-requests/是否跑图 Thread.sleep(越高越好) TPS/Chunks/Entities TPS提升 综合提升 false/否 48.95% 20.00/1089/363 --- --- true/否 57.72% 20.00/1089/365 0 17.18% false/是 4.73% 18.58/2377/818 --- --- true/是 15.30% 19.49/2607/856 0.91 10.10% 启用此项后，有显著的性能提升，并且在TPS能提升接近1。但是测试时(8次启动)中有一次崩溃了，看上去是区块生成的时候导致卡线程，可能和这个配置项有关 但我还是建议你启用此项，配置文件中建议也比较中肯，只是说出现问题后才建议关闭。 2. panda-redstone (Test ID:102-105/第479行)(使用panda4944的红石算法以提升性能，默认值=false) 这项配置在spongeForge服中可能效果不好(MOD服谁用红石啊)，但是如果你是用SpongeVanilla(并且是生存服)，那么这一项的优化效果绝对是显著的。 测试内容:    ①:不同红石数量不断更新(并更新周围方块)时，开启/关闭此项配置时红石更新的占用和服务器状况[1.12]    附加参数:       ①这次使用了SpongeVanilla。稳定性更好同时数据更精确 ①: panda-redstone配置/测试次数 Thread.sleep(越高越好) TPS/Chunks/Entities 周围方块更新的占用 针对提升 false/1st 27.40% 19.47/1089/347 30.54% --- true/1st 55.36% 20.00/1089/356 1.27% 67.18% false/2nd 25.56% 19.76/1089/365 29.49% --- true/2nd 52.59% 20.00/1089/359 1.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决定是否使用原版的方块更新机制，默认值即为使用优化算法 测试内容:    ①启用这项后对于红石计算的优化效果[1.12]    ②子配置项内两个选项对于红石计算的优化效果[1.12]    附加参数:       ①还是用SpongeVanilla啦 ① 是否启用/测试次数 Thread.sleep(越高越好) TPS/Chunks/Entities 针对提升 false/1st 37.92% 19.55/1089/351 --- true/1st 61.31% 19.88/1089/365 67.36% false/2nd 41.65% 20.00/1089/360 --- true/2nd 62.48% 20.00/1089/364 61.40% ② 工作的红石优化算法 Thread.sleep(越高越好) TPS/Chunks/Entities 针对提升 都不工作(即完全使用原版) 34.56% 19.77/1089/356 --- vanilla-decrement 50.40% 19.94/1089/360 48.42% vanilla-search 63.36% 19.88/1089/363 88.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://klpbbs.com/thread-136764-1-1.html 免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ Cnzw 回复 使用道具 举报 教程中心 各种问题内容使用教程，不限于MC哦 返回版块 返回列表 发新帖 高级模式 B Color Image Link Quote Code Smilies 您需要登录后才可以回帖 登录 | 立即注册 本版积分规则 发表回复 回帖并转播 回帖后跳转到最后一页 月亮岛 22 主题 162 回帖 385 积分 中级会员 中级会员, 积分 385, 距离下一级还需 115 积分 中级会员, 积分 385, 距离下一级还需 115 积分 积分 385 收听TA 发消息 快速回复 发帖 点评 赞赏 分享 推荐帖子 更多 1【KLPBBS】【1.16x】加拉里亚公园主题公园- 2【视频】每日一更-随机方块大陆生存 大海哥 精选版块 更多 游戏资讯 教程中心 视频专区 官方公告 灌水闲聊 游戏技巧 生活树洞 搞笑囧图 |Archiver|手机版|小黑屋|MCBBBS我爱你 | 萌ICP备20249110号 GMT+8, 2025-4-14 14:25 , Processed in 0.141206 second(s), 35 queries . Powered by Discuz! X3.5 © 2001-2025 Discuz! Team.