基于HTTP协议的开源中文分词系统:HTTPCWS 1.0.0 发布[原创]
[ 2009-8-11 08:45 | by 张宴 ]
发布版本:
httpcws 1.0.0 (最新版本:2009-08-10发布)
程序网址:http://code.google.com/p/httpcws
安装使用手册:http://blog.zyan.cc/httpcws_v100/
下载地址(32位版):http://httpcws.googlecode.com/files/httpcws-1.0.0-i386-bin.tar.gz
下载地址(64位版):http://httpcws.googlecode.com/files/httpcws-1.0.0-x86_64-bin.tar.gz
中文分词在线演示:http://blog.zyan.cc/demo/httpcws/
PHP演示程序下载:http://blog.zyan.cc/demo/httpcws/httpcws-php-demo.zip
httpcws 中文简介
1、什么是 httpcws ?
HTTPCWS 是一款基于HTTP协议的开源中文分词系统,目前仅支持Linux系统。HTTPCWS 使用“ICTCLAS 3.0 2009共享版中文分词算法”的API进行分词处理,得出分词结果。HTTPCWS 将取代本人之前开发的 PHPCWS 中文分词扩展。
ICTCLAS(Institute of Computing Technology, Chinese Lexical Analysis System)是中国科学院计算技术研究所在多年研究工作积累的基础上,基于多层隐马模型研制出的汉语词法分析系统,主要功能包括中文分词;词性标注;命名实体识别;新词识别;同时支持用户词典。ICTCLAS经过五年精心打造,内核升级6次,目前已经升级到了ICTCLAS3.0,分词精度98.45%,各种词典数据压缩后不到3M。ICTCLAS在国内973专家组组织的评测中活动获得了第一名,在第一届国际中文处理研究机构SigHan组织的评测中都获得了多项第一名,是当前世界上最好的汉语词法分析器。
ICTCLAS 3.0 商业版是收费的,而免费提供的 ICTCLAS 3.0 共享版不开源,词库是根据人民日报一个月的语料得出的,很多词语不存在。所以本人补充的一个19万条词语的自定义词库,对ICTCLAS分词结果进行合并处理,输出最终分词结果。
由于 ICTCLAS 3.0 2009 共享版只支持GBK编码,因此,如果是UTF-8编码的字符串,可以先用iconv函数转换成GBK编码,再用httpcws进行分词处理,最后转换回UTF-8编码。
HTTPCWS 软件自身(包括httpcws.cpp源文件、dict/httpcws_dict.txt自定义词库)采用NewBSD开源协议,可以自由修改。HTTPCWS 使用的 ICTCLAS 共享版 API 及 dict/Data/ 目录内的语料库,版权及著作权归中国科学院计算技术研究所、ictclas.org所有,使用需遵循其相关协议。
2、httpcws 中文分词在线演示
演示网址:http://blog.zyan.cc/demo/httpcws/
3、httpcws 中文分词下载安装
32位版:
64位版:
命令行启动参数:
4、httpcws 使用方法
GET方法(文本长度受URL的长度限制,需要分词的文本为GBK编码,最好采用urlencode对文本进行编码):
POST方法(文本长度无限制,适用于大文本分词,需要分词的文本为GBK编码,最好采用urlencode对文本进行编码):
PHP 调用 HTTPCWS 示例:
①、对GBK编码的字符串进行中文分词处理(HTTP POST方式):
httpcws 1.0.0 (最新版本:2009-08-10发布)
程序网址:http://code.google.com/p/httpcws
安装使用手册:http://blog.zyan.cc/httpcws_v100/
下载地址(32位版):http://httpcws.googlecode.com/files/httpcws-1.0.0-i386-bin.tar.gz
下载地址(64位版):http://httpcws.googlecode.com/files/httpcws-1.0.0-x86_64-bin.tar.gz
中文分词在线演示:http://blog.zyan.cc/demo/httpcws/
PHP演示程序下载:http://blog.zyan.cc/demo/httpcws/httpcws-php-demo.zip
httpcws 中文简介
1、什么是 httpcws ?
HTTPCWS 是一款基于HTTP协议的开源中文分词系统,目前仅支持Linux系统。HTTPCWS 使用“ICTCLAS 3.0 2009共享版中文分词算法”的API进行分词处理,得出分词结果。HTTPCWS 将取代本人之前开发的 PHPCWS 中文分词扩展。
ICTCLAS(Institute of Computing Technology, Chinese Lexical Analysis System)是中国科学院计算技术研究所在多年研究工作积累的基础上,基于多层隐马模型研制出的汉语词法分析系统,主要功能包括中文分词;词性标注;命名实体识别;新词识别;同时支持用户词典。ICTCLAS经过五年精心打造,内核升级6次,目前已经升级到了ICTCLAS3.0,分词精度98.45%,各种词典数据压缩后不到3M。ICTCLAS在国内973专家组组织的评测中活动获得了第一名,在第一届国际中文处理研究机构SigHan组织的评测中都获得了多项第一名,是当前世界上最好的汉语词法分析器。
ICTCLAS 3.0 商业版是收费的,而免费提供的 ICTCLAS 3.0 共享版不开源,词库是根据人民日报一个月的语料得出的,很多词语不存在。所以本人补充的一个19万条词语的自定义词库,对ICTCLAS分词结果进行合并处理,输出最终分词结果。
由于 ICTCLAS 3.0 2009 共享版只支持GBK编码,因此,如果是UTF-8编码的字符串,可以先用iconv函数转换成GBK编码,再用httpcws进行分词处理,最后转换回UTF-8编码。
HTTPCWS 软件自身(包括httpcws.cpp源文件、dict/httpcws_dict.txt自定义词库)采用NewBSD开源协议,可以自由修改。HTTPCWS 使用的 ICTCLAS 共享版 API 及 dict/Data/ 目录内的语料库,版权及著作权归中国科学院计算技术研究所、ictclas.org所有,使用需遵循其相关协议。
2、httpcws 中文分词在线演示
演示网址:http://blog.zyan.cc/demo/httpcws/
3、httpcws 中文分词下载安装
32位版:
cd /usr/local/
wget http://httpcws.googlecode.com/files/httpcws-1.0.0-i386-bin.tar.gz
tar zxvf httpcws-1.0.0-i386-bin.tar.gz
rm -f httpcws-1.0.0-i386-bin.tar.gz
cd httpcws-1.0.0-i386-bin/
ulimit -SHn 65535
/usr/local/httpcws-1.0.0-i386-bin/httpcws -d -x /usr/local/httpcws-1.0.0-i386-bin/dict/
wget http://httpcws.googlecode.com/files/httpcws-1.0.0-i386-bin.tar.gz
tar zxvf httpcws-1.0.0-i386-bin.tar.gz
rm -f httpcws-1.0.0-i386-bin.tar.gz
cd httpcws-1.0.0-i386-bin/
ulimit -SHn 65535
/usr/local/httpcws-1.0.0-i386-bin/httpcws -d -x /usr/local/httpcws-1.0.0-i386-bin/dict/
64位版:
cd /usr/local/
wget http://httpcws.googlecode.com/files/httpcws-1.0.0-x86_64-bin.tar.gz
tar zxvf httpcws-1.0.0-x86_64-bin.tar.gz
rm -f httpcws-1.0.0-x86_64-bin.tar.gz
cd httpcws-1.0.0-x86_64-bin/
ulimit -SHn 65535
/usr/local/httpcws-1.0.0-x86_64-bin/httpcws -d -x /usr/local/httpcws-1.0.0-x86_64-bin/dict/
wget http://httpcws.googlecode.com/files/httpcws-1.0.0-x86_64-bin.tar.gz
tar zxvf httpcws-1.0.0-x86_64-bin.tar.gz
rm -f httpcws-1.0.0-x86_64-bin.tar.gz
cd httpcws-1.0.0-x86_64-bin/
ulimit -SHn 65535
/usr/local/httpcws-1.0.0-x86_64-bin/httpcws -d -x /usr/local/httpcws-1.0.0-x86_64-bin/dict/
命令行启动参数:
4、httpcws 使用方法
GET方法(文本长度受URL的长度限制,需要分词的文本为GBK编码,最好采用urlencode对文本进行编码):
http://192.168.8.42:1985/?w=有人的地方就有江湖
http://192.168.8.42:1985/?w=%D3%D0%C8%CB%B5%C4%B5%D8%B7%BD%BE%CD%D3%D0%BD%AD%BA%FE
http://192.168.8.42:1985/?w=%D3%D0%C8%CB%B5%C4%B5%D8%B7%BD%BE%CD%D3%D0%BD%AD%BA%FE
POST方法(文本长度无限制,适用于大文本分词,需要分词的文本为GBK编码,最好采用urlencode对文本进行编码):
curl -d "有人的地方就有江湖" http://192.168.8.42:1985
curl -d "%D3%D0%C8%CB%B5%C4%B5%D8%B7%BD%BE%CD%D3%D0%BD%AD%BA%FE" http://192.168.8.42:1985
curl -d "%D3%D0%C8%CB%B5%C4%B5%D8%B7%BD%BE%CD%D3%D0%BD%AD%BA%FE" http://192.168.8.42:1985
PHP 调用 HTTPCWS 示例:
①、对GBK编码的字符串进行中文分词处理(HTTP POST方式):
<?php
@header('Content-Type: text/html; charset=gb2312');
$text = "有人的地方就有江湖";
$text = urlencode($text);
$opts = array(
'http'=>array(
'method'=>"POST",
'header'=>"Content-type: application/x-www-form-urlencoded\r\n".
"Content-length:".strlen($data)."\r\n" .
"Cookie: foo=bar\r\n" .
"\r\n",
'content' => $text,
)
);
$context = stream_context_create($opts);
$result = file_get_contents("http://127.0.0.1:1985", false, $context);
echo $result;
?>
@header('Content-Type: text/html; charset=gb2312');
$text = "有人的地方就有江湖";
$text = urlencode($text);
$opts = array(
'http'=>array(
'method'=>"POST",
'header'=>"Content-type: application/x-www-form-urlencoded\r\n".
"Content-length:".strlen($data)."\r\n" .
"Cookie: foo=bar\r\n" .
"\r\n",
'content' => $text,
)
);
$context = stream_context_create($opts);
$result = file_get_contents("http://127.0.0.1:1985", false, $context);
echo $result;
?>
Linux C/C++ 内存泄漏检测工具:Valgrind
[ 2009-7-31 21:01 | by 张宴 ]
Valgrind 是一款 Linux下(支持 x86、x86_64和ppc32)程序的内存调试工具,它可以对编译后的二进制程序进行内存使用监测(C语言中的malloc和free,以及C++中的new和delete),找出内存泄漏问题。
Valgrind 中包含的 Memcheck 工具可以检查以下的程序错误:
使用未初始化的内存 (Use of uninitialised memory)
使用已经释放了的内存 (Reading/writing memory after it has been free’d)
使用超过malloc分配的内存空间(Reading/writing off the end of malloc’d blocks)
对堆栈的非法访问 (Reading/writing inappropriate areas on the stack)
申请的空间是否有释放 (Memory leaks – where pointers to malloc’d blocks are lost forever)
malloc/free/new/delete申请和释放内存的匹配(Mismatched use of malloc/new/new [] vs free/delete/delete [])
src和dst的重叠(Overlapping src and dst pointers in memcpy() and related functions)
重复free
1、编译安装 Valgrind:
2、使用示例:对“ls”程序进程检查,返回结果中的“definitely lost: 0 bytes in 0 blocks.”表示没有内存泄漏。
3、使用示例:对一个使用libevent库编写的“httptest”程序进程检查,返回结果中的“definitely lost: 255 bytes in 5 blocks.”表示发生内存泄漏。
检查httptest程序,发现有一处“char *decode_uri = evhttp_decode_uri(evhttp_request_uri(req));”中的“decode_uri”没有被free,再程序处理完成后加上“free(decode_uri);”后,再使用Valgrind检查,结果已经是“definitely lost: 0 bytes in 0 blocks.”。
Valgrind 中包含的 Memcheck 工具可以检查以下的程序错误:
使用未初始化的内存 (Use of uninitialised memory)
使用已经释放了的内存 (Reading/writing memory after it has been free’d)
使用超过malloc分配的内存空间(Reading/writing off the end of malloc’d blocks)
对堆栈的非法访问 (Reading/writing inappropriate areas on the stack)
申请的空间是否有释放 (Memory leaks – where pointers to malloc’d blocks are lost forever)
malloc/free/new/delete申请和释放内存的匹配(Mismatched use of malloc/new/new [] vs free/delete/delete [])
src和dst的重叠(Overlapping src and dst pointers in memcpy() and related functions)
重复free
1、编译安装 Valgrind:
wget http://valgrind.org/downloads/valgrind-3.4.1.tar.bz2
tar xvf valgrind-3.4.1.tar.bz2
cd valgrind-3.4.1/
./configure --prefix=/usr/local/webserver/valgrind
make
make install
tar xvf valgrind-3.4.1.tar.bz2
cd valgrind-3.4.1/
./configure --prefix=/usr/local/webserver/valgrind
make
make install
2、使用示例:对“ls”程序进程检查,返回结果中的“definitely lost: 0 bytes in 0 blocks.”表示没有内存泄漏。
[root@xoyo42 /]# /usr/local/webserver/valgrind/bin/valgrind --tool=memcheck --leak-check=full ls /
==1157== Memcheck, a memory error detector.
==1157== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==1157== Using LibVEX rev 1884, a library for dynamic binary translation.
==1157== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==1157== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==1157== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==1157== For more details, rerun with: -v
==1157==
bin data0 dev home lib64 media mnt opt root selinux sys tcsql.db.idx.pkey.dec ttserver.pid var
boot data1 etc lib lost+found misc net proc sbin srv tcsql.db tmp usr
==1157==
==1157== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1)
==1157== malloc/free: in use at exit: 28,471 bytes in 36 blocks.
==1157== malloc/free: 166 allocs, 130 frees, 51,377 bytes allocated.
==1157== For counts of detected errors, rerun with: -v
==1157== searching for pointers to 36 not-freed blocks.
==1157== checked 174,640 bytes.
==1157==
==1157== LEAK SUMMARY:
==1157== definitely lost: 0 bytes in 0 blocks.
==1157== possibly lost: 0 bytes in 0 blocks.
==1157== still reachable: 28,471 bytes in 36 blocks.
==1157== suppressed: 0 bytes in 0 blocks.
==1157== Reachable blocks (those to which a pointer was found) are not shown.
==1157== To see them, rerun with: --leak-check=full --show-reachable=yes
==1157== Memcheck, a memory error detector.
==1157== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==1157== Using LibVEX rev 1884, a library for dynamic binary translation.
==1157== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==1157== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==1157== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==1157== For more details, rerun with: -v
==1157==
bin data0 dev home lib64 media mnt opt root selinux sys tcsql.db.idx.pkey.dec ttserver.pid var
boot data1 etc lib lost+found misc net proc sbin srv tcsql.db tmp usr
==1157==
==1157== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1)
==1157== malloc/free: in use at exit: 28,471 bytes in 36 blocks.
==1157== malloc/free: 166 allocs, 130 frees, 51,377 bytes allocated.
==1157== For counts of detected errors, rerun with: -v
==1157== searching for pointers to 36 not-freed blocks.
==1157== checked 174,640 bytes.
==1157==
==1157== LEAK SUMMARY:
==1157== definitely lost: 0 bytes in 0 blocks.
==1157== possibly lost: 0 bytes in 0 blocks.
==1157== still reachable: 28,471 bytes in 36 blocks.
==1157== suppressed: 0 bytes in 0 blocks.
==1157== Reachable blocks (those to which a pointer was found) are not shown.
==1157== To see them, rerun with: --leak-check=full --show-reachable=yes
3、使用示例:对一个使用libevent库编写的“httptest”程序进程检查,返回结果中的“definitely lost: 255 bytes in 5 blocks.”表示发生内存泄漏。
[root@xoyo42 tcsql-0.1]# /usr/local/webserver/valgrind/bin/valgrind --tool=memcheck --leak-check=full ./httptest
==1274== Memcheck, a memory error detector.
==1274== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==1274== Using LibVEX rev 1884, a library for dynamic binary translation.
==1274== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==1274== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==1274== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==1274== For more details, rerun with: -v
==1274==
==1274== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1005 from 2)
==1274== malloc/free: in use at exit: 402,291 bytes in 74 blocks.
==1274== malloc/free: 15,939 allocs, 15,865 frees, 6,281,523 bytes allocated.
==1274== For counts of detected errors, rerun with: -v
==1274== searching for pointers to 74 not-freed blocks.
==1274== checked 682,468,160 bytes.
==1274==
==1274== 255 bytes in 5 blocks are definitely lost in loss record 17 of 32
==1274== at 0x4A05FBB: malloc (vg_replace_malloc.c:207)
==1274== by 0x3C1D809BC6: evhttp_decode_uri (http.c:2105)
==1274== by 0x401C75: tcsql_handler (in /data0/tcsql/cankao/tcsql-0.1/tcsql)
==1274== by 0x3C1D80C88F: evhttp_get_body (http.c:1582)
==1274== by 0x3C1D8065F7: event_base_loop (event.c:392)
==1274== by 0x403E2F: main (in /data0/tcsql/cankao/tcsql-0.1/tcsql)
==1274==
==1274== LEAK SUMMARY:
==1274== definitely lost: 255 bytes in 5 blocks.
==1274== possibly lost: 0 bytes in 0 blocks.
==1274== still reachable: 402,036 bytes in 69 blocks.
==1274== suppressed: 0 bytes in 0 blocks.
==1274== Reachable blocks (those to which a pointer was found) are not shown.
==1274== To see them, rerun with: --leak-check=full --show-reachable=yes
==1274== Memcheck, a memory error detector.
==1274== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==1274== Using LibVEX rev 1884, a library for dynamic binary translation.
==1274== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==1274== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==1274== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==1274== For more details, rerun with: -v
==1274==
==1274== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1005 from 2)
==1274== malloc/free: in use at exit: 402,291 bytes in 74 blocks.
==1274== malloc/free: 15,939 allocs, 15,865 frees, 6,281,523 bytes allocated.
==1274== For counts of detected errors, rerun with: -v
==1274== searching for pointers to 74 not-freed blocks.
==1274== checked 682,468,160 bytes.
==1274==
==1274== 255 bytes in 5 blocks are definitely lost in loss record 17 of 32
==1274== at 0x4A05FBB: malloc (vg_replace_malloc.c:207)
==1274== by 0x3C1D809BC6: evhttp_decode_uri (http.c:2105)
==1274== by 0x401C75: tcsql_handler (in /data0/tcsql/cankao/tcsql-0.1/tcsql)
==1274== by 0x3C1D80C88F: evhttp_get_body (http.c:1582)
==1274== by 0x3C1D8065F7: event_base_loop (event.c:392)
==1274== by 0x403E2F: main (in /data0/tcsql/cankao/tcsql-0.1/tcsql)
==1274==
==1274== LEAK SUMMARY:
==1274== definitely lost: 255 bytes in 5 blocks.
==1274== possibly lost: 0 bytes in 0 blocks.
==1274== still reachable: 402,036 bytes in 69 blocks.
==1274== suppressed: 0 bytes in 0 blocks.
==1274== Reachable blocks (those to which a pointer was found) are not shown.
==1274== To see them, rerun with: --leak-check=full --show-reachable=yes
检查httptest程序,发现有一处“char *decode_uri = evhttp_decode_uri(evhttp_request_uri(req));”中的“decode_uri”没有被free,再程序处理完成后加上“free(decode_uri);”后,再使用Valgrind检查,结果已经是“definitely lost: 0 bytes in 0 blocks.”。
稳定的NTP时间同步服务器集群:ntp.api.bz[原创]
[ 2009-7-16 22:54 | by 张宴 ]
[文章作者:张宴 本文版本:v1.0 最后修改:2009.07.16 转载请注明原文链接:http://blog.zyan.cc/ntp_api_bz/]
NTP(Network Time Protocol)是由美国德拉瓦大学的David L. Mills教授于1985年提出,除了可以估算封包在网络上的往返延迟外,还可独立地估算计算机时钟偏差,从而实现在网络上的高精准度计算机校时,它是设计用来在Internet上使不同的机器能维持相同时间的一种通讯协定。时间服务器(time server)是利用NTP的一种服务器,通过它可以使网络中的机器维持时间同步。在大多数的地方,NTP可以提供1-50ms的可信赖性的同步时间源和网络工作路径。
网络时间协议(NTP)的详细说明在RFC-1305[Mills 1992]中。RFC-1305对 NTP协议自动机在事件、状态、转变功能和行为方面给出了明确的说明。它以合适的算法以增强时钟的准确性,并且减轻多个由于同步源而产生的差错,实现了准确性低于毫秒的时间服务,以满足目前因特网中路径量测的需要。
ntp.api.bz 是一组NTP服务器集群,目前有6台服务器,位于上海电信。这项服务是 api.bz 继 http://sms.api.bz 移动飞信免费短信发送接口之后的第二项免费 API 服务。
客户端设置:
1、Linux服务器可通过 ntpdate 命令与时间服务器同步(如果没有安装ntp软件,CentOS可以通过“yum install ntp”命令安装):
如果想定时执行ntpdate进行时间同步,可以通过crontab来进行:
输入以下内容,每小时的第19分钟做一次时间同步:
2、Windows服务器或个人电脑请用鼠标双击屏幕右下角的时间,按照下图设置:
点击“立即更新”就可以马上更新时间,响应速度与成功率要比原有的 time.windows.com 高得多。
NTP(Network Time Protocol)是由美国德拉瓦大学的David L. Mills教授于1985年提出,除了可以估算封包在网络上的往返延迟外,还可独立地估算计算机时钟偏差,从而实现在网络上的高精准度计算机校时,它是设计用来在Internet上使不同的机器能维持相同时间的一种通讯协定。时间服务器(time server)是利用NTP的一种服务器,通过它可以使网络中的机器维持时间同步。在大多数的地方,NTP可以提供1-50ms的可信赖性的同步时间源和网络工作路径。
网络时间协议(NTP)的详细说明在RFC-1305[Mills 1992]中。RFC-1305对 NTP协议自动机在事件、状态、转变功能和行为方面给出了明确的说明。它以合适的算法以增强时钟的准确性,并且减轻多个由于同步源而产生的差错,实现了准确性低于毫秒的时间服务,以满足目前因特网中路径量测的需要。
ntp.api.bz 是一组NTP服务器集群,目前有6台服务器,位于上海电信。这项服务是 api.bz 继 http://sms.api.bz 移动飞信免费短信发送接口之后的第二项免费 API 服务。
客户端设置:
1、Linux服务器可通过 ntpdate 命令与时间服务器同步(如果没有安装ntp软件,CentOS可以通过“yum install ntp”命令安装):
/usr/sbin/ntpdate ntp.api.bz
如果想定时执行ntpdate进行时间同步,可以通过crontab来进行:
crontab -e
输入以下内容,每小时的第19分钟做一次时间同步:
19 * * * * /usr/sbin/ntpdate ntp.api.bz
2、Windows服务器或个人电脑请用鼠标双击屏幕右下角的时间,按照下图设置:
点击“立即更新”就可以马上更新时间,响应速度与成功率要比原有的 time.windows.com 高得多。
我的微博客暂时由饭否迁移到twitter
[ 2009-7-12 23:07 | by 张宴 ]
饭否被和谐了,我的微博客由饭否移到美国佬的地盘。被GFW还可以翻墙,总比信息丢失好。
设置hosts文件:C:\windows\system32\drivers\etc\hosts
浏览器通过 https://twitter.com/ 访问。
不设置hosts,则可以通过 http://www.itweet.net/web/ 等网站访问。
手机可通过 http://dabr.co.uk 访问。
我的twitter:https://twitter.com/rewinx 或 http://twitter.com/rewinx
设置hosts文件:C:\windows\system32\drivers\etc\hosts
引用
128.121.146.228 twitter.com
168.143.162.101 assets1.twitter.com
168.143.162.101 static.twitter.com
168.143.162.101 assets0.twitter.com
168.143.162.101 assets2.twitter.com
168.143.162.101 assets3.twitter.com
168.143.162.101 assets4.twitter.com
168.143.162.101 assets1.twitter.com
168.143.162.101 static.twitter.com
168.143.162.101 assets0.twitter.com
168.143.162.101 assets2.twitter.com
168.143.162.101 assets3.twitter.com
168.143.162.101 assets4.twitter.com
浏览器通过 https://twitter.com/ 访问。
不设置hosts,则可以通过 http://www.itweet.net/web/ 等网站访问。
手机可通过 http://dabr.co.uk 访问。
我的twitter:https://twitter.com/rewinx 或 http://twitter.com/rewinx
实例:Linux EXT3文件系统下成功恢复误删的文件[原创]
[ 2009-7-6 00:46 | by 张宴 ]
[文章作者:张宴 本文版本:v1.0 最后修改:2009.07.06 转载请注明原文链接:http://blog.zyan.cc/linux_ext3_undelete/]
环境:CentOS 5.3 x86_64下,/dev/sdb1为数据分区/data0,EXT3文件系统。
前因:误删了/data0/tcsql/cankao/phpcws-1.5.0/httpcws.cpp文件。由于忘了备份httpcws.cpp文件,重新开发工作量较大,因此只有恢复该文件一条路可走。
debugfs命令针对EXT2分区还行,但对EXT3分区就帮不上忙了。偶然发现的一款开源软件,解决了我的大忙。该软件下载网址为:
http://code.google.com/p/ext3grep/
1、先安装ext3grep软件:
2、umount /data0分区:
如果提示busy,先kill正在使用这个目录的进程,再umount:
3、查询所有Inode,(执行需要几分钟~十多分钟):
4、逐级查找Inode,看是否能找到httpcws.cpp文件(此步骤也可省略):
环境:CentOS 5.3 x86_64下,/dev/sdb1为数据分区/data0,EXT3文件系统。
前因:误删了/data0/tcsql/cankao/phpcws-1.5.0/httpcws.cpp文件。由于忘了备份httpcws.cpp文件,重新开发工作量较大,因此只有恢复该文件一条路可走。
debugfs命令针对EXT2分区还行,但对EXT3分区就帮不上忙了。偶然发现的一款开源软件,解决了我的大忙。该软件下载网址为:
http://code.google.com/p/ext3grep/
1、先安装ext3grep软件:
wget http://ext3grep.googlecode.com/files/ext3grep-0.10.1.tar.gz
tar zxvf ext3grep-0.10.1.tar.gz
cd ext3grep-0.10.1
./configure
make
make install
tar zxvf ext3grep-0.10.1.tar.gz
cd ext3grep-0.10.1
./configure
make
make install
2、umount /data0分区:
umount /data0
如果提示busy,先kill正在使用这个目录的进程,再umount:
fuser -k /data0
umount /data0
umount /data0
3、查询所有Inode,(执行需要几分钟~十多分钟):
ext3grep /dev/sdb1 --ls --inode 2
4、逐级查找Inode,看是否能找到httpcws.cpp文件(此步骤也可省略):
“惠普Proliant DL380 G4服务器”挂接“惠普Modular Smart Array 500G2磁盘阵列柜”[原创]
[ 2009-6-17 16:54 | by 张宴 ]
[文章作者:张宴 本文版本:v1.0 最后修改:2009.06.17 转载请注明原文链接:http://blog.zyan.cc/post/415/]
正为视频、图片存储发愁,一个偶然的机会,获知公司在廊坊机房机架上有一台“300GB*14块硬盘”磁盘整列柜,竟然没人使用。周一申请了一辆公司的车,去廊坊机房将该盘阵拖了回来。
环境:
一台“惠普Proliant DL380 G4服务器(2U机架式)”,已安装CentOS 5.3 64位操作系统;
一台“惠普Modular Smart Array 500G2磁盘阵列柜”,插满14块标称300GB的SCSI硬盘;
一块“惠普 Smart Array 642阵列卡”,插在“惠普Proliant DL380 G4服务器”;
一根SCSI连接线,连接“惠普 Smart Array 642阵列卡”和“惠普Modular Smart Array 500G2磁盘阵列柜”。
配置步骤:
1、在“惠普Proliant DL380 G4服务器”PCI插槽中安装一块Smart Array 642阵列卡,用SCSI线连接“惠普MSA 500G2磁盘阵列柜”。
2、在以下网址点击右侧“Support”栏目中的“Support matrices”,查看“HP Proliant DL380 G4服务器”支持的“HP SmartStart CD光盘类型”:
http://www.hp.com/servers/smartstart
3、通过以下网址下载 HP SmartStart 8.25 x64 光盘,解压后有一个ISO镜像文件,将它刻录到CD刻录光盘上:
ftp://ftp.hp.com/pub/softlib2/software1/cd/p1760479716/v51549/smartstart-8.25-0-x64.zip
4、将SmartStart光盘插入“惠普Proliant DL380 G4服务器”的光驱,选择服务器开机从光盘启动,在光盘引导后的图像界面“Array Configuration Utility”中,会显示所有的磁盘阵列卡,包括“惠普Proliant DL380 G4服务器”自带的阵列卡和“惠普MSA 500G2磁盘阵列柜”的阵列卡。
(1)、点击选择“MSA 500G2”阵列卡。先选择创建磁盘组(Create Array),14块硬盘全选上;
(2)、再选择创建逻辑盘(Create Logical Drive)。因为这里插了14块标称300GB的SCSI硬盘(实际容量(300GB / 1.024 / 1.024 / 1.024) * 14 / 1024 ≈ 3.8TB),而“惠普MSA 500G2磁盘阵列柜”的每块逻辑盘最大只能支持2TB的数据容量,所以至少需要创建两块逻辑盘,第一块逻辑盘选择2TB,第二块逻辑盘使用默认值,即剩余大小。每块逻辑盘可选择做RAID 0、RAID 1、RAID 5和RAID 6,缺省配置是RAID 6(可损坏任意两颗硬盘,但性能比RAID 5略低8%~15%)。因为是图形界面,这一部分操作比较简单,就不再详细描述。
5、使用SmartStart光盘创建完逻辑盘之后,重启“惠普Proliant DL380 G4服务器”。
6、重启后,输入root帐号密码登入CentOS 5.3 x86_64系统。
正为视频、图片存储发愁,一个偶然的机会,获知公司在廊坊机房机架上有一台“300GB*14块硬盘”磁盘整列柜,竟然没人使用。周一申请了一辆公司的车,去廊坊机房将该盘阵拖了回来。
环境:
一台“惠普Proliant DL380 G4服务器(2U机架式)”,已安装CentOS 5.3 64位操作系统;
一台“惠普Modular Smart Array 500G2磁盘阵列柜”,插满14块标称300GB的SCSI硬盘;
一块“惠普 Smart Array 642阵列卡”,插在“惠普Proliant DL380 G4服务器”;
一根SCSI连接线,连接“惠普 Smart Array 642阵列卡”和“惠普Modular Smart Array 500G2磁盘阵列柜”。
配置步骤:
1、在“惠普Proliant DL380 G4服务器”PCI插槽中安装一块Smart Array 642阵列卡,用SCSI线连接“惠普MSA 500G2磁盘阵列柜”。
2、在以下网址点击右侧“Support”栏目中的“Support matrices”,查看“HP Proliant DL380 G4服务器”支持的“HP SmartStart CD光盘类型”:
http://www.hp.com/servers/smartstart
3、通过以下网址下载 HP SmartStart 8.25 x64 光盘,解压后有一个ISO镜像文件,将它刻录到CD刻录光盘上:
ftp://ftp.hp.com/pub/softlib2/software1/cd/p1760479716/v51549/smartstart-8.25-0-x64.zip
4、将SmartStart光盘插入“惠普Proliant DL380 G4服务器”的光驱,选择服务器开机从光盘启动,在光盘引导后的图像界面“Array Configuration Utility”中,会显示所有的磁盘阵列卡,包括“惠普Proliant DL380 G4服务器”自带的阵列卡和“惠普MSA 500G2磁盘阵列柜”的阵列卡。
(1)、点击选择“MSA 500G2”阵列卡。先选择创建磁盘组(Create Array),14块硬盘全选上;
(2)、再选择创建逻辑盘(Create Logical Drive)。因为这里插了14块标称300GB的SCSI硬盘(实际容量(300GB / 1.024 / 1.024 / 1.024) * 14 / 1024 ≈ 3.8TB),而“惠普MSA 500G2磁盘阵列柜”的每块逻辑盘最大只能支持2TB的数据容量,所以至少需要创建两块逻辑盘,第一块逻辑盘选择2TB,第二块逻辑盘使用默认值,即剩余大小。每块逻辑盘可选择做RAID 0、RAID 1、RAID 5和RAID 6,缺省配置是RAID 6(可损坏任意两颗硬盘,但性能比RAID 5略低8%~15%)。因为是图形界面,这一部分操作比较简单,就不再详细描述。
5、使用SmartStart光盘创建完逻辑盘之后,重启“惠普Proliant DL380 G4服务器”。
6、重启后,输入root帐号密码登入CentOS 5.3 x86_64系统。
从“军事战争”总结了一些服务器架构思考[原创]
[ 2009-5-28 15:31 | by 张宴 ]
[文章作者:张宴 本文版本:v1.0 最后修改:2009.05.28 转载请注明原文链接:http://blog.zyan.cc/post/414/]
“客户端访问”与“服务器端响应”,犹如一场战争。初期,访问量较小,弄几台服务器随便拉起一只队伍,就能抵抗住客户端的进攻。慢慢的,访问量大起来,这时候,就需要讲究排兵布阵、战略战术、多兵种协调作战。于是,开始有了负载均衡服务器、Web服务器、缓存服务器、数据库服务器、存储服务器等多兵种;开始有了系统架构等战略战术。随着新项目和运营需求的越来越多,我们开始了多线作战。慢慢地,我总结了以下一些思考:
1、“收编绿林队伍”与“自己招兵买马”:
两者的关系就犹如“使用开源软件、框架”与“自己开发模块、写框架”,如果已有的开源软件、框架、架构能够较好地用于自己的项目,并便于扩展,则优先使用开源软件;如果没有现成的东西,或者已有的开源软件性能不高、扩展性差、学习成本高,则可以取长补短,在项目中打造自己的“队伍”。
2、适当利用“雇佣军”:
在多个项目同时进行时,不要认为自己能打赢每一场战斗,而每一场战斗都由自己亲自去打。确实,我相信很多人能够打赢一场场战斗,却只有少数人能够打赢一场战争。前暴雪北方“四大佬”创建的旗舰工作室的倒闭,印证了这样一个事实:一群天才,却没有让一个划时代意义的游戏诞生。旗舰工作室放着捷径不走却事必躬亲,自己做客户端、自己做语聊系统、自己做图像引擎、自己做客服系统,最终自己被自己给拖垮了。
不要让战线拉得太广,适当利用“雇佣军”,项目中的一些非重要、非核心的组成部分可以购买其他公司的成熟产品与服务,时间、费用、维护成本可能要更低。最近,我工作中的两项服务使用了“雇佣军”:(1)、购买ChinaCache CDN的Flash Media Server点播加速服务,支撑金山游戏视频宣传站点,节省了部署多节点的成本和时间;(2)、购买快网的智能DNS解析服务,来做金山游戏官网动态内容“北京多线、珠海电信、天津网通”三个机房服务器的智能DNS解析服务,节省了收集、整理,将来更新维护IP信息等工作。
3、打造“高技术兵器”:
现代战争的特点都拥一个有共同的前提那就是:都不可能离开“高技术兵器”。同样,要想承担高并发访问,而又希望系统架构简单一点、程序开发快捷一点,那么,则需要一款服务器端的“高技术兵器”。Web 2.0网站主要组成部分有内容页和列表页,内容页可以采用key-value形式的Memcached、Squid等开源产品来实现缓存,高并发访问下需要实时更新的列表页缓存,目前还没有合适的开源产品来解决。MySQL等数据库在高并发连接、大数据记录情况下性能低下,实时更新的列表页,成为最主要的瓶颈。我目前正在基于一些开源类库,开发的一款简单关系型数据库,将实现MySQL单表拥有的大部分复杂条件查询功能,并将达到单表千万级以上记录下,Memcached 60%左右的并发查询性能,预计6月6日开发完成进入测试阶段。
4、精简军队,提高战斗力:
军队越多,补给、后勤等开支也会越大,同样,服务器越多,维护成本、托管成本、复杂度也越高。所以,服务器不是越多越好,在能够保证容错性、避免单点故障的情况下,如果能用一台高配置服务器来解决的事,不要同两台低配置的服务器来干。
传统的系统架构只不过围绕负载均衡设备或服务器、Web服务器集群、数据库服务器集群、搜索引擎服务器集群、分布式存储服务器集群、缓存系统服务器集群等等,技术含量并不是特别高,只不过很多人没有生产环境的机会去实践而已。随着内存价格的下降,单台服务器扩充到64G内存的事情不再罕见;Intel将会在下周面向高端服务器领域发布代号为Nehalem-EX的8核XEON处理器。随着硬件性能的不断提高,我预测,将来的系统架构与服务器集群将不再从服务类型上划分,而将按“CPU密集型服务器集群”、“内存密集型服务器集群”、“存储密集型服务器集群”划分。我现在所设计的架构与开发的服务器端程序,也逐渐向后者转移。
最近,Google的工程师Luiz André Barroso and Urs Hölzle发表了一篇长达120页的论文,提出了一个数据中心就是一台计算机(The Datacenter as a Computer - An Introduction to the Design of Warehouse-Scale Machines )
“客户端访问”与“服务器端响应”,犹如一场战争。初期,访问量较小,弄几台服务器随便拉起一只队伍,就能抵抗住客户端的进攻。慢慢的,访问量大起来,这时候,就需要讲究排兵布阵、战略战术、多兵种协调作战。于是,开始有了负载均衡服务器、Web服务器、缓存服务器、数据库服务器、存储服务器等多兵种;开始有了系统架构等战略战术。随着新项目和运营需求的越来越多,我们开始了多线作战。慢慢地,我总结了以下一些思考:
1、“收编绿林队伍”与“自己招兵买马”:
两者的关系就犹如“使用开源软件、框架”与“自己开发模块、写框架”,如果已有的开源软件、框架、架构能够较好地用于自己的项目,并便于扩展,则优先使用开源软件;如果没有现成的东西,或者已有的开源软件性能不高、扩展性差、学习成本高,则可以取长补短,在项目中打造自己的“队伍”。
2、适当利用“雇佣军”:
在多个项目同时进行时,不要认为自己能打赢每一场战斗,而每一场战斗都由自己亲自去打。确实,我相信很多人能够打赢一场场战斗,却只有少数人能够打赢一场战争。前暴雪北方“四大佬”创建的旗舰工作室的倒闭,印证了这样一个事实:一群天才,却没有让一个划时代意义的游戏诞生。旗舰工作室放着捷径不走却事必躬亲,自己做客户端、自己做语聊系统、自己做图像引擎、自己做客服系统,最终自己被自己给拖垮了。
不要让战线拉得太广,适当利用“雇佣军”,项目中的一些非重要、非核心的组成部分可以购买其他公司的成熟产品与服务,时间、费用、维护成本可能要更低。最近,我工作中的两项服务使用了“雇佣军”:(1)、购买ChinaCache CDN的Flash Media Server点播加速服务,支撑金山游戏视频宣传站点,节省了部署多节点的成本和时间;(2)、购买快网的智能DNS解析服务,来做金山游戏官网动态内容“北京多线、珠海电信、天津网通”三个机房服务器的智能DNS解析服务,节省了收集、整理,将来更新维护IP信息等工作。
3、打造“高技术兵器”:
现代战争的特点都拥一个有共同的前提那就是:都不可能离开“高技术兵器”。同样,要想承担高并发访问,而又希望系统架构简单一点、程序开发快捷一点,那么,则需要一款服务器端的“高技术兵器”。Web 2.0网站主要组成部分有内容页和列表页,内容页可以采用key-value形式的Memcached、Squid等开源产品来实现缓存,高并发访问下需要实时更新的列表页缓存,目前还没有合适的开源产品来解决。MySQL等数据库在高并发连接、大数据记录情况下性能低下,实时更新的列表页,成为最主要的瓶颈。我目前正在基于一些开源类库,开发的一款简单关系型数据库,将实现MySQL单表拥有的大部分复杂条件查询功能,并将达到单表千万级以上记录下,Memcached 60%左右的并发查询性能,预计6月6日开发完成进入测试阶段。
4、精简军队,提高战斗力:
军队越多,补给、后勤等开支也会越大,同样,服务器越多,维护成本、托管成本、复杂度也越高。所以,服务器不是越多越好,在能够保证容错性、避免单点故障的情况下,如果能用一台高配置服务器来解决的事,不要同两台低配置的服务器来干。
传统的系统架构只不过围绕负载均衡设备或服务器、Web服务器集群、数据库服务器集群、搜索引擎服务器集群、分布式存储服务器集群、缓存系统服务器集群等等,技术含量并不是特别高,只不过很多人没有生产环境的机会去实践而已。随着内存价格的下降,单台服务器扩充到64G内存的事情不再罕见;Intel将会在下周面向高端服务器领域发布代号为Nehalem-EX的8核XEON处理器。随着硬件性能的不断提高,我预测,将来的系统架构与服务器集群将不再从服务类型上划分,而将按“CPU密集型服务器集群”、“内存密集型服务器集群”、“存储密集型服务器集群”划分。我现在所设计的架构与开发的服务器端程序,也逐渐向后者转移。
最近,Google的工程师Luiz André Barroso and Urs Hölzle发表了一篇长达120页的论文,提出了一个数据中心就是一台计算机(The Datacenter as a Computer - An Introduction to the Design of Warehouse-Scale Machines )
Nginx 0.8.x + PHP 5.2.10(FastCGI)搭建胜过Apache十倍的Web服务器(第5版)[原创]
[ 2009-5-6 13:40 | by 张宴 ]
本文已有最新版本:
请点击《Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建胜过Apache十倍的Web服务器(第6版)》
[文章作者:张宴 本文版本:v5.5 最后修改:2009.09.18 转载请注明原文链接:http://blog.zyan.cc/nginx_php_v5/]
前言:本文是我撰写的关于搭建“Nginx + PHP(FastCGI)”Web服务器的第5篇文章。本系列文章作为国内最早详细介绍 Nginx + PHP 安装、配置、使用的资料之一,为推动 Nginx 在国内的发展产生了积极的作用。这是一篇关于Nginx 0.7.x系列版本的文章,安装、配置方式与第4篇文章相差不大,但增加了MySQL安装配置的信息、PHP 5.2.10 的 php-fpm 补丁。Nginx 0.7.x系列版本虽然为开发版,但在很多大型网站的生产环境中已经使用。
链接:《2007年9月的第1版》、《2007年12月的第2版》、《2008年6月的第3版》、《2008年8月的第4版》
Nginx ("engine x") 是一个高性能的 HTTP 和反向代理服务器,也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的,它已经在该站点运行超过两年半了。Igor 将源代码以类BSD许可证的形式发布。
Nginx 超越 Apache 的高性能和稳定性,使得国内使用 Nginx 作为 Web 服务器的网站也越来越多,其中包括新浪博客、新浪播客、网易新闻等门户网站频道,六间房、56.com等视频分享网站,Discuz!官方论坛、水木社区等知名论坛,豆瓣、YUPOO相册、海内SNS、迅雷在线等新兴Web 2.0网站。
Nginx 的官方中文维基:http://wiki.nginx.org/NginxChs
在高并发连接的情况下,Nginx是Apache服务器不错的替代品。Nginx同时也可以作为7层负载均衡服务器来使用。根据我的测试结果,Nginx 0.8.15 + PHP 5.2.10 (FastCGI) 可以承受3万以上的并发连接数,相当于同等环境下Apache的10倍。
根据我的经验,4GB内存的服务器+Apache(prefork模式)一般只能处理3000个并发连接,因为它们将占用3GB以上的内存,还得为系统预留1GB的内存。我曾经就有两台Apache服务器,因为在配置文件中设置的MaxClients为4000,当Apache并发连接数达到3800时,导致服务器内存和Swap空间用满而崩溃。
而这台 Nginx 0.8.15 + PHP 5.2.10 (FastCGI) 服务器在3万并发连接下,开启的10个Nginx进程消耗150M内存(15M*10=150M),开启的64个php-cgi进程消耗1280M内存(20M*64=1280M),加上系统自身消耗的内存,总共消耗不到2GB内存。如果服务器内存较小,完全可以只开启25个php-cgi进程,这样php-cgi消耗的总内存数才500M。
在3万并发连接下,访问Nginx 0.8.15 + PHP 5.2.10 (FastCGI) 服务器的PHP程序,仍然速度飞快。下图为Nginx的状态监控页面,显示的活动连接数为28457(关于Nginx的监控页配置,会在本文接下来所给出的Nginx配置文件中写明):
我生产环境下的两台Nginx + PHP5(FastCGI)服务器,跑多个一般复杂的纯PHP动态程序,单台Nginx + PHP5(FastCGI)服务器跑PHP动态程序的处理能力已经超过“700次请求/秒”,相当于每天可以承受6000万(700*60*60*24=60480000)的访问量(更多信息见此),而服务器的系统负载也不高:
2009年9月3日下午2:30,金山游戏《剑侠情缘网络版叁》临时维护1小时(http://kefu.xoyo.com/gonggao/jx3/2009-09-03/750438.shtml),大量玩家上官网,论坛、评论、客服等动态应用Nginx服务器集群,每台服务器的Nginx活动连接数达到2.8万,这是笔者遇到的Nginx生产环境最高并发值。
下面是用100个并发连接分别去压生产环境中同一负载均衡器VIP下、提供相同服务的两台服务器,一台为Nginx,另一台为Apache,Nginx每秒处理的请求数是Apache的两倍多,Nginx服务器的系统负载、CPU使用率远低于Apache:
你可以将连接数开到10000~30000,去压Nginx和Apache上的phpinfo.php,这是用浏览器访问Nginx上的phpinfo.php一切正常,而访问Apache服务器的phpinfo.php,则是该页无法显示。4G内存的服务器,即使再优化,Apache也很难在“webbench -c 30000 -t 60 http://xxx.xxx.xxx.xxx/phpinfo.php”的压力情况下正常访问,而调整参数优化后的Nginx可以。
webbench 下载地址:http://blog.zyan.cc/post/288/
注意:webbench 做压力测试时,该软件自身也会消耗CPU和内存资源,为了测试准确,请将 webbench 安装在别的服务器上。
测试结果:##### Nginx + PHP #####
测试结果:##### Apache + PHP #####
为什么Nginx的性能要比Apache高得多?这得益于Nginx使用了最新的epoll(Linux 2.6内核)和kqueue(freebsd)网络I/O模型,而Apache则使用的是传统的select模型。目前Linux下能够承受高并发访问的Squid、Memcached都采用的是epoll网络I/O模型。
处理大量的连接的读写,Apache所采用的select网络I/O模型非常低效。下面用一个比喻来解析Apache采用的select模型和Nginx采用的epoll模型进行之间的区别:
假设你在大学读书,住的宿舍楼有很多间房间,你的朋友要来找你。select版宿管大妈就会带着你的朋友挨个房间去找,直到找到你为止。而epoll版宿管大妈会先记下每位同学的房间号,你的朋友来时,只需告诉你的朋友你住在哪个房间即可,不用亲自带着你的朋友满大楼找人。如果来了10000个人,都要找自己住这栋楼的同学时,select版和epoll版宿管大妈,谁的效率更高,不言自明。同理,在高并发服务器中,轮询I/O是最耗时间的操作之一,select和epoll的性能谁的性能更高,同样十分明了。
安装步骤:
(系统要求:Linux 2.6+ 内核,本文中的Linux操作系统为CentOS 5.3,另在RedHat AS4上也安装成功)
请点击《Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建胜过Apache十倍的Web服务器(第6版)》
[文章作者:张宴 本文版本:v5.5 最后修改:2009.09.18 转载请注明原文链接:http://blog.zyan.cc/nginx_php_v5/]
前言:本文是我撰写的关于搭建“Nginx + PHP(FastCGI)”Web服务器的第5篇文章。本系列文章作为国内最早详细介绍 Nginx + PHP 安装、配置、使用的资料之一,为推动 Nginx 在国内的发展产生了积极的作用。这是一篇关于Nginx 0.7.x系列版本的文章,安装、配置方式与第4篇文章相差不大,但增加了MySQL安装配置的信息、PHP 5.2.10 的 php-fpm 补丁。Nginx 0.7.x系列版本虽然为开发版,但在很多大型网站的生产环境中已经使用。
链接:《2007年9月的第1版》、《2007年12月的第2版》、《2008年6月的第3版》、《2008年8月的第4版》
Nginx ("engine x") 是一个高性能的 HTTP 和反向代理服务器,也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的,它已经在该站点运行超过两年半了。Igor 将源代码以类BSD许可证的形式发布。
Nginx 超越 Apache 的高性能和稳定性,使得国内使用 Nginx 作为 Web 服务器的网站也越来越多,其中包括新浪博客、新浪播客、网易新闻等门户网站频道,六间房、56.com等视频分享网站,Discuz!官方论坛、水木社区等知名论坛,豆瓣、YUPOO相册、海内SNS、迅雷在线等新兴Web 2.0网站。
Nginx 的官方中文维基:http://wiki.nginx.org/NginxChs
在高并发连接的情况下,Nginx是Apache服务器不错的替代品。Nginx同时也可以作为7层负载均衡服务器来使用。根据我的测试结果,Nginx 0.8.15 + PHP 5.2.10 (FastCGI) 可以承受3万以上的并发连接数,相当于同等环境下Apache的10倍。
根据我的经验,4GB内存的服务器+Apache(prefork模式)一般只能处理3000个并发连接,因为它们将占用3GB以上的内存,还得为系统预留1GB的内存。我曾经就有两台Apache服务器,因为在配置文件中设置的MaxClients为4000,当Apache并发连接数达到3800时,导致服务器内存和Swap空间用满而崩溃。
而这台 Nginx 0.8.15 + PHP 5.2.10 (FastCGI) 服务器在3万并发连接下,开启的10个Nginx进程消耗150M内存(15M*10=150M),开启的64个php-cgi进程消耗1280M内存(20M*64=1280M),加上系统自身消耗的内存,总共消耗不到2GB内存。如果服务器内存较小,完全可以只开启25个php-cgi进程,这样php-cgi消耗的总内存数才500M。
在3万并发连接下,访问Nginx 0.8.15 + PHP 5.2.10 (FastCGI) 服务器的PHP程序,仍然速度飞快。下图为Nginx的状态监控页面,显示的活动连接数为28457(关于Nginx的监控页配置,会在本文接下来所给出的Nginx配置文件中写明):
我生产环境下的两台Nginx + PHP5(FastCGI)服务器,跑多个一般复杂的纯PHP动态程序,单台Nginx + PHP5(FastCGI)服务器跑PHP动态程序的处理能力已经超过“700次请求/秒”,相当于每天可以承受6000万(700*60*60*24=60480000)的访问量(更多信息见此),而服务器的系统负载也不高:
2009年9月3日下午2:30,金山游戏《剑侠情缘网络版叁》临时维护1小时(http://kefu.xoyo.com/gonggao/jx3/2009-09-03/750438.shtml),大量玩家上官网,论坛、评论、客服等动态应用Nginx服务器集群,每台服务器的Nginx活动连接数达到2.8万,这是笔者遇到的Nginx生产环境最高并发值。
下面是用100个并发连接分别去压生产环境中同一负载均衡器VIP下、提供相同服务的两台服务器,一台为Nginx,另一台为Apache,Nginx每秒处理的请求数是Apache的两倍多,Nginx服务器的系统负载、CPU使用率远低于Apache:
你可以将连接数开到10000~30000,去压Nginx和Apache上的phpinfo.php,这是用浏览器访问Nginx上的phpinfo.php一切正常,而访问Apache服务器的phpinfo.php,则是该页无法显示。4G内存的服务器,即使再优化,Apache也很难在“webbench -c 30000 -t 60 http://xxx.xxx.xxx.xxx/phpinfo.php”的压力情况下正常访问,而调整参数优化后的Nginx可以。
webbench 下载地址:http://blog.zyan.cc/post/288/
注意:webbench 做压力测试时,该软件自身也会消耗CPU和内存资源,为了测试准确,请将 webbench 安装在别的服务器上。
测试结果:##### Nginx + PHP #####
引用
[root@localhost webbench-1.5]# webbench -c 100 -t 30 http://192.168.1.21/phpinfo.php
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.1.21/phpinfo.php
100 clients, running 30 sec.
Speed=102450 pages/min, 16490596 bytes/sec.
Requests: 51225 susceed, 0 failed.
top - 14:06:13 up 27 days, 2:25, 2 users, load average: 14.57, 9.89, 6.51
Tasks: 287 total, 4 running, 283 sleeping, 0 stopped, 0 zombie
Cpu(s): 49.9% us, 6.7% sy, 0.0% ni, 41.4% id, 1.1% wa, 0.1% hi, 0.8% si
Mem: 6230016k total, 2959468k used, 3270548k free, 635992k buffers
Swap: 2031608k total, 3696k used, 2027912k free, 1231444k cached
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.1.21/phpinfo.php
100 clients, running 30 sec.
Speed=102450 pages/min, 16490596 bytes/sec.
Requests: 51225 susceed, 0 failed.
top - 14:06:13 up 27 days, 2:25, 2 users, load average: 14.57, 9.89, 6.51
Tasks: 287 total, 4 running, 283 sleeping, 0 stopped, 0 zombie
Cpu(s): 49.9% us, 6.7% sy, 0.0% ni, 41.4% id, 1.1% wa, 0.1% hi, 0.8% si
Mem: 6230016k total, 2959468k used, 3270548k free, 635992k buffers
Swap: 2031608k total, 3696k used, 2027912k free, 1231444k cached
测试结果:##### Apache + PHP #####
引用
[root@localhost webbench-1.5]# webbench -c 100 -t 30 http://192.168.1.27/phpinfo.php
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.1.27/phpinfo.php
100 clients, running 30 sec.
Speed=42184 pages/min, 31512914 bytes/sec.
Requests: 21092 susceed, 0 failed.
top - 14:06:20 up 27 days, 2:13, 2 users, load average: 62.15, 26.36, 13.42
Tasks: 318 total, 7 running, 310 sleeping, 0 stopped, 1 zombie
Cpu(s): 80.4% us, 10.6% sy, 0.0% ni, 7.9% id, 0.1% wa, 0.1% hi, 0.9% si
Mem: 6230016k total, 3075948k used, 3154068k free, 379896k buffers
Swap: 2031608k total, 12592k used, 2019016k free, 1117868k cached
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.1.27/phpinfo.php
100 clients, running 30 sec.
Speed=42184 pages/min, 31512914 bytes/sec.
Requests: 21092 susceed, 0 failed.
top - 14:06:20 up 27 days, 2:13, 2 users, load average: 62.15, 26.36, 13.42
Tasks: 318 total, 7 running, 310 sleeping, 0 stopped, 1 zombie
Cpu(s): 80.4% us, 10.6% sy, 0.0% ni, 7.9% id, 0.1% wa, 0.1% hi, 0.9% si
Mem: 6230016k total, 3075948k used, 3154068k free, 379896k buffers
Swap: 2031608k total, 12592k used, 2019016k free, 1117868k cached
为什么Nginx的性能要比Apache高得多?这得益于Nginx使用了最新的epoll(Linux 2.6内核)和kqueue(freebsd)网络I/O模型,而Apache则使用的是传统的select模型。目前Linux下能够承受高并发访问的Squid、Memcached都采用的是epoll网络I/O模型。
处理大量的连接的读写,Apache所采用的select网络I/O模型非常低效。下面用一个比喻来解析Apache采用的select模型和Nginx采用的epoll模型进行之间的区别:
假设你在大学读书,住的宿舍楼有很多间房间,你的朋友要来找你。select版宿管大妈就会带着你的朋友挨个房间去找,直到找到你为止。而epoll版宿管大妈会先记下每位同学的房间号,你的朋友来时,只需告诉你的朋友你住在哪个房间即可,不用亲自带着你的朋友满大楼找人。如果来了10000个人,都要找自己住这栋楼的同学时,select版和epoll版宿管大妈,谁的效率更高,不言自明。同理,在高并发服务器中,轮询I/O是最耗时间的操作之一,select和epoll的性能谁的性能更高,同样十分明了。
安装步骤:
(系统要求:Linux 2.6+ 内核,本文中的Linux操作系统为CentOS 5.3,另在RedHat AS4上也安装成功)
Sun发布了MySQL 5.4,比MySQL 5.1快了59%
[ 2009-4-24 19:10 | by 张宴 ]
除了 Oracle 买了 Sun 这件事之外,还有一件重要的事,就是 Sun 发布了 MySQL 5.4 预览版。根据其 EAStress2004 benchmark 测试,MySQL 5.4 比 MySQL 5.1 快了 59%。有空我下载下来自己做个测试。
更多内容见:
《A Quick Look at MySQL 5.4》:http://dev.mysql.com/tech-resources/articles/mysql-54.html
MySQL 5.4 下载地址:http://dev.mysql.com/downloads/mysql/5.4.html
更多内容见:
《A Quick Look at MySQL 5.4》:http://dev.mysql.com/tech-resources/articles/mysql-54.html
MySQL 5.4 下载地址:http://dev.mysql.com/downloads/mysql/5.4.html
Linux下PHP 5.2 Oracle客户端扩展(OCI8)安装[原创]
[ 2009-4-21 12:53 | by 张宴 ]
[文章作者:张宴 本文版本:v1.0 最后修改:2009.04.21 转载请注明原文链接:http://blog.zyan.cc/post/411/]
1、下载Oracle即时客户端程序包 — Basic: 运行 OCI、OCCI 和 JDBC-OCI 应用程序所需的所有文件
①、打开以下网址(本文以32位版为例):
(Linux 32位版)http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/linuxsoft.html
(Linux 64位版)http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/linuxx86_64soft.html
②、下载以下几个文件:
2、安装Oracle即时客户端程序包
3、安装OCI8 PHP扩展(使用PHP自带的OCI8,假设PHP程序安装在/usr/local/webserver/php/)
4、修改PHP配置文件(/usr/local/webserver/php/etc/php.ini)
在extension_dir = "/usr/local/webserver/php/lib/php/extensions/no-debug-non-zts-20060613/"后增加一行:
5、重启PHP
6、创建一个phpinfo.php文件(内容如下)并通过Web访问,如果有“oci8”这一项,则表明安装成功。
1、下载Oracle即时客户端程序包 — Basic: 运行 OCI、OCCI 和 JDBC-OCI 应用程序所需的所有文件
①、打开以下网址(本文以32位版为例):
(Linux 32位版)http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/linuxsoft.html
(Linux 64位版)http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/linuxx86_64soft.html
②、下载以下几个文件:
oracle-instantclient11.1-basic-11.1.0.7.0-1.i386.rpm
oracle-instantclient11.1-devel-11.1.0.7.0-1.i386.rpm
oracle-instantclient11.1-sqlplus-11.1.0.7.0-1.i386.rpm
oracle-instantclient11.1-devel-11.1.0.7.0-1.i386.rpm
oracle-instantclient11.1-sqlplus-11.1.0.7.0-1.i386.rpm
2、安装Oracle即时客户端程序包
rpm -ivh oracle-instantclient11.1-basic-11.1.0.7.0-1.i386.rpm oracle-instantclient11.1-devel-11.1.0.7.0-1.i386.rpm oracle-instantclient11.1-sqlplus-11.1.0.7.0-1.i386.rpm
echo "/usr/lib/oracle/11.1/client/lib/" > /etc/ld.so.conf.d/oracle_client.conf
/sbin/ldconfig
echo "/usr/lib/oracle/11.1/client/lib/" > /etc/ld.so.conf.d/oracle_client.conf
/sbin/ldconfig
3、安装OCI8 PHP扩展(使用PHP自带的OCI8,假设PHP程序安装在/usr/local/webserver/php/)
yum install libaio
wget http://pecl.php.net/get/oci8-1.3.5.tgz
tar zxvf oci8-1.3.5.tgz
cd oci8-1.3.5/
/usr/local/webserver/php/bin/phpize
CFLAGS="-I/usr/include/oracle/11.1/client/"
CXXFLAGS="-I/usr/include/oracle/11.1/client/"
./configure --with-php-config=/usr/local/webserver/php/bin/php-config --with-oci8=/usr/lib/oracle/11.1/client/
make
make install
wget http://pecl.php.net/get/oci8-1.3.5.tgz
tar zxvf oci8-1.3.5.tgz
cd oci8-1.3.5/
/usr/local/webserver/php/bin/phpize
CFLAGS="-I/usr/include/oracle/11.1/client/"
CXXFLAGS="-I/usr/include/oracle/11.1/client/"
./configure --with-php-config=/usr/local/webserver/php/bin/php-config --with-oci8=/usr/lib/oracle/11.1/client/
make
make install
4、修改PHP配置文件(/usr/local/webserver/php/etc/php.ini)
在extension_dir = "/usr/local/webserver/php/lib/php/extensions/no-debug-non-zts-20060613/"后增加一行:
extension = "oci8.so"
5、重启PHP
6、创建一个phpinfo.php文件(内容如下)并通过Web访问,如果有“oci8”这一项,则表明安装成功。
<?php
phpinfo();
?>
phpinfo();
?>
珠海金山软件之行[原创]
[ 2009-4-19 23:56 | by 张宴 ]
[文章作者:张宴 本文版本:v1.0 最后修改:2009.04.19 转载请注明原文链接:http://blog.zyan.cc/post/410/]
2009年4月14日(星期二)
下班后,和同事打的到首都国际机场,乘21:10起飞的中国南方航空CZ3734航班飞往珠海。这也是我第一次坐飞机。
波音737穿越着宁静的天空,云端望月的景象,罕见而优美。经过的三个小时的飞行,掠过了大半个中国,飞机降落在珠海三灶机场。
走出飞机,打的前往吉大区的如家快捷酒店,沿途海风扑面,湿气弥漫,与北京的干燥行成鲜明的对比。
2009年4月15日(星期三)
上午10点,我们去了珠海金山软件公司,在“万花谷”会议室跟西山居工作室开了个小会,随后参观了三楼的《剑侠世界》研发团队和四楼的《剑侠情缘网络版3》研发团队,向他们请教了100多人协作开发的项目管理经验。
下午,跟金山网游公司CTO的会议,是我主要关心的议题,以下几项收获也不错:
1、我所设计的“广州电信机房、天津网通机房、北京电信通多线机房”三个核心IDC的系统架构得以通过,只是做了点小调整,将“广州电信机房”换成了“珠海电信机房”,因为金山享有珠海电信在带宽和线路上的特殊待遇。
PS:百度网页搜索前端服务器也分布在三个机房:北京电信机房、北京网通机房、北京长城宽带多线机房。
全国所有电信用户访问 www.baidu.com 将被解析到以下两个VIP:
220.181.6.19 (北京市·电信)
220.181.6.18 (北京市·电信)
全国所有网通用户访问 www.baidu.com 将被解析到以下两个VIP:
202.108.22.5 (北京市·网通)
202.108.22.43 (北京市·网通)
全国铁通、教育网等其他访问 www.baidu.com 将被解析到以下两个VIP:
119.75.213.50 (北京市·长城宽带)
119.75.213.51 (北京市·长城宽带)
2、获批了20台服务器。搭建我三个IDC的架构平台,硬件资源得以满足,剩下要解决的就是这20台服务器尽快到位的问题了。
3、允许了将来购买 Adobe 即将推出的 Flash Media Server 4.0 授权,利用 Flash Player 10 和 RTMFP协议(支持P2P)提供 FLV/MP4(H264) 视频流媒体点播服务。
目前逍遥网《基于开源Flash Server:Red5构建RTMP流媒体播放平台》,采用的是 RTMP 协议,生产环境(剑网3相关视频:http://jx3.xoyo.com/xgxz/video/)平均每个视频播放所消耗的带宽是25KB/秒,100M独享带宽可以支撑500人同时在线观看。将来采用 RTMFP 协议进行 Flash P2P 视频点播服务,将大大地节省带宽。
RTMFP 是 Real‐Time Media Flow Protocol的缩写,是Adobe推出的一种新的通信协议,这种通信协议可以让 Flash 客户端直接和另外一个Flash 客户端之间进行数据通信,也就是常说的P2P的方式进行通信。
RTMFP 将会大大地减少音视频直播、点播、多人在线游戏等应用的网络带宽的消耗,减轻服务器的负担。因为很多数据都是客户端之间直接传输了,无须再经过服务器中转了。RTMFP由于使用了UDP网络协议,所以相对之前的TCP协议在数据传输效率上也会大大提高,这种优势在音视频数据传输方面是非常明显的。
下面的示意图表现了RTMFP和RTMP的不同之处:
2009年4月14日(星期二)
下班后,和同事打的到首都国际机场,乘21:10起飞的中国南方航空CZ3734航班飞往珠海。这也是我第一次坐飞机。
波音737穿越着宁静的天空,云端望月的景象,罕见而优美。经过的三个小时的飞行,掠过了大半个中国,飞机降落在珠海三灶机场。
走出飞机,打的前往吉大区的如家快捷酒店,沿途海风扑面,湿气弥漫,与北京的干燥行成鲜明的对比。
2009年4月15日(星期三)
上午10点,我们去了珠海金山软件公司,在“万花谷”会议室跟西山居工作室开了个小会,随后参观了三楼的《剑侠世界》研发团队和四楼的《剑侠情缘网络版3》研发团队,向他们请教了100多人协作开发的项目管理经验。
下午,跟金山网游公司CTO的会议,是我主要关心的议题,以下几项收获也不错:
1、我所设计的“广州电信机房、天津网通机房、北京电信通多线机房”三个核心IDC的系统架构得以通过,只是做了点小调整,将“广州电信机房”换成了“珠海电信机房”,因为金山享有珠海电信在带宽和线路上的特殊待遇。
PS:百度网页搜索前端服务器也分布在三个机房:北京电信机房、北京网通机房、北京长城宽带多线机房。
全国所有电信用户访问 www.baidu.com 将被解析到以下两个VIP:
220.181.6.19 (北京市·电信)
220.181.6.18 (北京市·电信)
全国所有网通用户访问 www.baidu.com 将被解析到以下两个VIP:
202.108.22.5 (北京市·网通)
202.108.22.43 (北京市·网通)
全国铁通、教育网等其他访问 www.baidu.com 将被解析到以下两个VIP:
119.75.213.50 (北京市·长城宽带)
119.75.213.51 (北京市·长城宽带)
2、获批了20台服务器。搭建我三个IDC的架构平台,硬件资源得以满足,剩下要解决的就是这20台服务器尽快到位的问题了。
3、允许了将来购买 Adobe 即将推出的 Flash Media Server 4.0 授权,利用 Flash Player 10 和 RTMFP协议(支持P2P)提供 FLV/MP4(H264) 视频流媒体点播服务。
目前逍遥网《基于开源Flash Server:Red5构建RTMP流媒体播放平台》,采用的是 RTMP 协议,生产环境(剑网3相关视频:http://jx3.xoyo.com/xgxz/video/)平均每个视频播放所消耗的带宽是25KB/秒,100M独享带宽可以支撑500人同时在线观看。将来采用 RTMFP 协议进行 Flash P2P 视频点播服务,将大大地节省带宽。
RTMFP 是 Real‐Time Media Flow Protocol的缩写,是Adobe推出的一种新的通信协议,这种通信协议可以让 Flash 客户端直接和另外一个Flash 客户端之间进行数据通信,也就是常说的P2P的方式进行通信。
RTMFP 将会大大地减少音视频直播、点播、多人在线游戏等应用的网络带宽的消耗,减轻服务器的负担。因为很多数据都是客户端之间直接传输了,无须再经过服务器中转了。RTMFP由于使用了UDP网络协议,所以相对之前的TCP协议在数据传输效率上也会大大提高,这种优势在音视频数据传输方面是非常明显的。
下面的示意图表现了RTMFP和RTMP的不同之处:
基于开源Flash Server:Red5构建RTMP流媒体播放平台[原创]
[ 2009-4-13 23:13 | by 张宴 ]
[文章作者:张宴 本文版本:v1.0 最后修改:2009.04.13 转载请注明原文链接:http://blog.zyan.cc/post/409/]
上周五,我们基于开源Flash Server:Red5(http://osflash.org/red5)的Flash流媒体服务平台上线,内容涉及视频上传、视频分发、调用接口、Flash播放器等。
一、Flash RTMP流媒体播放演示(播放时进度条可以自由拖动):
生产环境更多 Flash RTMP 流媒体视频演示:http://jx3.xoyo.com/xgxz/video/
二、安装步骤简要说明:
①、安装JDK
打开http://java.sun.com/javase/downloads/,下载最新的Java SE Development Kit (JDK),安装在/usr/local/jdk/下。
②、安装Red5
打开http://osflash.org/red5/070final,下载red5-0.7.0.tar.gz,解压缩后执行./red5.sh,然后访问http://yourdomain:5080/,有演示。
三、服务器带宽消耗比较:
①、客户端 1.5M ADSL 环境,HTTP 方式播放单个视频,服务器所消耗的带宽:
②、客户端 1.5M ADSL 环境,RTMP 流媒体方式播放单个视频,服务器所消耗的带宽:
HTTP 方式播放,如果服务器端不限速,客户端的带宽越大,服务器消耗的带宽也越大,但限速又会影响用户体验;
RTMP 流媒体方式播放,只要客户端达到最低带宽要求,不管客户端的带宽如何,服务器消耗的带宽都一样。
如果播放10M以内大小的视频,HTTP 能够在较短的时间内下载完视频,能够降低并发观看用户数;
如果播放10M以上大小的视频,RTMP 要比 HTTP 方式节省不少带宽。
RTMP 播放时进度条可以自由拖动,虽然Lighttpd和Nginx目前也可以使用somevideo.flv?start=xxx的方式从指定位置下载视频,但还是不如 RTMP 灵活。
上周五,我们基于开源Flash Server:Red5(http://osflash.org/red5)的Flash流媒体服务平台上线,内容涉及视频上传、视频分发、调用接口、Flash播放器等。
一、Flash RTMP流媒体播放演示(播放时进度条可以自由拖动):
生产环境更多 Flash RTMP 流媒体视频演示:http://jx3.xoyo.com/xgxz/video/
二、安装步骤简要说明:
①、安装JDK
打开http://java.sun.com/javase/downloads/,下载最新的Java SE Development Kit (JDK),安装在/usr/local/jdk/下。
chmod +x jdk-6u13-linux-i586.bin
./jdk-6u13-linux-i586.bin
./jdk-6u13-linux-i586.bin
②、安装Red5
打开http://osflash.org/red5/070final,下载red5-0.7.0.tar.gz,解压缩后执行./red5.sh,然后访问http://yourdomain:5080/,有演示。
三、服务器带宽消耗比较:
①、客户端 1.5M ADSL 环境,HTTP 方式播放单个视频,服务器所消耗的带宽:
[root@localhost ~]# ./net.sh eth0 1
IN: 3318 Byte/s OUT: 259984 Byte/s
IN: 3486 Byte/s OUT: 249470 Byte/s
IN: 3332 Byte/s OUT: 259984 Byte/s
IN: 3090 Byte/s OUT: 252528 Byte/s
IN: 3000 Byte/s OUT: 252474 Byte/s
IN: 3000 Byte/s OUT: 253976 Byte/s
IN: 2940 Byte/s OUT: 255478 Byte/s
IN: 3004 Byte/s OUT: 252474 Byte/s
IN: 3452 Byte/s OUT: 252528 Byte/s
IN: 3270 Byte/s OUT: 260038 Byte/s
IN: 3586 Byte/s OUT: 252474 Byte/s
IN: 3318 Byte/s OUT: 259984 Byte/s
IN: 3486 Byte/s OUT: 249470 Byte/s
IN: 3332 Byte/s OUT: 259984 Byte/s
IN: 3090 Byte/s OUT: 252528 Byte/s
IN: 3000 Byte/s OUT: 252474 Byte/s
IN: 3000 Byte/s OUT: 253976 Byte/s
IN: 2940 Byte/s OUT: 255478 Byte/s
IN: 3004 Byte/s OUT: 252474 Byte/s
IN: 3452 Byte/s OUT: 252528 Byte/s
IN: 3270 Byte/s OUT: 260038 Byte/s
IN: 3586 Byte/s OUT: 252474 Byte/s
②、客户端 1.5M ADSL 环境,RTMP 流媒体方式播放单个视频,服务器所消耗的带宽:
[root@localhost ~]# ./net.sh eth0 1
IN: 3900 Byte/s OUT: 27878 Byte/s
IN: 4200 Byte/s OUT: 30868 Byte/s
IN: 4380 Byte/s OUT: 27801 Byte/s
IN: 4080 Byte/s OUT: 29965 Byte/s
IN: 4080 Byte/s OUT: 26450 Byte/s
IN: 3960 Byte/s OUT: 27143 Byte/s
IN: 3000 Byte/s OUT: 10061 Byte/s
IN: 3960 Byte/s OUT: 16166 Byte/s
IN: 3660 Byte/s OUT: 26480 Byte/s
IN: 4020 Byte/s OUT: 23127 Byte/s
IN: 3900 Byte/s OUT: 27878 Byte/s
IN: 4200 Byte/s OUT: 30868 Byte/s
IN: 4380 Byte/s OUT: 27801 Byte/s
IN: 4080 Byte/s OUT: 29965 Byte/s
IN: 4080 Byte/s OUT: 26450 Byte/s
IN: 3960 Byte/s OUT: 27143 Byte/s
IN: 3000 Byte/s OUT: 10061 Byte/s
IN: 3960 Byte/s OUT: 16166 Byte/s
IN: 3660 Byte/s OUT: 26480 Byte/s
IN: 4020 Byte/s OUT: 23127 Byte/s
HTTP 方式播放,如果服务器端不限速,客户端的带宽越大,服务器消耗的带宽也越大,但限速又会影响用户体验;
RTMP 流媒体方式播放,只要客户端达到最低带宽要求,不管客户端的带宽如何,服务器消耗的带宽都一样。
如果播放10M以内大小的视频,HTTP 能够在较短的时间内下载完视频,能够降低并发观看用户数;
如果播放10M以上大小的视频,RTMP 要比 HTTP 方式节省不少带宽。
RTMP 播放时进度条可以自由拖动,虽然Lighttpd和Nginx目前也可以使用somevideo.flv?start=xxx的方式从指定位置下载视频,但还是不如 RTMP 灵活。
Google 构建大规模信息检索系统中的挑战
[ 2009-4-5 00:07 | by 张宴 ]
以下是 Google 检索系统的架构师、Google Mapreduce 的发明者 Jeff Dean 在 WSDM 2009 上的主题演讲:《Challenges in Building Large-Scale Information Retrieval Systems》。在这个主题演讲中,Jeff Dean 讲述了 Google 在10年中,Google 检索系统的演变和发展。
英文原文:http://research.google.com/people/jeff/WSDM09-keynote.pdf
演讲视频:http://videolectures.net/wsdm09_dean_cblirs/
中文译文(由银杏泰克有限公司郝培强翻译):
英文原文:http://research.google.com/people/jeff/WSDM09-keynote.pdf
演讲视频:http://videolectures.net/wsdm09_dean_cblirs/
中文译文(由银杏泰克有限公司郝培强翻译):
CentOS 5.2下重新编译PHP增加LDAP支持[原创]
[ 2009-3-31 17:30 | by 张宴 ]
[文章作者:张宴 本文版本:v1.0 最后修改:2009.03.31 转载请注明原文链接:http://blog.zyan.cc/post/406/]
yum install openldap openldap-devel nss_ldap openldap-clients openldap-servers
cd php-5.2.8/
./configure 省略参数 --with-ldap --with-ldap-sasl
make ZEND_EXTRA_LIBS='-liconv'
make install
cd php-5.2.8/
./configure 省略参数 --with-ldap --with-ldap-sasl
make ZEND_EXTRA_LIBS='-liconv'
make install
中国移动飞信免费发短信API接口(第三方 Fetion API)[原创]
[ 2009-3-22 10:35 | by 张宴 ]
[文章作者:张宴 本文版本:v1.1 最后修改:2010.08.03 转载请注明原文链接:http://blog.zyan.cc/fetion_api/]
备注:2010年7月底移动飞信修改协议,造成影响的 sms.api.bz 免费发送短信API接口,已于2010年8月3日19:00恢复正常。
飞信是由中国移动通信集团公司推出的一款集商务应用和娱乐功能为一体的,基于手机应用以及与Internet深度互通的即时通讯产品,可免费给好友发送短信。
1、下载中国移动飞信PC客户端软件(http://www.fetion.com.cn/downloads/pc.aspx),并注册开通飞信。注册成为飞信用户,下载飞信PC客户端、使用PC客户端基本功能,不收取费用。
2、通过PC客户端,邀请并添加免费短信接收方的手机号码(仅限中国移动)到您的飞信好友,该手机号需要通过通过PC客户端、或回复短信接受您的邀请;
3、通过 http://sms.api.bz/ 提供的 API 接口,即可免费给飞信好友或给你自己的手机发短信。利用本API接口可进行日程提醒、服务器监控、报警、故障通知或短信自动控制等功能。
飞信免费发短信API接口在线演示页面:
http://sms.api.bz/
https://sms.api.bz/ (HTTPS加密接口)
飞信免费发短信API接口调用方式(通过HTTP访问以下网址、支持GET和POST):
注:短信内容最大长度为180个汉字,超过180个汉字不发送。返回的信息为UTF-8编码的中文文本信息。
2009年5月28日新增:飞信免费发短信API接口调用方式(通过HTTPS加密隧道访问以下网址、支持GET和POST,进一步保证您的密码安全):
注:短信内容最大长度为180个汉字,超过180个汉字不发送。返回的信息为UTF-8编码的中文文本信息。
例1:在Linux命令行下通过curl命令给自己的手机号(假设为13800138000)发送短信(HTTP GET 方式)
例2:在PHP5中通过file_get_contents函数发送短信(HTTP GET 方式)
备注:2010年7月底移动飞信修改协议,造成影响的 sms.api.bz 免费发送短信API接口,已于2010年8月3日19:00恢复正常。
飞信是由中国移动通信集团公司推出的一款集商务应用和娱乐功能为一体的,基于手机应用以及与Internet深度互通的即时通讯产品,可免费给好友发送短信。
1、下载中国移动飞信PC客户端软件(http://www.fetion.com.cn/downloads/pc.aspx),并注册开通飞信。注册成为飞信用户,下载飞信PC客户端、使用PC客户端基本功能,不收取费用。
2、通过PC客户端,邀请并添加免费短信接收方的手机号码(仅限中国移动)到您的飞信好友,该手机号需要通过通过PC客户端、或回复短信接受您的邀请;
3、通过 http://sms.api.bz/ 提供的 API 接口,即可免费给飞信好友或给你自己的手机发短信。利用本API接口可进行日程提醒、服务器监控、报警、故障通知或短信自动控制等功能。
飞信免费发短信API接口在线演示页面:
http://sms.api.bz/
https://sms.api.bz/ (HTTPS加密接口)
飞信免费发短信API接口调用方式(通过HTTP访问以下网址、支持GET和POST):
http://sms.api.bz/fetion.php?username=您的移动飞信登录手机号&password=您的移动飞信登录密码&sendto=接收短信的飞信好友手机号(也可以是你自己的手机号)&message=短信内容
注:短信内容最大长度为180个汉字,超过180个汉字不发送。返回的信息为UTF-8编码的中文文本信息。
2009年5月28日新增:飞信免费发短信API接口调用方式(通过HTTPS加密隧道访问以下网址、支持GET和POST,进一步保证您的密码安全):
https://sms.api.bz/fetion.php?username=您的移动飞信登录手机号&password=您的移动飞信登录密码&sendto=接收短信的飞信好友手机号(也可以是你自己的手机号)&message=短信内容
注:短信内容最大长度为180个汉字,超过180个汉字不发送。返回的信息为UTF-8编码的中文文本信息。
例1:在Linux命令行下通过curl命令给自己的手机号(假设为13800138000)发送短信(HTTP GET 方式)
curl "http://sms.api.bz/fetion.php?username=13800138000&password=123456&sendto=13800138000&message=短信内容"
例2:在PHP5中通过file_get_contents函数发送短信(HTTP GET 方式)