幻想曲.Net

19 位领导已批示 关于 “寻Apache2下Discuz高性能配置方案”

1. 
   summer 发表于： 四月 28th, 2009 10:56 下午
   

   个人认为使用nginx更好一些，一个是因为nginx确实有比apache更高的并发处理能力，另外也是因为dz官方就是用的 nginx。另外看看是否和 mysql 的配置有关

2. 
   linnchord 发表于： 四月 29th, 2009 8:36 上午
   

   1. ngix
   2. php加速器 apc/eacc
   3. zend优化器
   4. squid
   5. memcached
   6. mysql的配置优化

3. 
   幻想曲 发表于： 四月 29th, 2009 8:53 上午
   

   @linnchord:
   这个列出来的不是一时半会能解决的，如memcache的应用。
   mysql方面目前基本上没什么压力。

4. 
   rssidea 发表于： 四月 29th, 2009 9:03 上午
   

   哪个linux？我现在有一台dell 1950,CentOS默认配置的apache，请求phpinfo2000多rps,discuz首页也就220左右吧。我使用了APC缓存，提高了php执行效率。其他都是针对前端的优化，估计对压力测试工具没什么用处。

   个人觉得不用刻意去追求所谓最大连接数，连接数不够时，apache日志可以反应出来，逐渐调整即可。如果并发很高的，合理设置keepAlive也许是个好想法。另外，高并发情况下，php解释器调用的开销是非常大的，换成fastcgi会好很多。你的内存只有1G，那强烈建议你换nginx或者lighttpd吧。

   discuz不熟，那个说2000多的文章能不能让我看看？

5. 
   ZhuZhe 发表于： 四月 29th, 2009 9:37 上午
   

   同上nginx^_^

6. 
   星辉一冷 发表于： 四月 29th, 2009 9:59 上午
   

   ServerTokens ProductOnly
   ServerSignature Off

   DeflateCompressionLevel 3

   vhost:

   SetOutputFilter DEFLATE
   Header set Connection close

7. 
   phoenix 发表于： 四月 29th, 2009 10:00 上午
   

   apache 在优化后的性能是很强的。
   应该不会是这个样子的。

   是不是mysql 的连接处了问题。

   mysql 默认安装后的连接好像是100个。

   还有仔细查看 mysql 和apache 的日志，看看在最大负荷时，日志中有什么提示吗？

8. 
   星辉一冷 发表于： 四月 29th, 2009 10:00 上午
   

   BTW: APC, EAC, XCache 等也是很有必要的.

9. 
   phoenix 发表于： 四月 29th, 2009 10:01 上午
   

   不知道你用的什么版本的linux ，

   推荐 centos 之类的服务器版本做。

   一些桌面版本可能不太适合。

10. 
    幻想曲 发表于： 四月 29th, 2009 10:34 上午
    

    @rssidea:
    谢谢你的建议。
    服务器操作系统是centos 5.2.
    内存只有1G，
    你所说的“discuz首页也就220左右吧”是指什么？

11. 
    幻想曲 发表于： 四月 29th, 2009 10:37 上午
    

    @phoenix:
    的确，我也不认为apache在这种情况下的表现如此“差劲”。
    mysql这边基本没有压力，CPU只有2%左右。
    而且昨天lr只是测试的首页访问，而且首页基本上是静态的了，基本上涉及不到DB查询。
    apache日志倒是没有去看过，谢谢你的提醒。

12. 
    幻想曲 发表于： 四月 29th, 2009 10:38 上午
    

    @星辉一冷:
    兄弟，你这也太抽象了~~~

    @phoenix:
    系统是 centos 5.2.

13. 
    幻想曲 发表于： 四月 29th, 2009 10:40 上午
    

    @rssidea:

    discuz不熟，那个说2000多的文章能不能让我看看？
    当时随意翻到了，出处可能找不到了^_^

14. 
    kevin 发表于： 四月 30th, 2009 9:33 上午
    

    是不是你的测试方法有问题。
    1> loadrunner的脚本中是否包含了 其他静态资源的载入。比如图片，样式表，脚本等等。可以一并去掉
    2> 只测试首页页面即可，write_cookie等浏览器响应可以保留。

    3> 静态资源可以放到其他的服务器上，修改论坛的资源相对地址为绝对地址就好了，可以显著的提升页面展示速度。 Apache 对静态资源的处理是非常差的，nginx 是不二的选择。

    4> 在论坛这种应用中，nginx, apache 的差别并不大，瓶颈在磁盘IO与数据库IO

    GOOD　LUCK ^_^

15. 
    幻想曲 发表于： 四月 30th, 2009 9:44 上午
    

    @kevin:
    第一轮测试是发现有这样的问题，有一些图片是其它服务器上的地址。
    第二轮去掉了这些图片。
    直接点我还是感觉服务器上的配置有问题:-/

16. 
    L.S 发表于： 五月 3rd, 2009 2:19 上午
    

    1）nginx
    2）增加图片超时时间，可以考虑使用YSLOW的建议来优化；

17. 
    overerd 发表于： 五月 3rd, 2009 10:41 下午
    

    应该是应用程序配置或某些业务逻辑问题。
    从你的ResponseTime来看，感觉每2分钟响应时间就上去，而且还小有规律（图给的太少），从文中得知“web服务器CPU占用70%-80%”，那应该是某些业务“忙碌”而导致。

    可以尝试解决：
    增加个空Php网页测试，如继续此情况，说明是服务器配置问题。
    如果是.Net可以windbg，php就。。。

18. 
    幻想曲 发表于： 五月 4th, 2009 8:24 上午
    

    嗯，这个方法已经测试过，曾经压测过一个phpinfo();这个响应时间与并发数还是比较好的。
    我不愿去相信这是Discuz的问题。

19. 
    Miles 发表于： 六月 19th, 2009 10:15 上午
    

    可以用xdebug和WinCacheGrind分析下是否为Discuz的问题

发表您的评论