请求太多处理不过来?
第一步是应该是请求分流，建多个队列用多线程处理不同类型的请求，
例如登陆应有本人的队列

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

你必须要考虑程序的可伸缩性，也就是可以同时并发的逻辑越多，你可以扩展性能的余地就越大。
你得设法找出代码中任何全局的，加锁的，不能并发的东西。

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

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

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

呵呵,,看到你说多线程本人立马就知道你压力的原因了..\
并发性强的代码,多线程就是死,而且是最快的.

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

你改一下列队 测试一下 别给弄坏了 就行 要不然被开 别找本人

楼上所言有道理啊，建议题主模拟大量用户进行登录和战斗操作，然后记录上锁和解锁地址和次数。
你说的登录和战斗不是用的同一个队列，那肯定是线程在满负载工作啊，看看线程有没有可以改进的地方。

没研究过，看看大神们的讨论，帮你顶一下

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

全局无响应了!!会不会死锁了？

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

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

跟本人现在做这个东西架构一样，不过本人的还在开发中。头痛啊。 本人现在是发送信息，等服务端接收完数据后就断开，把数据存入队列，等服务端处理完后再连接发送请求的客户端返回。

找你们公司的架构师处理吧,不是技术层面就能够解决的问题

每个玩家同时有几百条在进行推送 —  看看能不能先把这个设计改一改

内存,CPU,IO(硬盘/带宽)其中某一项瓶颈了？
假如存在瓶颈，那就要该业务逻辑或扩展机器了。
假如都有空闲，那就要找到哪里阻塞了。

引用:

分服务器确实会好点，但我们的服务器配置还是挺不错的，是程序崩溃了，主要是程序处理不过来。

不要简单的一句崩溃，崩溃了说明有BUG啊。

引用:

发生战斗时，每个玩家同时有几百条在进行推送，推送消息用到的是多线程。我们在测试的过程中发现，消息队列中的消息没有推送完，所以导致以上出现的种种问题。

什么叫同时？几百条/s？统计过每秒服务器处理消息数量吗？