100分！求服务器压力的解决方案

Question

服务器测试socket

Answer 1

“队列”这个词儿听上去挺时髦，但是这往往就是你的瓶颈。你看许多学java的人抄袭的所谓“队列”的代码，只有两个处理线程，还美其名曰“队列多线程代码”。实际上你应该在一个有着4核或者8核的pc server可以用上几百个、甚至上千个线程来处理游戏消息，而不是只有两个线程。“队列”这个词儿，可能使得你只会两个线程。所以不要纠结在什么队列中。实际上.net的ThreadPool可以自动管理系统线程池，你的处理方法可以直接注册给系统线程池，根本用不着自己搞什么队列。

Answer 2

很早以前，我们的一个功能相当“轻”的交友方面的服务器系统，自己建了一个线程池，默认是最多300个线程。实际上当服务于两千万在线活跃用户时，大多数时间也只是并行有50个线程在执行事务。那是因为自己写上一百几十行代码来自己做个线程池，能够满足个人爱好，而并不是因为它一定就比.net framework中的更高级。什么时候会考虑队列？实际上当你天然地就是多线程编程时，此时反而是考虑特意要“阻塞”一些数据并行处理的时候，才想到要使用“队列”来吧原本并行的东西给顺序化了。把“队列”这个词用在多线程编程上，这就是似是而非的，容易产生误区。

Answer 3

首先检查程序算法，有没有低级的严重影响性能的BUG. （这是很常见的）比如说不正确的循环，正则等。
然后在压力测试时，观察一下CPU的每个核是不是都爆满。如果是的话，那什么优化也别想了，加服务器吧。
如果都不是，那可能就是LS几位所说的问题，系统架构问题。

Answer 4

还要充分利用服务器的内存，按理说，游戏服务器的关键数据都应该驻留内存。如果说你的CPU都满了，内存还空空荡荡，也说明资源没得到充分利用。

Answer 5

首先 最基本的 你也应该把你配置说出来阿比如8核16G 100MB速度 08R2X64的系统..目前支持了**人..并发多少人.顶峰多少人之后服务器扛不住了...这都是基本信息..如果你说上面的配置 抗住了100W长连接+10W并发..那还发个毛的帖子了

Answer 6

你回答了两条，这里一并作答。你分析的还是有点道理，我们之前也考虑到了，bug基本没有了，因为我们有日志记录。主要是系统结构问题，但现在说这个并不现实，改架构不做讨论氛围内。之前的用例测试，显示cpu和内存消耗并不大。你还有没有其他建议。

Answer 7

我把问题重新整理一下,如下：
现象：玩家登录过多，如果同时在进行战斗，那么达到一定数量后，后面的玩家登录不上，登录上的玩家也收到了影响，游戏没有响应了。
服务器配置：极好，可以排除服务器的问题。
程序方面的：采用socket连接方式。玩家进行战斗，采用的是消息队列的方式，用线程池来处理请求。目前主要是压力过大，但不清楚是哪个模块出了问题。可能是消息推送过多？发生战斗时，每个玩家同时有几百条在进行推送，推送消息用到的是多线程。我们在测试的过程中发现，消息队列中的消息没有推送完，所以导致以上出现的种种问题。

Answer 8

页游的话不需要用socket连接呀
socket的话是长连接
用HTTP就行了
操作一次请求一次~

Answer 9

希望能给你到启发
http://kb.cnblogs.com/page/207824/ 当然这是网站的~登录界面一个服务器~ 聊天一个服务器~
其他的按地图分到不同的服务器~

Answer 10

资料太少，不好做出具体的判断，大家都是狂猜，不过资料一多，估计也没人会看得下去。我怀疑是不是你的战斗计算过于复杂，导致线程池使用了太多的资源，形成队列拥堵，然后就越来越慢，最后暴了，当然，也不排除是有人找到复杂点的恶意攻击，但也应该是变卡，而不是直接无响应了。其实，像这种很容易解决，第一，自己模拟个500线程去战斗登陆或是其它什么，其二，你应该有特殊字符记录吧？比如ATT表示战斗什么的，login表示登陆，view_j表示查看交易所，你再把开始和结束时间一同记录，然后分析一下就很明了哪块。

Answer 11

内存,CPU,IO(硬盘/带宽)其中某一项瓶颈了？
如果存在瓶颈，那就要该业务逻辑或者扩展机器了。
如果都有空闲，那就要找到哪里阻塞了。
不要简单的一句崩溃，崩溃了说明有BUG啊。
什么叫同时？几百条/s？统计过每秒服务器处理消息数量吗？