9Enjoy

带链接的评论和留言真多。。。

Thu, 02 Sep 2010 22:07:31 +0800

连续两天有一大堆垃圾广告评论和留言，今天进后台一看，审核评论 (634 待审核)，汗。。。这么多啊！还好后台有"一次性删除所有待审核的项目"的功能。还有一大堆自动通过审核的评论，手工删除了好几页。

都什么年代了，还在群发评论留链接。。。

无论是百度还是Google，早就把博客评论里的链接权重降的很低了，为什么还要化时间做这些事呢？
也许这种群发链接的方法现在还有一点点作用，但绝对属于黑帽SEO。
有这时间，不如好好的研究下如何提高网站的用户体验。。。

后台把 [url，<a 归入垃圾留言特征词汇，那种说一句话，留个网址的评论或留言也将会被当作垃圾评论或留言，并会自动屏蔽。
Tags - 链接 , seo

linux下分析哪个进程最耗iowait

Fri, 27 Aug 2010 17:39:25 +0800

先停掉syslog
service syslog stop

打开block dump:
echo 1 > /proc/sys/vm/block_dump

多次运行，查看结果
dmesg | egrep "READ|WRITE|dirtied" | egrep -o '([a-zA-Z]*)' | sort | uniq -c | sort -rn | head
排前的比较占用io

抓完后关掉block_dump和启动syslog:
echo 0 > /proc/sys/vm/block_dump
service syslog start

我的一台负荷较重的服务器，iowait经常在10%以上，因此这样查看了下，多次运行显示：

   1283 kjournald
   1059 httpd
    190 pdflush
-------------------------------------
   1267 kjournald
   1228 httpd
      2 pdflush
-------------------------------------
   1506 pdflush
    661 kjournald
    423 httpd
     11 sh
      6 nrpe
      6 bash
      3 check
      2 egrep
-------------------------------------
   1247 kjournald
   1187 httpd
      6 egrep
-------------------------------------
   1288 httpd
   1148 kjournald
      6 egrep
-------------------------------------
   1242 kjournald
   1120 httpd
     57 php
     30 crond
      8 bash
      6 egrep
-------------------------------------

看来kjournald是罪魁祸首？httpd也蛮高的，需要优化。

Tags - iowait , 进程 , 负荷

smarty缓存终极优化测试

Sun, 22 Aug 2010 19:01:16 +0800

之前在看到可以关闭compile_check来减少模板编译文件的判断，这几天看了下郭欣的《构建高性能Web站点》，再次学到好东西。就是放弃smarty自带的缓存文件的判断，直接生成html文件，然后用stat来检查html文件的时间，用来判断是否缓存是否过期。代码类似:

    $cache_filename = 'cache/enjoy_'.$par.'.htm';
    $stat_info = @stat($cache_filename);
    if($stat_info && $stat_info[9] > time()-10800){
        echo file_get_contents($cache_filename);
        exit();
    }
    ......
    $html = $smarty->fetch($template_name,$par);
    file_put_contents($cache_filename,$html);
    echo $html;

用本机的程序测试了下，本机因为是测试环境，没有装apc。

ab.exe -n 100 -c 10 http://www.9enjoy.com/

没用使用smarty缓存，就1句速度很快的SQL查询语句
Document Path:          /
Document Length:        16787 bytes

Time taken for tests:   1.984 seconds
Total transferred:      1697100 bytes
HTML transferred:       1678700 bytes
Requests per second:    50.39 [#/sec] (mean)
Time per request:       198.438 [ms] (mean)
Time per request:       19.844 [ms] (mean, across all concurrent requests)
Transfer rate:          835.19 [Kbytes/sec] received

使用smarty缓存后：
Time taken for tests:   1.891 seconds
Total transferred:      1697100 bytes
HTML transferred:       1678700 bytes
Requests per second:    52.89 [#/sec] (mean)
Time per request:       189.063 [ms] (mean)
Time per request:       18.906 [ms] (mean, across all
Transfer rate:          876.60 [Kbytes/sec] received
没多大提高。

改造之后，但仍然先构造了smarty对象
Time taken for tests:   0.688 seconds
Total transferred:      1697100 bytes
HTML transferred:       1678700 bytes
Requests per second:    145.45 [#/sec] (mean)
Time per request:       68.750 [ms] (mean)
Time per request:       6.875 [ms] (mean, across all concurrent requests)
Transfer rate:          2410.65 [Kbytes/sec] received

显著提高啊！
把加载smarty的语句放在判断后：

Time taken for tests:   0.391 seconds
Total transferred:      1697100 bytes
HTML transferred:       1678700 bytes
Requests per second:    256.00 [#/sec] (mean)
Time per request:       39.063 [ms] (mean)
Time per request:       3.906 [ms] (mean, across all concurrent requests)
Transfer rate:          4242.75 [Kbytes/sec] received
再次大幅提高！

如果自定义了缓存文件名称，那么删除缓存文件就得另外写一个，不能使用smarty自带的。如果要使用smarty自带的删除功能，那么缓存文件就要使用smarty的方式来命名。如模板文件为index.html，那么生成的缓存文件为：%%77^774^774BE9C9%%index.html，如果加了hx这个$cache_id，那么缓存文件为：hx^%%77^774^774BE9C9%%index.html。这是怎么生成的呢？我根据smarty核心程序中的_get_auto_id和_get_auto_filename函数写了一个生成缓存文件名的一个函数。

function get_smarty_cachefile($cache_dir,$template_name,$cache_id=null){
    $_compile_dir_sep = '^';
    $_return = $cache_dir.DIRECTORY_SEPARATOR;
    if(isset($cache_id)) {
        $auto_id = str_replace('%7C',$_compile_dir_sep,(urlencode($cache_id)));
        $_return .= $auto_id . $_compile_dir_sep;
    }

    $_filename = urlencode(basename($template_name));
    $_crc32 = sprintf('%08X', crc32($template_name));
    $_crc32 = substr($_crc32, 0, 2) . $_compile_dir_sep .
              substr($_crc32, 0, 3) . $_compile_dir_sep . $_crc32;
    $_return .= '%%' . $_crc32 . '%%' . $_filename;
    return $_return;
}

这个函数，未考虑缓存目录分级，如果有使用缓存目录分级$smarty->use_sub_dirs=true，那么只需要把$_compile_dir_sep = '^';改为$_compile_dir_sep =DIRECTORY_SEPARATOR即可。
如上例：
$cache_filename = get_smarty_cachefile('cache',$template_name,'hx');
这样就可以使用$smarty->clear_cache($template_name, 'hx')来删除这个缓存文件。

这样，只需要更改判断是否有缓存的代码，尽量把加载smarty的代码和初始化smarty放到判断之后，其他的不用考虑，就可以享受smarty性能的提升了。
Tags - smarty , 优化

用ab对apache,nginx,nginx proxy读取静态文件速度测试

Sat, 07 Aug 2010 11:29:54 +0800

今天抽空分别在三个http下(apache,nginx,nginx proxy)用ab测试一下读取静态文件的反应时间。
ab.exe -c 10 -n 100 http://www.9enjoy.com/css/hx.css
Document Path:          /css/hx.css
Document Length:        215 bytes

Concurrency Level:      10
Complete requests:      100
Failed requests:        0
Write errors:           0
Non-2xx responses:      100
Total transferred:      38300 bytes
HTML transferred:       21500 bytes

apache
Time taken for tests:   5.297 seconds
              min  mean[+/-sd] median   max
Connect:       16   52 296.3     16    2984
Processing:    16  462 915.0    203    4047
Waiting:       16  246 688.7    109    4047
Total:         47  514 951.7    219    4063

nginx
Time taken for tests:   4.859 seconds
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       16   48 295.1     16    2969
Processing:    16  427 897.8    156    4359
Waiting:       16  191 599.0     94    4359
Total:         47  475 936.5    172    4375

nginx proxy
Time taken for tests:   4.219 seconds
              min  mean[+/-sd] median   max
Connect:       16   18   5.8     16      31
Processing:    31  184 289.0    156    3031
Waiting:       16  123 297.2     94    3031
Total:         47  202 288.8    188    3047

这个文件比较小，在来个稍大一点的测试JQuery v1.3.2
ab.exe -c 10 -n 50 http://www.9enjoy.com/js/jquery.js

Document Path:          /js/jquery.js
Document Length:        57254 bytes

Concurrency Level:      10
Complete requests:      50
Failed requests:        0
Write errors:           0
Total transferred:      2880700 bytes
HTML transferred:       2862700 bytes

apache
Time taken for tests:   34.688 seconds
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       16   22   7.7     16      31
Processing:   438 4861 7810.7   1313   31031
Waiting:       16  827 3082.5     31   21078
Total:        469 4883 7811.5   1328   31047

nginx
Time taken for tests:   29.875 seconds
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       16   20   7.1     16      31
Processing:   438 4940 6601.4   1703   23484
Waiting:       16  574 1563.6     16    9016
Total:        453 4960 6601.6   1734   23516

nginx proxy
Time taken for tests:   28.484 seconds
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       16   19   6.7     16      31
Processing:   406 4532 6301.3   1875   28375
Waiting:       16 1234 4325.4     31   21031
Total:        422 4552 6301.6   1891   28391

测试结果，读取静态文件，nginx_proxy最快，nginx比apache略快一点点。
测试可能受网络和负荷的影响，但基本上是这个结果。
Tags - apache , nginx , proxy

baidu Transcoder是什么？

Fri, 06 Aug 2010 14:01:56 +0800

在日志中看到如下信息：

引用

220.181.32.23 - - [06/Aug/2010:13:47:30 +0800] "GET /hx.htm HTTP/1.1" 200 3155 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; baidu Transcoder;)" -
220.181.108.46 - - [06/Aug/2010:13:53:54 +0800] "GET / HTTP/1.1" 200 3216 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; baidu Transcoder;)" -

baidu Transcoder，这是什么？

搜索了下，原来是Baidu对手机用户访问网页时提供实时转换的一个独立服务。

可以参见，百度百科对Transcoder的说明：http://baike.baidu.com/view/2140769.htm

我在手机上使用百度m.baidu.com搜索后，点开的页面就是经过了baidu的Transcoder处理后显示的，以智能的适应手机的版面，并能把大图变小图，节省一些手机上网所占的流量。如查看9enjoy首页：http://gate.baidu.com/tc_path/pn=9/bd_page_type=1/pu=0/t=0/?&m=1155&noopen=1&src=http%3A%2F%2Fwww%2E9enjoy%2Ecom#tc_area_4

有些人说baidu Transcoder是拔毛蜘蛛，显然是不对的。

Tags - baidu , 手机 , 转换

警告: 网页已经过期的解决方法

Thu, 05 Aug 2010 17:29:05 +0800

引用

警告: 网页已经过期您申请的网页是用表单中提交的信息创建的。该网页已失效。由于有安全预警功能，Internet Explorer 不会自动再次提交您的信息。

要重新提交信息并查看该网页，请单击刷新按钮。

此提示出现在一个POST提交的页面，点到其它页面后，再返回时，IE就会显示这个提示。以前也有碰到过好多次，不过都没太在意，今天化时间了解了下，原来是session在作怪。

在通过IE的后退按钮或者网页中的history.go(-1)时，我们看到的将是缓存页，但使用了session_start后，这个函数会强制当前页面不被缓存，导致出现“警告: 网页已经过期”。

解决方法一：
在session_start之后加一句header("Cache-control: private"); 注意在此之前程序不能有任何输出。

解决方法二：
在session_start前加上session_cache_limiter('private'); //不清空表单，只在session生效期间
session_cache_limiter还有另两个参数的含义：
session_cache_limiter('nocache');// 清空表单
session_cache_limiter('public'); //不清空表单，如同没有使用session
Tags - session , 表单

各浏览器(IE6,IE7,IE8,FireFox...)默认CSS

Sat, 31 Jul 2010 09:23:59 +0800

各浏览器的默认CSS原文：http://www.iecss.com/

为以防万一备份了一下，存到了我的空间上了，有时会用得着：http://www.9enjoy.com/code/default-css/

常用浏览器默认样式下载
IE6(下载)
IE7(下载)
IE8(下载)
IE9(下载)
Firefox 3.6.3(下载)

一般写CSS都会在头部会把一些常用的标签重置margin和padding为0，但在某些地方又要恢复原默认的CSS，这些样式就起上作用了：）

Tags - ie , css , firefox

nginx下php(FastCGI)搭配APC实现PHP加速

Thu, 29 Jul 2010 17:06:35 +0800

网上的文章一般介绍nginx+php的安装都使用eaccelerator，其实用APC也很方便。以下是安装手记。

下载最新版APC
wget http://pecl.php.net/get/APC
tar zxf APC-3.1.3p1.tgz
cd APC-3.1.3p1
/usr/local/webserver/php/bin/phpize
./configure --enable-apc --enable-apc-mmap --with-php-config=/usr/local/webserver/php/bin/php-config
提示
Installing shared extensions: /usr/local/webserver/php/lib/php/extensions/no-debug-non-zts-20060613/
在这个目录下生成了一个apc.so文件

修改php.ini
vi /usr/local/webserver/php/etc/php.ini

extension_dir = "./"
修改为
extension_dir = "/usr/local/webserver/php/lib/php/extensions/no-debug-non-zts-20060613/"
再在下面加一句：
extension = apc.so

重载下php的配置文件
/usr/local/webserver/php/sbin/php-fpm reload

列几个常用的配置，一般来说都不用改，除了apc.shm_size这个值，即分配多少内存给APC存储。

apc.shm_size = 30
;每个共享内存块的大小，单位是M

apc.enabled = 1
这是默认配置，1是启用

apc.ttl = 0
; 缓存条目在缓冲区中允许逗留的秒数。0 表示永不超时。建议值为7200~36000

apc.gc_ttl = 3600
; 缓存条目在垃圾回收表中能够存在的秒数。

apc.stat=1

; 是否启用脚本更新检查。改变这个指令值要非常小心。默认值 On 表示APC在每次请求脚本时都检查脚本是否被更新, 如果被更新则自动重新编译和缓存编译后的内容。但这样做对性能有不利影响。如果设为 Off 则表示不进行检查，从而使性能得到大幅提高。但是为了使更新的内容生效，你必须重启Web服务器。
; 这个指令对于include/require的文件同样有效。但是需要注意的是，如果你使用的是相对路径，APC就必须在每一次include/require时都进行检查以定位文件。而使用绝对路径则可以跳过检查，所以建议使用绝对路径进行include/require操作。

更多配置参数请参见：http://cn2.php.net/apc

默认启用的是APC的System Cache功能，以下是PHP使用User Cache的最常用方法

<?php
//$mem_key是键值，$cache_time是缓存时间
$hx_info = apc_fetch($mem_key);
if(!$hx_info){
apc_store($mem_key, $hx_info, $cache_time);
}
?>

Tags - php , apc

Coreseek(Sphinx)遭遇sql_range_query: MySQL server has gone away错误

Mon, 26 Jul 2010 22:20:44 +0800

Coreseek一直运行的好好的，但最近有些搜索不到了，重建次索引也不行。

仔细查看了运行提示，如下

引用

Coreseek Fulltext 3.2 [ Sphinx 0.9.9-release (r2117)]
Copyright (c) 2007-2010,
Beijing Choice Software Technologies Inc (http://www.coreseek.com)

using config file '/usr/local/coreseek/etc/csft.conf'...
indexing index 'hx_line'...
ERROR: index 'hx_line': sql_range_query: MySQL server has gone away (DSN=mysql://root:***@localhost:3306/hx_db).
total 302579 docs, 14798361 bytes
total 33.659 sec, 439652 bytes/sec, 8989.49 docs/sec
total 0 reads, 0.000 sec, 0.0 kb/call avg, 0.0 msec/call avg
total 242 writes, 0.572 sec, 1021.9 kb/call avg, 2.3 msec/call avg

错误提示是这个：

引用

sql_range_query: MySQL server has gone away

在SE中搜索未果，看来没人碰上过这问题啊！

我是有使用sphinx的分区查询功能，设置了sql_range_step和sql_ranged_throttle。尝试调整这两个参数运行，但都不行。
每次都是索引到30w的文档时，卡住约10多秒，然后就显示上面的内容了。

想到我的mysql的配置有设置超时时间，应该是这个配置影响了它吧。
wait_timeout=8
interactive_timeout=8
在csft.conf中，加入
sql_query_pre= set session wait_timeout = 60;
sql_query_pre= set session interactive_timeout=60;
后，运行bin/indexer hx_line --rotate

同样运行到30w之后，停住了约十几秒，然后又继续了:)
问题解决了！

那么为什么运行到30w时会卡住呢？猜测是我设置的mem_limit=512M的问题，难道是设置太小了？再仔细看了文档，找到答案了

引用

mem_limit 索引过程内存使用限制.可选选项,默认 32M. 这是 indexer 不会超越的强制内存限制.可以以字节,千字节(以 K 为后缀)或兆字节(以 M 为后缀)为单位.参见示例.当过小的值导致 I/O 缓冲低于 8KB 时该限制会自动提高,此值的最低限度依赖于待索引数据的大小.如果缓冲低于 256KB,会产生警告. 最大可能的限制是 2047M.太低的值会影响索引速度,但 256M 到 1024M 对绝大多数数据集(如果不是全部)来说应该足够了.这个值设得太高可能导致 SQL 服务器连接超时.在文档收集阶段,有时内存缓冲的一部分会被排序,而与数据库的通信会暂停,于是数据库服务器可能超时.这可以通过提高 SQL 服务器端的超时时间或降低 mem_limit 来解决.

原来居然是因为mem_limit这个值设高了。。。！在文档收集阶段，有时内存缓冲的一部分会被排序，而与数据库的通信会暂停，所以看到了运行到30w时卡住的情况，然后化了十几秒，超过了我设置的8s的限制，所以报MySQL server has gone away了。

Tags - sphinx , coreseek , timeout

ping IP遭遇TTL expired in transit.

Mon, 19 Jul 2010 22:37:14 +0800

广东群英机房晚上出问题，应该不少于百台服务器受影响。症状是ping 域名或IP，提示：TTL expired in transit

121.10.140.44是我随便测试的一个IP

Pinging 121.10.140.44 with 32 bytes of data:

Reply from 59.34.122.90: TTL expired in transit.
Reply from 59.34.122.90: TTL expired in transit.
Reply from 59.34.122.90: TTL expired in transit.

试了140和141网段的很多个Ip，都是这个返回结果，应该是所有都这样了。TTL expired in transit.我倒是第一次看到，看英文意思似乎是说TTL在传输过程中过期了。

tracert 121.10.140.44

引用

Tracing route to 121.10.140.44 over a maximum of 30 hops

  1    33 ms    29 ms    29 ms  1.184.77.125.board.xm.fj.dynamic.163data.com.cn
[125.77.184.1]
  2    16 ms    15 ms    15 ms  218.85.151.97
  3    15 ms    15 ms    15 ms  61.154.238.37
  4    14 ms    15 ms    17 ms  61.154.236.2
  5    31 ms    31 ms    29 ms  202.97.40.194
  6    33 ms    33 ms    33 ms  59.34.122.213
  7    32 ms    33 ms    33 ms  125.90.92.138
  8    36 ms    33 ms    33 ms  119.146.112.106
  9    34 ms    31 ms    33 ms  59.34.122.105
10    30 ms    31 ms    31 ms  59.34.122.90
11    33 ms    33 ms    33 ms  59.34.122.105
12    30 ms    35 ms    31 ms  59.34.122.90
13    32 ms    33 ms    31 ms  59.34.122.105
14    31 ms    31 ms    31 ms  59.34.122.90
15    32 ms    33 ms    33 ms  59.34.122.105
16    30 ms    31 ms    31 ms  59.34.122.90
17    34 ms    33 ms    33 ms  59.34.122.105
18    30 ms    33 ms    33 ms  59.34.122.90

很容易看出59.34.122.105和59.34.122.90死循环了...

查了下出现TTL expired in transit的原因有两个：

1）TTL值太小！TTL值小于你和对方主机之间经过的路由器数目。

2）路由器数量太多，经过路由器的数量大于TTL值！

第1点，原来是正常的，排除。就是第2点原因了。

这样看来不是机房就是电信的问题，看了下网站统计，全无，排除电信的问题，应该是机房的哪里设置问题。

哎，只能等待解决了。

@@update，大约在出问题的1个半小时后，问题解决。
@@update，群英VIP服务 23:45:43
2010-7-19 21:20 我司汇聚层路由设备出现故障，导致网络出现中断，现已处理完毕。
故障历时75分钟.
Tags - ttl , ping