Andilas13的博客

不得不说，在有微软生态绑定的情况下，C# 果然是最多人选择的语言。ASP.NET Core 发展多年，生态成熟、文件完善，加上 Azure 的整合优势，对许多企业来说算是稳健、安全又效率不错的选择。要评估帮合作对象做连接我们工具的语言翻译器，所以顺便做了一个小范围的调查，看看那些语言是应该在我们优先制作翻译器的部分，当然，各种语言在伺服器开发中其实各有拥护者，而选择也很常受到应用场景、产业特性甚至历史包袱影响。像是游戏引擎后端、即时运算服务、嵌入式系统，也许还有unreal的存在加持。

但由于系统是根据超线程数来计算CPU使用率的，因此单凭CPU使用率来观察会导致对实际负载的误解。如何在云端平台上建立 30,000 名用户的网页 MMO游戏环境-4 (OOM Killer 问题與雲平台!未来我们将根据进程和执行绪的运算负载以及事件的平均完成时间来评估系统负载，而不是依赖 CPU 使用率来计算。如何在云端平台上建立 30,000 名用户的网页 MMO游戏环境-3 (OOM Killer 问题)如何在云端平台上建立 30,000 名用户的网页 MMO游戏环境-2 (服务器)

虽然云端平台没有给我们直接的答复，但我们透过AI发现，该特定的云端供应商使用了共享虚拟网路介面（ENI）。较小实例的网路频宽是共享的，这意味着如果其他租户在给定时间内使用同一虚拟机管理程式上的网路资源，您的资料包可能会暂时延迟，然后一次性涌入您的机器，导致记忆体突然激增。我们认为这是导致该问题的主要原因。然而，我们的目标是尽可能在小实例（1C2T 或 2C4T）上运行我们的伺服器。在超过 24 小时的监控过程中，我们没有观察到任何异常的持续记忆体成长（因为我们使用快取机制，记忆体使用量呈现波浪式波动）。

共享的虚拟网卡（ENI）共享网路频宽，如果Hypervisor 在该时段内有其他租户占用了网卡资源，可能会导致后续记忆体暴增。检查CloudWatch 的 "Network TCP Retransmit" 指标，看看是否有大量的 TCP 重传发生。小型 EC2（1C2T / 2C4T）通常使用低端虚拟网卡，没有专用流量优先权，万一某个时刻封包累积过多...处理内部 VPC 流量时发生突发缓存释放，导致主机瞬间暴增流量。可能...封包重组与 EC2 虚拟网卡（vNIC）限制?可能...共享环境导致突发流量?

在云端平台上建立 30,000 名用户，用机器人模拟连接行为之后发生的异常与...

虽然我们的伺服器采用了第三代 AMD EPYC 4C8T 处理器，但我们的机器人程式可能没有得到适当的最佳化，我们仍在寻找有问题的部分。但奇怪的是，在我们之前对以「G」开头的平台进行的测试中，我们运行了 60,000 个机器人连接，接收 3,000 个连接的边缘伺服器每分钟仅传输了 900 MiB 的数据。相比之下，在这个平台上大约有2,000个连接，数据流量每分钟高达2.5 GB，这显示出明显的差异。然而，我们高估了这方面，最终我们只维护了26台核心伺服器以及东京和法兰克福的一台边缘伺服器。

在云端平台的积分支持下，这次搭建了一个512*512平米的小规模单一虚拟世界，最多可容纳3万人..

累积到目前测试回馈给我们的心得，主要问题还是在前端显示的部分。所以就来聊聊在网页跑3D多人互动之渲染效能瓶颈!!!数万个3D角色与场景物件需即时渲染，导致GPU/CPU过载，低端设备卡顿。已经使用的解决方案：LOD（Level of Detail）技术：根据距离动态调整模型细节，远距离使用低多边形模型。Instanced Rendering：批次渲染相同模型（如重复的树木、建筑物）。Culling（剔除）：透过视锥剔除（Frustum Culling）和遮挡剔除（Occlusion Culling）跳

多人连线使用技术与乘载量

突破上万同时互动的人数，想知道真假不如自己试试看!填写问卷有机会拿到技术白皮书甚至...

原先考虑主要放在东京，但经过测算发现主要测试者区域连线进来反而更远。测试修正后放在AWS ..

考虑了Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform (GCP)AWS的新创培育方案提供了我们强力且实际的点数支持...

在先前的测试数据，每个逻辑伺服器能处理约 80 万个任务/秒，每个任务影响 3-5 个物件...

问：60,000 名玩家在同一世界真的可能吗?你们说不使用分片（sharding）就能做到 ，但是「伺服器网格化（server meshing）」本质上也是一种分片?此外，我想知道你的延迟（latency） 和 吞吐量（throughput），以及如果这个技术是依赖「决定性（determinism）」?答：

現在的性能極限是軟體還是硬體?達成同樣或是超過市面上的目標，但是成本只要....?我們使用 更經濟的硬體（N2 系列，節省 40% 成本），實現了 6 萬人單一無縫世界實時互動，為大規模 MMO遊戲/元宇宙以及其他需要高併發的運算 帶來全新可能！ 技術亮點：- 每一執行緒每秒 100,00

多伺服器协作的复杂性远超单一伺服器多执行绪的开发，开发者需要面对网路延迟、数据一致性、操作时序等多方面的挑战。传统与现代解法的比较:

为什么加开伺服器?1. 技术层面：2.区域化分服：3. 玩家社群与社交关系：

随着技术的不断演进，未来帧同步技术还有更多优化空间，无论是降低延迟、提高效能，或是适应更多不同类型的游戏场景，这些都将是我们持续努力的方向。- 在游戏运行过程中，根据客户端与服务端的时间差，在 0.85~1.15x 范围内进行加减速。低于 **150ms** 时，减速运行。2. **客户端与服务端间的延迟在 150ms 以内，几乎不会影响用户体验。- 透过上述方式，将物理网路延迟控制在 **30~400ms** 范围内。- 在游戏开始前，检测房间内所有玩家的连线延迟，取延迟最高的玩家作为基准。

应对DDoS攻击更轻松：边缘伺服器不处理逻辑，即使主机因资源耗尽而中断，也不影响整体游戏的运行。主机暴露于风险之中：逻辑伺服器直接面向网路，容易受到非应用层级的攻击，例如骇客入侵或DDoS攻击，除服务中断外甚至造成机密资讯外泄。成本与效能的最佳平衡：透过云端 Auto Scaling 功能，在面对攻击时，快速扩展更多可用端点，实现最低成本的高效防护。在逻辑伺服器之前，架设一层专门处理连接的边缘伺服器，仅负责封包转发与数据缓存。全球部署边缘伺服器机房，为来自世界各地的玩家提供稳定低延迟的游戏体验。

很棒的玩法为什么做不出来?当交互不只是在你的电脑，而是跨多人的电脑时候，你会卡在什么上?

突破单一世界无分片的承载量，模拟60,000名玩家在同一空间的即时互动怎做