升级建议

私人青铜

各位管理员， 我很惊讶的发现你们的脱机升级之后仍旧使用了discuz的代码，在过去几天中，又出现几次响应较慢和超时的现象。
作为一个有大量同时在线的大型交互系统，吉他中国目前的访问量和同时在线人数已经很大，这时再使用简单的LAMP模型已经不能满足这种复杂的并发连接开销造成的系统资源压力，应当考虑使用中间件技术，开源也有比如JBOSS这样比较优秀的系统，然后使用EJB模式构建，可以极大的缓解目前由于数据库请求和网络响应队列的压力（这两方面是我的猜测）。
当然，我也能理解出于成本的原因，不可能再次快速升级，那么可以考虑找些专业的工程师对服务器进行调优，或者适当的调整代码。否则，随着更多爱好者的关注，服务器的压力会越来越大，造成困难。

小兵吉他

恩，我们争取1年内超越QQ，2年内超越SINA，3年内超越盛大
:kiss:

yourdj

首先谢谢您的建议

我们使用的不是LAMP，而是FALMP(FreeBSD+apache+Lighttp+MySQL+PHP)，您看到的是假象:)


坦白的讲，这次升级和搬迁到现在为止，我们的确遇到了很多问题

但这个问题不单纯是系统或数据库方面的问题（起初的确是遇到了MySQL上的两个BUG，但MySQL官方的技术支持人员已经及时帮助我们clear了），并且我们也不曾因为在这方面出过问题而受到阻碍。

现在我们面临的问题有两个

1、线路质量问题，目前的线路有5%的丢包率

2、线路带宽问题，流量或端口被限制（这个是我估计的，目前还没有实际证实）

综合上面两个因素和我们平均并发100页面的情况来看，会导致一系列不完整的请求在系统内部排队。这样来说，再好的架构，都会很快被不能立即完成的队列填满（我认为拥有更大的队列空间和内存在这种情况下反而会成为加速情况恶化的条件），造成传输拥堵，也就是现在我们遇到的问题。表面现象更像是一种真正的分布式拒绝服务攻击。

即便是这种恶劣条件下，系统能表现出这样的情况，已经非常勉强……

解决问题要找到根源，所以我认为真正的解决办法就是拿着家伙冲进机房给他们点颜色瞧瞧;)

呵呵，开玩笑……

另外我们也非常欢迎有技术实力的朋友参与这个平台的建设，给我们的用户更舒适的交流空间。

此致

By YouRDj

私人青铜

所以我才建议用中间件的... 因为比较复杂的大表查询会造成超时 堵塞队列的
另外一个办法是不是可能拆分表 或者规划索引呢 提高相应速度
如果是网络缓冲的问题 还是需要调内核 嘿嘿