<s id="qx03x"></s>
  • <tt id="qx03x"><noscript id="qx03x"></noscript></tt><rt id="qx03x"><nav id="qx03x"></nav></rt>

    <strong id="qx03x"><li id="qx03x"></li></strong>
    <tt id="qx03x"></tt>

        1. 分頁: 6/31 第一頁 上頁 1 2 3 4 5 6 7 8 9 10 下頁 最后頁 [ 顯示模式: 摘要 | 列表 ]
            發布版本:
            httpcws 1.0.0 (最新版本:2009-08-10發布)

            程序網址:http://code.google.com/p/httpcws

            安裝使用手冊:http://blog.www.lukangtou.cn/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.www.lukangtou.cn/demo/httpcws/

            PHP演示程序下載:http://blog.www.lukangtou.cn/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.www.lukangtou.cn/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/


            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/


            命令行啟動參數:

            點擊在新窗口中瀏覽此圖片



            4、httpcws 使用方法
            GET方法(文本長度受URL的長度限制,需要分詞的文本為GBK編碼,最好采用urlencode對文本進行編碼):


            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


            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;
          ?>

            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:
          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


            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


            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


            檢查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.”。

            [文章作者:張宴 本文版本:v1.0 最后修改:2009.07.16 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/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”命令安裝):

          /usr/sbin/ntpdate ntp.api.bz


            如果想定時執行ntpdate進行時間同步,可以通過crontab來進行:
          crontab -e

            輸入以下內容,每小時的第19分鐘做一次時間同步:
          19 * * * * /usr/sbin/ntpdate ntp.api.bz



            2、Windows服務器或個人電腦請用鼠標雙擊屏幕右下角的時間,按照下圖設置:

            點擊在新窗口中瀏覽此圖片

            點擊“立即更新”就可以馬上更新時間,響應速度與成功率要比原有的 time.windows.com 高得多。
            飯否被和諧了,我的微博客由飯否移到美國佬的地盤。被GFW還可以翻墻,總比信息丟失好。

            設置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


            瀏覽器通過 https://twitter.com/ 訪問。

            不設置hosts,則可以通過 http://www.itweet.net/web/ 等網站訪問。

            手機可通過 http://dabr.co.uk 訪問。

            我的twitterhttps://twitter.com/rewinxhttp://twitter.com/rewinx

            [文章作者:張宴 本文版本:v1.0 最后修改:2009.07.06 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/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軟件:
          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


            2、umount /data0分區:
          umount /data0

            如果提示busy,先kill正在使用這個目錄的進程,再umount:
          fuser -k /data0
          umount /data0


            3、查詢所有Inode,(執行需要幾分鐘~十多分鐘):
          ext3grep /dev/sdb1 --ls --inode 2

            點擊在新窗口中瀏覽此圖片

            4、逐級查找Inode,看是否能找到httpcws.cpp文件(此步驟也可省略):
            [文章作者:張宴 本文版本:v1.0 最后修改:2009.06.17 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/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系統。
            [文章作者:張宴 本文版本:v1.0 最后修改:2009.05.28 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/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 )
            本文已有最新版本:

            請點擊Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建勝過Apache十倍的Web服務器(第6版)




            [文章作者:張宴 本文版本:v5.5 最后修改:2009.09.18 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/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.www.lukangtou.cn/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


            測試結果:#####  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




            為什么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的性能誰的性能更高,同樣十分明了。



            安裝步驟:
           ?。ㄏ到y要求:Linux 2.6+ 內核,本文中的Linux操作系統為CentOS 5.3,另在RedHat AS4上也安裝成功)
            除了 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

            [文章作者:張宴 本文版本:v1.0 最后修改:2009.04.21 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/post/411/]

            1、下載Oracle即時客戶端程序包 — Basic: 運行 OCI、OCCI 和 JDBC-OCI 應用程序所需的所有文件

           ?、?、打開以下網址(本文以32位版為例):
           ?。↙inux 32位版)http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/linuxsoft.html
           ?。↙inux 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


            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


            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


            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();
          ?>

            點擊在新窗口中瀏覽此圖片
          Tags: , ,

          珠海金山軟件之行[原創]

          [不指定 2009-4-19 23:56 | by 張宴 ]
            [文章作者:張宴 本文版本:v1.0 最后修改:2009.04.19 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/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的不同之處:
            [文章作者:張宴 本文版本:v1.0 最后修改:2009.04.13 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/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/下。
          chmod +x 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


           ?、?、客戶端 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


            HTTP 方式播放,如果服務器端不限速,客戶端的帶寬越大,服務器消耗的帶寬也越大,但限速又會影響用戶體驗;
            RTMP 流媒體方式播放,只要客戶端達到最低帶寬要求,不管客戶端的帶寬如何,服務器消耗的帶寬都一樣。

            如果播放10M以內大小的視頻,HTTP 能夠在較短的時間內下載完視頻,能夠降低并發觀看用戶數;
            如果播放10M以上大小的視頻,RTMP 要比 HTTP 方式節省不少帶寬。

            RTMP 播放時進度條可以自由拖動,雖然Lighttpd和Nginx目前也可以使用somevideo.flv?start=xxx的方式從指定位置下載視頻,但還是不如 RTMP 靈活。
          Tags: , ,
            以下是 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/

            中文譯文(由銀杏泰克有限公司郝培強翻譯):
          Tags:
            [文章作者:張宴 本文版本:v1.0 最后修改:2009.03.31 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/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
            [文章作者:張宴 本文版本:v1.1 最后修改:2010.08.03 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/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):
          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 方式)
          分頁: 6/31 第一頁 上頁 1 2 3 4 5 6 7 8 9 10 下頁 最后頁 [ 顯示模式: 摘要 | 列表 ]
          在线精品国产在线视频