Posts Tagged ‘fastcgi’

bluehost性能:fastcgi及opcode(xcache),drupal下测试

April 20th, 2011

bluehost性能,我用的是drupal,20000个node,当搜索引擎爬行时,下面是我观察了好几天的数据(由于我用了中文URL,所以不能整站静态化),只谈PHP性能。

如果1.没打开fastcgi,那么马上就会超时得很厉害

2.打开了fastcgi,由于node太多,还是有超时,但已经好些了,再安装xcache (opcode都差不多,xcache安装容易些),性能再次上升,但超时依然

3.安装cacherouter模块:非常奇怪,性能反而下降了,不解,于是查看xcache-admin的管理界面,发现cache每4~5分钟就会被清空一次。

发帖问bluehost的管理员,加上自己的测试,终于得到以下信息:

1.opcode(xcache) 只有在fastcgi的模式下才有效,否则安装了也是浪费性能

2.但fastcgi每5分钟就会重启一次进层,所以导致这个过程中opcode的cache的就会被灭掉,下次又要重建cache,这绝对是性能浪费的.但如果不用的话,又会慢得要死

3.我想到了一个关于drupal的折中的办法,drupal所有页面都是调用index.php的,所以我在cron里设置了每5分钟请求一下index.php,这就能一定比率地保证了drupal的模块是被缓存了,注意是index.php,而不是普通的主页,这要与启用了boost相区别,如我就设置为:http://u14s.com/index.php而不是设置为http://u14s.com

This is the case with APC as well. You only get the benefit of 5 minutes of in memory caching. There unfortunately is nothing we can do to remedy this.

 

 

Share

利用cron增加bluehost的反应速度

May 13th, 2010

wget -O – -q -t 1 http://www.trackself.com/print.php >/dev/null 2>&1

用bluehost或者其它空间的朋友都知道,如果网站有一段时间是沉默的,那么fastcgi这个进程就会自杀(这是VPS国外空间的一个缺点啊,自己的独立服务器才不会让fastcgi自杀而影响性能),这样下次有游客访问进来的时候,如果 刚好要运行PHP的话,fastcgi又要重新启动,那是相当的慢啊。慢不但止,这样的一次重新启动,所需要的短暂的CPU也是令人无语的。重要的是,当fastcgi进程完全死寂时,fastcgi对PHP执行的缓存就会被清空,这样运行时又要重新建立缓存,实在不好。

所以最好的办法就是写一个只有一行的PHP文档,每分钟访问这个文档一次,这样的话fastcgi进程就会一直呆在那里了,这样PHP的反应时间就会让人觉得很舒服。另外则是,也不用担心因为fastcgi长期在那里运行则会增加负担,fastcgi在无任务执行的时候所占的内存是以KB为单位而已,而且当出错,fastcgi会自杀并自动启动新进程。

当然,需要注意的就是如果你修改php.ini要使之马上生效的话,要手动杀了fastcgi让它自己重启,否则可能要等上个一两小时才能生效。

我的做法是写一个只有一行的PHP,print.php里只有一行<?php print “cron”;?>,每分钟执行一次

Share

用bluehost要使用fastcgi

March 25th, 2010

今天服务器频频出现CPU超载而出现访问不了

先说一下情况:我有两个页面,一个是http://www.135995.com,这是一个纯静态的页面,第二个页面是本站http://www.trackself.com,为wordpress程序(无静态化).没什么特别应用,为什么会访问不了呢。

发现每当使用wordpress的安装插件功能,这时基本上就是一个超载的过程了,我当时就想,bluehost不会那么无耻吧,这CPU分配得也太低了吧,只跑个博客就频死了。OK,现在发现,原来是我设置上的错误啊。

我的bluehost的PHP设置是apache_module形式的,默认的应该就是这个了(印象中我没改过),还好我记得fastcgi一般是比module形式的PHP要快的,于是就切换到这个模式。

一个非常理想的结果,wordpress快了几乎10倍(夸张了,但明显感觉提速了),而且我的静态页面感觉也快了。

这还不是令我高兴的,当我同时创建30个gallery的时候,同时创建大约3000张图片的缩略图(就是为了人为让fastcgi死,以及产生 CPU超负)。果然,后台显示cpu超负了。但是,嘿嘿,我的静态页面http://www.135995.com还正常得很,并没有被ban掉,爽吧。而且过非常短的5秒,全部PHP也再次活了。而且进一步的长时间测试表明,即便它显示我每分钟都超负,但我的两个站都跑得很正常,我的神啊,我爱 fastcgi,这样其实就相当于CPU限制在PHP层面上被取消了。不过,明显的是,如果长期这么做,估计bluehost的客服会要求我关闭 wordpress的,偶尔做做测试就好了

备:在学校的独立主机我做过详细的测试,单单几十个网站不用cpanel的时候,fastcgi是比module要慢的,但这种情况显然不适合bluehost以及其它的虚拟主机提供商。

故我总结了一点:bluehost的主机,如果CPU超负,只是临时ban掉这个程序一断时间,而不是ban整台虚拟主机,所以啊,还有什么理由让你不使用fastcgi模式呢。

Share