使用LAMP作为我的游戏的服务器组件是否可行？

Question

我一直在开发一款伪多人游戏，它将每个玩家的重要数据存储在我的MySQL数据库中。该游戏类似于部落冲突，玩家建立自己的基地，并可能选择攻击其他玩家的基地。

为了防止作弊，所有重要的功能都通过PHP在我的服务器上运行。例如，如果玩家想要建造一座房子，服务器会被告知：玩家想要建造BUILDING_A grid{x，y}，PHP脚本从数据库中检查该区域是否可用，玩家是否有技术，资金等。

所有这些函数都相对简单。他们只是检查谁试图访问数据库，以及他们是否能做他们想做的事情。然后，服务器将更新数据库中的玩家数据，并向设备返回一条消息。

---

因此，从本质上讲，我的游戏将始终遵循相同的过程：

1）播放器设备发出请求，

2）服务器对玩家进行身份验证并允许或拒绝请求，

3）服务器向播放器设备发送响应，设备跟随它。

---

但我不确定我的方法是否可行或可扩展。我刚刚独自测试了它，效果很好，但假设我在第一周就得到了100或1000名球员。在高峰期，每秒可能有几百个服务器请求，其中调用PHP脚本并访问和更新数据库。如果它成为热门，并且有成千上万的人同时访问我的PHP脚本和数据库怎么办？

这种方法一开始就可行吗？如果我的服务器足够强大，那么一个PHP脚本可以同时被这么多人访问吗？服务器能否在一秒钟内向我的数据库写入数百次？它会对操作进行排队吗，它会忽略一些操作，重叠的操作会失败吗？

例如，如果我支付了 AWS EC2 费用并在那里设置了我的 LAMP，那么这种系统是否可以工作，或者我是否会遇到某种我不知道的限制或问题？

Answer 1

是的，LAMP环境可以轻松管理每秒超过10k的请求。这里只有一个建议，而不是使用比服务器性能更好的服务器。在大多数情况下，仍然是性能的更好选择。Apache2NginxApache2Nginx参考： https://theorganicagency.com/blog/apache-vs-nginx-performance-comparison/如果想自己做基准测试，你可以使用：https://www.litespeedtech.com/benchmarks/php-hello-world当您计划在EC2上部署它时，您可以首先使用m5a.large，后来在普及创建（克隆）一个m5a.large Ubuntu服务器上，并将它们都放在ELB下。祝你好运！

Answer 2

PHP脚本同时被这么多人访问，服务器可以在一秒钟内数百次写入我的数据库吗？它会对操作进行排队吗，它会忽略一些操作，重叠的操作会失败吗？每秒数百个 -- 好吧，几千个 -- 视情况而定。对操作进行排队 - 是的，但这相当快;这些操作将主要并行执行。忽略一些 -- 不。好吧，如果他们保持队列很长时间，以至于超过，默认为50秒。（不太可能发生。lock_wait_timeout“只是失败了”——不。您可能应该计划有足够的RAM来处理所涉及的所有数据。（听起来这不会有问题。如果查询必须过于频繁地进入磁盘，这将成为扩展游戏的限制。AWS EC2 使用固态硬盘，对吗？（硬盘太慢。是否涉及图形？这是如何处理的？它是否完全在每个用户的客户端浏览器中？我问，因为如果重绘屏幕涉及SQL查询，那可能是一个沉重的负载。听起来典型的“会话”是启动 PHP连接到 MySQLSELECT用户信息做一些PHP处理'更新用户信息这将发生，平均每隔几秒钟发生一次。一千个用户这样做应该很容易实现。这假设它是一个单人游戏。相反，如果它是一个多用户游戏，那么“新建的房子”难道不需要向所有其他用户广播吗？

Answer 3

首先，您可能希望查找以您选择的语言编写的“AJAX 服务器”或“远程过程调用 （RPC） 服务器”包。您实际上并不需要“Web服务器”来完成此特定工作。您可以找到专门针对此目的的更专业、更轻量级的工具。（对于“容器化部署”，通常用于此类任务。Rackspace等供应商在其网站上非常广泛地撰写了有关部署“动态可扩展服务器”的各种方法的文章。我相信他们仍然有一家公司的文章，该公司销售“足球妈妈”使用的移动应用程序。当没有人使用该应用程序时，相应的“容器”不会运行。当周末来临时，每个妈妈都看着她们的小宝贝在田野里跑来跑去，一个可调节数量的容器动态地上线来处理负载......然后最终再次死亡。所以，是的，你的推理是合理的，你的要求是一个非常普遍的要求。你可以站在巨人的肩膀上。

Answer 4

这个问题没有简单的答案，但对于一个在配置良好的服务器上运行的编写良好的应用程序，逻辑的执行只需要处理请求所需时间的一小部分 - 响应时间通常由网络往返时间和与DBMS通信所花费的时间主导。多用户系统通常无法扩展的地方是处理并发性;程序员认为并行运行的东西需要按顺序运行，并且可能使用锁定来强制执行。因此，编程语言的选择（只要它不是CGI，其中程序被声明来处理每个请求）实际上并不重要。您需要能够对其中每个操作进行基准测试 - 收集有关客户端端到端响应时间的数据，并在中心位置（不一定是实时）收集数据，并在应用程序中收集有关数据库等待时间的指标。PHP会话可能是一个主要瓶颈 - 还要尽量减少每个请求对数据库的调用次数。我见过臃肿的Wordpress安装努力在3秒内用256Mb的RAM处理请求，并且在合理的规格主机上不支持超过20个并发连接 - 我也见过内容管理系统能够在10毫秒内处理请求，RAM限制为4Mb。容量大约相差一千倍以上。