<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. 分頁: 1/2 第一頁 1 2 下頁 最后頁 [ 顯示模式: 摘要 | 列表 ]
            傳承自 APMServ 的 PHPTS,十年后隆重推出。

            PHPTS 邊緣計算協作服務器套件,是 Windows 系統上一鍵搭建 Nginx + PHP + MySQL + Memcached + Redis + MongoDB + InfluxDB 等網站、APP、小程序服務器端運行環境的軟件。

            它即可以運行在云服務器上用于生產環境,也能夠運行在個人電腦上作為編程開發環境。任何個人和企業,均可免費使用,包括商用用途,并可與自有產品集成發布。

            PHPTS 未來更大的用途,是運行在本地服務器、PC臺式機、筆記本電腦、工控機上,作為邊緣計算節點服務器,與攝像頭、存儲、音響、投屏、打印機、串口設備、工業設備、物聯網終端互聯互通,利用本地計算機、顯卡實現AI人工智能運算、語音合成、人臉識別、視頻流分析、音視頻轉碼,不必購買各大公有云平臺按次數、按時間、按使用量收費的昂貴計算型云服務;并將利用光纖寬帶、5G網絡與公有云互聯,組建私有云、混合云。

            【2020年02月15日 PHPTS 1.07 版本發布】

            軟件下載,請訪問 PHPTS 官方網站:https://www.phpts.com/

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

            PHPTS 1.06 版本,集成 Nginx 1.17.8、PHP 7.4.2、PHP 7.3.14、PHP 5.6.40、MySQL 8.0.19(x64)、Memcached 1.5.22、Redis 4.0.14(x64)、MongoDB 4.3.3(x64)、phpMyAdmin 5.0.1、Bash 終端,并可通過組件方式下載安裝 InfluxDB(時間序列數據庫)、HeidiSQL(MySQL客戶端管理工具)、Another.Redis.Desktop.Manager(Redis客戶端管理工具)。推薦在64位 Windows 系統上安裝 PHPTS。

            Nginx for PHPTS 是專門為 Windows 移植的高并發版本,采用 Windows 輸入輸出完成端口(IOCP),媲美 Linux 下的 epoll。

            相比于官方 Nginx Windows 版本僅支持 1024 連接數、僅支持低效的 SELECT/POLL 模型、僅支持單進程,PHPTS Windows 版本支持 32768 連接數、支持 IOCP 模型、支持多進程能夠充分利用多核 CPU。從此 Nginx Windows 版本性能低下、不能用于生產環境成為歷史。

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

            PHPTS 軟件功能界面截圖

            Nginx 虛擬主機:

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

            PHP:

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

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

            MySQL:

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

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

            Memcached:

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

            Redis:

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

            InfluxDB 時間序列數據庫:

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

            MongoDB 面向文檔數據庫:

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

            Linux Bash 仿真終端:

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

            軟件下載,請訪問 PHPTS 官方網站:https://www.phpts.com/
            2011年7月8日早上7:00,作為領隊,帶領金山游戲運營技術中心部分同事、家屬組成的45人旅行團,乘大巴車從北京金山軟件大廈出發,開始承德木蘭圍場、內蒙古烏蘭布統大草原三日游。

            沒有去過的朋友,可以將本文當成一篇攻略;無論是否去過的朋友,都可以將本文當成一篇美景欣賞相冊。木蘭圍場、烏蘭布統大草原,真是太漂亮了。

            【第一天:2011年7月8日】

            “北京→木蘭圍場”行車路線:
            


            【萬頃林?!?/strong>

            經過3個小時的京承高速、3個小時的國道,到達“塞罕壩國家森林公園”山門。

            車過山門,還需1小時的山路,觀千里松林、萬頃林海。53座的大巴車,挑戰360度的下坡大轉彎,還是有些難度的。

            點擊在新窗口中瀏覽此圖片
            5月7日,我在北京長城飯店“2011中國PHP技術高峰論壇”上的演講PPT:

            下載地址1(國外服務器):http://blog.www.lukangtou.cn/attachment/201105/2011phptc_zy.zip

            下載地址2(國內服務器):http://ishare.iask.sina.com.cn/f/15231659.html



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

            以下是我在會議主辦方對演講文字速錄的基礎上,修正錯漏內容,整理之后,對應到每頁PPT的文字內容:

            [PPT No.1]
            大家下午好,現在我來跟大家分享的是PHP在金山游戲運營中的應用,包括團隊協助開發實現方式、網站Web架構設計、游戲運營平臺設計這些信息。

            [PPT No.2]
            我議題主要有兩個,一個是金山游戲官方網站的一些應用,另一個是金山游戲運營系統Keyes中的架構設計。

            [PPT No.3]
            金山游戲官方網站包括用戶中心、客服系統、論壇、視頻、各游戲官網,以及其他跟游戲相關的一些產品,主要采用64位CentOS Linux系統、Nginx、PHP 5.2版本、MySQL 5.5。

            [PPT No.4]
            首先來看團隊協作開發。我們肯定遇到過這樣一種情況,在很多項目中,都是多個人同時開發,涉及到開發環境和測試環境不一樣。我們很多PHP工程師,都是在Windows上開發代碼,雖然Windows上也可以配置Nginx+PHP+MySQL環境,但是,由于測試環境、生產環境都是Linux系統,而且一些功能只能在Linux下運行,還有一些PHP擴展(例如:分布式圖片處理、金山通行證加密擴展),也只能運行在Linux環境中。當我們在Windows上修改完幾行PHP代碼,想馬上看一下執行結果,如果利用FTP之類的工具傳到Linux測試服務器上再測試,就太慢了。如果同一臺Linux測試服務器上,有多少人同時開發,你上傳上去PHP文件,可能會覆蓋別人上傳的同名文件,就沒有辦法做到版本控制。

            [PPT No.5]
            我們從圖中可以看到,假如是程序員A和B都在Windows上開發代碼,由于Nginx與PHP之間采用的是TCP FastCGI協議通訊,因此,兩者可以分離到不同的服務器上。我們可以把Nginx安裝在程序員各自的Windows PC機上,用本機的Nginx處理HTTP請求,用Linux測試服務器上的php-cgi程序,處理PHP請求。程序員在Windows上開發程序,保存之后,不用做任何上傳操作,即可用Linux上的php-cgi調試程序。從圖中這個流程可以看到,首先,兩個程序員分別從SVN版本庫,獲取到一個項目的最新版本,各自進行一些修改。兩人修改程序時,采用的是同一臺Linux測試服務器的php-cgi,對各自PC機上的PHP程序進行調試。在PC機上本地測試沒有問題,可以提交到SVN版本庫。我們做了一個自動同步程序,利用SVN鉤子,在每次發生svn commit提交時,在對應的測試服務器的對應項目路徑內,執行svn update,將最新修改到文件同步到測試服務器。后來發現有一些問題,如果我們一個項目的目錄、程序文件特別多的話,svn update需要遍歷掃描目錄列表,非常慢。因為我們的SVN是和Apache結合起來使用的,Apache可以記錄日志,于是,我們進行了改進,將SVN提交日志記錄到Linux下的命名管道內,再用一個程序從命名管道內讀取日志,只svn update每次修改的幾個文件,這樣,速度就非??炝?。設置hosts為Linux測試服務器的IP,就可以測試多位程序員代碼合并后的效果了。
          Tags:
           ?。ū疚膩碜浴冻绦騿T》雜志2011年01期,《程序員》官網地址:http://www.programmer.com.cn/4544/

            主持人:馮大輝,現任丁香園 (http://www.dxy.cn)網站CTO。曾歷任支付寶架構師、數據庫團隊負責人等職。

          點擊在新窗口中瀏覽此圖片  許式偉:作為系統架構師,您一般會從哪些方面來保證網站的高可用性(降低故障時間)?

            張宴:很多因素都會導致網站發生故障,從而影響網站的高可用性,比如服務器硬件故障、軟件系統故障、IDC機房故障、程序上線前測試未發現的Bug、遭受分布式攻擊、突發訪問人數劇增等。

            一套良好的網站系統架構,應該盡可能地避免只有一臺服務器、一個數據庫、一套軟件節點等單點故障的存在。單點故障一旦發生,將直接導致網站服務不可用,恢復正常服務所需的時間也比較長,甚至還可能無法恢復。負載均衡集群、雙節點熱備、分布式處理等都可以用來解決單點故障,比如提供相同業務的Web服務器、MySQL數據庫從庫,都可以構建負載均衡集群。一旦集群中的一臺服務器、一個服務出現故障,自動實時摘除,對用戶來說是不可感知的,不會影響到整個網站的訪問,可以為運維工程師留下足夠的時間去排查和解決故障。

            對于重要的MySQL數據庫主庫,我們習慣于從硬件層和軟件層來實現熱備,避免單點。越是復雜的設備,發生故障的概率越大。在磁盤沒有損壞的情況下,應用程序導致服務器宕機的概率,遠高于簡單的磁盤陣列宕機的概率。所以,從硬件層解決的話,可以在兩臺服務器上安裝相同的數據庫版本、進行相同的配置,用SAS或SCSI線連接一臺磁盤陣列,將數據庫數據文件存放到盤陣上。正常情況下用服務器A掛載盤陣分區,啟動MySQL,綁定虛擬IP;如果服務器A宕機,則用服務器B掛載盤陣分區,啟動MySQL,接管虛擬IP。從軟件層解決的話,則可以借助DRBD等軟件做鏡像。

            IDC機房發生故障的概率較小,但如果發生的話,影響面也是最大的。如果所有服務器都托管在一個IDC機房,一旦該機房遭遇長時間流量攻擊、斷電、斷網、地方政策性封網等,通常只能聯系IDC去處理,除此之外束手無策,解決時間也比較長。如果成本允許,將網站服務器分布在兩個以上的IDC機房,當某個IDC發生故障時,可以臨時切換DNS域名解析來優先恢復服務。

            雖然程序代碼上線前,經過了測試人員的嚴格測試,但測試環境和生產環境畢竟有差異,所以一些會急劇影響性能、正常服務的Bug往往在程序上線之后,才會被發現,這就要求我們在發現Bug后,能夠迅速回滾到上一正常版本。我們在SVN的基礎上,開發了Web代碼發布系統,會將每個發布版本之間的文件變更記錄下來,一鍵實現程序代碼在多臺Web服務器上的發布和回滾。

            遭遇DDOS分布式拒絕服務攻擊,使用防火墻來對付半連接、假IP,還算比較容易。而那種專挑復雜動態應用程序URL進行的分布式CC攻擊,來源為真實IP、真實HTTP請求,具有模擬正規瀏覽器User-Agent、單個IP的每秒請求數不高、有成千上萬個攻擊源等特征,很難與正常訪問區分開,比較難對付。但是,正常通過瀏覽器訪問一個URL,會加載該URL中引入的JavaScript腳本、CSS樣式、圖片等文件。遇到CC攻擊,需要及時分析日志,找出訪問量異常上漲的URL,然后用事先寫好的shell腳本找出哪些IP的請求只訪問了該URL,而不加載該URL引入的文件,對這些IP進行自動封鎖。

            系統架構設計時,需要事先考慮到高于目前訪問量多少倍的突發訪問。對于網游站點來說,訪問量受廣告集中時間段投放、線上活動的影響較大,帶寬峰值時間不固定,對于靜態內容,可以使用商業CDN,按實際使用量計費。對于動態內容,如果遇到突發訪問人數劇增,超過現有服務器處理能力,最簡單的臨時處理辦法就是增加服務器。上架新服務器需要時間,但是,同一個IDC機房內,可以借助其他業務的服務器,在不同端口開啟一組新進程,加入到原有負載均衡池中。另外,可以臨時關閉一些Web中的次要功能,來減少服務器消耗。



            許式偉:您在任務切分上,有什么經驗分享?您通過哪些手段保證任務的獨立性?

            張宴:相信很多人都遇到過這種情況:在一個老項目上修改、增加一些新功能所花費的時間,不比重新來做一個包含所有功能的新項目時間用得少。一個需要長期維護的項目,不可避免地會面臨老員工的離職、新員工的接手,很多時候,項目代碼的可維護性將決定一個項目的生存周期。讓一個新員工在規定開發時間的壓力下,去面對一個文檔不夠詳細、陌生的、功能復雜的龐大項目,短時間弄明白所有功能邏輯不是一件容易的事。所以,任務需要切分,將一個大的任務切分成一個個小模塊之后,各模塊之間可以做到代碼獨立,互不影響,可維護性也大大增強。

            關于任務切分,我以本人今年負責的兩個重要項目架構設計為例來介紹一下。在第一個項目:金山游戲官網的《用戶行為分析系統》中,由于數據挖掘計算需要消耗較高的內存、CPU資源,一臺服務器的處理能力不夠,而商業的分布式數據倉庫價格又太貴,所以,只有從程序應用中下手,進行任務切分。我們先按需要挖掘的數據指標,將整個數據挖掘任務切分成多個數據挖掘插件,每個插件可以在不同的服務器上運行,多個插件可以同時在多臺服務器上。多個數據挖掘插件之間,如果用到相同的某項數據,那么,就將該項數據以冗余方式,復制幾份提供給需要的插件,從而實現插件之間無交互、無關聯,保證了超大數據量下插件的運算速度。

            在第二個項目:金山游戲新版運營管理系統中,則將整個任務切分成了PHP Web管理界面、PHP Web API功能接口、C/C++中間件引擎三部分。這是一種分層結構切分,最上層的“PHP Web管理界面”調用“PHP Web API功能接口”,“PHP Web API功能接口”調用運行在游戲服務器端的“C/C++中間件引擎”,“C/C++中間件引擎”與“游戲服務器端進程”通過TCP、UDP二進制協議、信號、命令行等多種方式通信。四者之間相對獨立,代碼無關聯,通過一層層API接口實現交互?!癙HP Web管理界面”負責通用界面實現?!癙HP Web API功能接口”內部,又按接入的游戲模塊、子功能模塊進行了更細的切分,各功能模塊之間通過內部API交互?!癈/C++中間件引擎”大而全,不處理具體指令,但兼容TCP、UDP、HTTP、HTTPS/SSL、信號、命令行等大多數通信方式,負責和各種類型的游戲服務端交互。這是一套完全由API接口驅動的系統架構,一款新游戲接入運營管理系統時,只需在“PHP Web API功能接口”中增加一個模塊;一個游戲新管理功能的增加,只需要在“PHP Web API功能接口”中增加一個子模塊。通過任務切分,將復雜功能簡單化,也將原來接入一款新游戲所需要的幾個月時間,縮短為1~2周。



            許式偉:您通過哪些手段,來保障產品的質量?您傾向于多久更新一次您的網站?
            當您看到這篇博客的時候,我們剛剛作出了一個非常艱難的決定。在“房價不降反增,左一個國十條,右一個國五條壓不下房價”之前,在“CPI持續增加、通貨膨脹、物價飛漲、現金貶值”無法緩解之前,在“貸過兩次款,即使賣掉也算第三套房,銀行不予放貸的認房又認貸政策”結束之前,我和老婆經過商量,決定拿出手中擁有的全部現金,賣掉在香港股市的全部股票,變現在宇通客車公司的全部債券投資,刷光信用卡的4萬元限額,再通過多方籌借現金40萬元,以打完97折后的總價145萬元,全款買下位于昌平區的“龍山華府”4號樓的一套3室2廳1衛,101.89平米,南、北、西三面通透,2011年底交房。

            今年年底,地鐵昌平線開通,可乘地鐵昌平線到達西二旗站,與13號線換乘。如果入住后買輛車,可以直接走八達嶺高速到金山軟件大廈。

            今天,交了10萬元訂金,和開發商簽訂了《北京市商品房認購書》。下周交付剩余的135萬元。此役之后,手無分文,所有投資只保留美股市場的部分資金和青島的一處房產,打算借此在兩年內歸還40多萬元借款。

            也許,只有那么一天,當通貨膨脹、貨幣貶值的速度超過了房價的漲速,房價才會相對地降下來。有史可鑒,人民日報1989年2月20日第2版:“北京最近提供2萬多平方米住房,每平方米1600元至1900元。若買兩居室,少說也要6萬多元。一名大學生從參加工作起就日日節衣縮食,每月存儲50元,已是極限,100年才能買上兩居室?!比缃?,20年過去了,按照當時那樣的攢錢法到現在,6萬元能買個幾平米?

            小區效果圖:
            點擊在新窗口中瀏覽此圖片

            戶型圖(點擊圖片看大圖):
            

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

            Mysql-udf-http 是一款簡單的MySQL用戶自定義函數(UDF, User-Defined Functions),具有http_get()、http_post()、http_put()、http_delete()四個函數,可以在MySQL數據庫中利用HTTP協議進行REST相關操作。

            項目網址http://code.google.com/p/mysql-udf-http/
            中文說明http://blog.www.lukangtou.cn/mysql-udf-http/
            使用環境:Linux操作系統,支持的MySQL版本:5.1.x 和 5.5.x。5.0.x未經測試。
            軟件作者:張宴



            一、REST架構風格:

            REST(Representational State Transfer)是一種輕量級的Web Service架構風格,其實現和操作明顯比SOAP和XML-RPC更為簡潔,可以完全通過HTTP協議實現,還可以利用緩存Cache來提高響應速度,性能、效率和易用性上都優于SOAP協議。REST最早是由 Roy Thomas Fielding 博士2000年在論文《Architectural Styles and the Design of Network-based Software Architectures》中提出的,中文譯文全文PDF點此下載。另外,有篇譯文對REST做了一個簡化說明。

            目前,REST架構風格的常見實現是基于HTTP協議及其四種基本方法(如POST、GET、PUT和DELETE)的。有人將HTTP協議的四種方法與CRUD原則相對應,CRUD原則對于資源只需要四種行為:Create(創建)、Read(讀?。?、Update(更新)和Delete(刪除)就可以完成對其操作和處理。

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

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

            在Mysql-udf-http中,四個函數http_post()、http_get()、http_put()、http_delete()分別對應HTTP協議的POST、GET、PUT、DELETE四種方法。

            REST是一種架構風格,而不是協議或標準。HTTP協議“POST、GET、PUT、DELET”四種方法與CRUD原則“Create、Read、Update、Delete”四種行為的一一對應關系只是一種架構設計習慣,而不是規范。因此,POST方法也可以用來更新資源,PUT方法也可以用來創建資源,這就要看具體應用程序作者的定義了。例如Tokyo Tyrant除了支持Memcached協議外,還支持REST方式存取,PUT代表創建和更新,GET代表讀取,DELETE代表刪除(關于Tokyo Tyrant的安裝使用請點擊這兒)。

            目前國內外流行的Web 2.0應用API接口中,很多都支持REST架構風格。例如:新浪微博開放平臺、人人網API、Google OpenID、Flickr、Twitter、eBay、Facebook、Last.fm、del.icio.us、Yahoo Search、Amazon S3、Amazon EC2、Digg、Microsoft Bing、FriendFeed、PayPal、Foursquare,更多...

            當記錄數成百上千萬條時,通常采用 MySQL 分表減低數據庫壓力。但是,全部數據按點擊數、精華、積分排序顯示等功能,在MySQL 分表中則無法實現。編寫 Mysql-udf-http 的最初目的,是為了在項目開發中,將 MySQL 各分表的數據自動同步到我們的 TCSQL 高速列表數據庫,用來做列表查詢、顯示,內容頁則根據ID直接查詢各 MySQL 分表的內容。由于HTTP協議的通用性,通過 Mysql-udf-http 可以做更多的事情。

            通過Mysql-udf-http,你可以在MySQL中利用觸發器,將MySQL的數據同步到支持REST的應用上。例如你有一個獨立博客,你可以在文章表創建MySQL觸發器,這樣,在發表文章時,就可以將文章標題、URL自動同步到新浪微博、Twitter。你想用 Tokyo Tyrant 做緩存,也可以利用MySQL觸發器在發生增、刪、改時,將數據自動同步到 Tokyo Tyrant。詳細配置方法本文第4節中會有介紹。



            二、Mysql-udf-http的安裝與使用:

            1. 在Linux系統上安裝Mysql-udf-http

            注意:“/usr/local/webserver/mysql/”是你的MySQL安裝路徑,如果你的MySQL安裝路徑不同,請自行修改。
            此文為《程序員》雜志約稿,發表在2010年6月刊。

            文章以“KBI用戶行為分析”的項目架構為原型,對Web商業智能平臺的架構設計進行了概要介紹。實現海量數據的分析挖掘計算相對較易,如何以靈活的可擴展性框架,來便捷地應對項目開發周期中,來自眾多項目干系人的需求變更,才是難點。
            書名:《實戰Nginx:取代Apache的高性能Web服務器》
            作者:張宴
            出版社:電子工業出版社
            ISBN號:9787121102479
            出版日期:2010年03月
            字數:430千字
            頁碼:352
            開本:16

            網上書城:
            卓越亞馬遜:http://www.amazon.cn/mn/detailApp/ref=sr_1_1?_encoding=UTF8&s=books&qid=1270279433&asin=B003CHHHB8&sr=8-1
            當當網:http://product.dangdang.com/product.aspx?product_id=20807089&ref=search-0-A
            China-Pub:http://www.china-pub.com/196364
            電子工業出版社書城:http://www.phei.com.cn/bookshop/bookinfo.asp?bookcode=TP102470&booktype=main


            點擊在新窗口中瀏覽此圖片
          Tags: , , , , , , , , , , , , , ,
            [文章作者:張宴 本文版本:v1.0 最后修改:2010.02.05 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/sphinx_search/]

            前言:

            2008年7月,我寫過一篇文章《基于Sphinx+MySQL的千萬級數據全文檢索(搜索引擎)架構設計》。有不少網友希望閱讀全文,我將該文檔整理了一下,分享出來。文檔解壓后大小為7.33M,共19頁。

            本站下載地址: http://blog.www.lukangtou.cn/book/sphinx/sphinx_mysql.zip

            新浪下載分流: http://ishare.iask.sina.com.cn/f/6728201.html

            上述文檔架構存在的局限,我在2008年12月的文章《億級數據的高并發通用搜索引擎架構設計》中已經指出:一是MySQL本身的并發能力有限,在200~300個并發連接下,查詢和更新就比較慢了;二是由于MySQL表的主鍵與Sphinx索引的ID一一對應,從而無法跨多表建立整站查詢,而且新增加類別還得修改配置文件,比較麻煩;三是因為和MySQL集成,無法發揮出Sphinx的優勢。雖然如此,但對于一些寫入量不大的搜索應用,已經足夠了,或許對很多人會有幫助。



            正文:

            在這之后,本人基于《億級數據的高并發通用搜索引擎架構設計》開發的Sphinx分布式通用站內搜索引擎平臺,已經在生產環境運行9個月以上,經過運營中的不斷完善與改進,目前已形成了一套可擴展的分布式通用站內搜索引擎框架。CMS、視頻、論壇等產品發生的增、刪、改操作,文本內容實時寫入自行開發的 HTTPSQS 高性能簡單消息隊列服務,通過隊列控制器更新索引和存儲。提供支持XML、JSON的API查詢接口,支持億級數據的索引、分布式、中文分詞、高亮顯示、自動摘要、準實時(1分鐘內)增量索引更新。

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

            下面是Sphinx新的搜索架構中技術關鍵點實現方式的一些介紹,與大家分享、交流一下:

            1、一元分詞和中文分詞的結合:

           ?、?、一元分詞位于索引更新模塊。Sphinx索引引擎對于CJK(中日韓)語言(必須是UTF-8編碼)支持一元切分,假設【反恐行動是國產主視角射擊網絡游戲】這段文字,Sphinx會將其切成【反 恐 行 動 是 國 產 主 視 角 射 擊 網 絡 游 戲】,然后對每個字建立反向索引。如果用這句話中包含的字組成一個不存在的詞語,例如【恐動】,也會被搜索到,所以搜索時,需要加引號,例如搜索【"反恐行動"】,就能完全匹配連在一起的四個字,不連續的【"恐動"】就不會被搜索到。但是,這樣還有一個問題,搜索【"反恐行動游戲"】或【"國產網絡游戲"】就會搜索不到。對于這個問題,采用位于搜索查詢模塊的中文分詞來處理。

            sphinx.conf配置文件中關于UTF-8中文一元分詞的配置如下:
          ...省略...
          index t_source_main
          {
                  source                  = t_source_main
                  path                    = /data0/search/sphinx/data/t_source_main
                  docinfo                 = extern
                  mlock                   = 0
                  morphology              = none
                  min_word_len            = 1
                  charset_type            = utf-8
                  min_prefix_len          = 0
                  html_strip              = 1
                  charset_table           = 0..9, A..Z->a..z, _, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F
                  ngram_len               = 1
                  ngram_chars             = U+3000..U+2FA1F
          }
          ...省略...


           ?、?、中文分詞位于搜索查詢模塊。搜索“反恐行動游戲”、“國產網絡游戲”,先調用獨立的中文分詞系統,分別切分為“反恐行動 游戲”、“國產 網絡游戲”,這時候,再給以空格分隔的詞語加上引號,去Sphinx搜索【"反恐行動" "游戲"】或【"國產" "網絡游戲"】,就能搜索到這條記錄了。中文分詞詞庫發生增、刪、改,無需重建整個Sphinx搜索索引。



            2、使用自行開發的HTTPSQS(http://code.google.com/p/httpsqs)開源簡單隊列服務程序,來緩沖高并發數據寫入

            新聞、論壇帖子、客服公告、SNS社區等發生的增、刪、改操作,文本內容通過更新接口實時寫入HTTPSQS隊列,再通過隊列控制器更新到Sphinx搜索引擎索引中。



            3、Sphinx不能嚴格按照字段排序的小問題

            如果不想使用權重,只希望嚴格按照時間、主鍵等排序,而匹配模式(Matching modes)又為非SPH_MATCH_BOOLEAN時(比較常用的是SPH_MATCH_ALL、SPH_MATCH_EXTENDED),Sphinx搜索結果在某一頁中的排序會不太準確。例如:按照UNIX時間戳倒序排序,0,20為第一頁,20,40為第二頁,第一頁的最小時間戳一定會大于第二頁的最大時間戳,但是,第一頁中的0,20條記錄卻不會嚴格按照時間戳排序,第二頁亦是如此。因此,如果需要精確排序,用戶翻到搜索結果的某一頁,就需要對Sphinx在某一搜索結果頁中的記錄另行再排序,在我的這套搜索架構中,這一再排序操作由search.php查詢接口使用array_multisort()函數處理。一般情況下,一頁只會顯示5~30條記錄,因此,只對幾十條記錄采用PHP再排序,速度也是非??斓?。



            4、隊列控制器中“時間控制”與“數量控制”相結合,實現搜索索引的1分鐘內準實時更新:

           ?、?、Sphinx 0.9.9生產環境的建索引速度大約在5.5 Mbytes/秒、6400文檔/秒。隊列控制器可以設置10秒鐘更新一次增量索引,只要Sphinx增量索引數據源的文檔數在38萬以內,就能保證增量索引在1~60秒內得到更新,這是從“時間”上進行控制。

           ?、?、為了避免增量索引數據源的文檔數增長到38萬,隊列控制器在增量索引數據源的文檔數超過1萬時,還將激活增量索引合并入主索引的操作,合并完成的文檔將從增量索引數據源中刪除,這是從“數量”上進行控制。
          Tags: , ,
            [文章作者:張宴 本文版本:v1.7.1 最后修改:2011.11.04 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/httpsqs/]

            HTTPSQS(HTTP Simple Queue Service)是一款基于 HTTP GET/POST 協議的輕量級開源簡單消息隊列服務,使用 Tokyo Cabinet 的 B+Tree Key/Value 數據庫來做數據的持久化存儲。

            項目網址http://code.google.com/p/httpsqs/
            使用文檔http://blog.www.lukangtou.cn/httpsqs/
            使用環境:Linux(同時支持32位、64位操作系統,推薦使用64位操作系統)
            軟件作者:張宴

            隊列(Queue)又稱先進先出表(First In First Out),即先進入隊列的元素,先從隊列中取出。加入元素的一頭叫“隊頭”,取出元素的一頭叫“隊尾”。利用消息隊列可以很好地異步處理數據傳送和存儲,當你頻繁地向數據庫中插入數據、頻繁地向搜索引擎提交數據,就可采取消息隊列來異步插入。另外,還可以將較慢的處理邏輯、有并發數量限制的處理邏輯,通過消息隊列放在后臺處理,例如FLV視頻轉換、發送手機短信、發送電子郵件等。

            HTTPSQS 具有以下特征:

            ● 非常簡單,基于 HTTP GET/POST 協議。PHP、Java、Perl、Shell、Python、Ruby等支持HTTP協議的編程語言均可調用。
            ● 非??焖?,入隊列、出隊列速度超過10000次/秒。
            ● 高并發,支持上萬的并發連接,C10K不成問題。
            ● 支持多隊列。
            ● 單個隊列支持的最大隊列數量高達10億條。
            ● 低內存消耗,海量數據存儲,存儲幾十GB的數據只需不到100MB的物理內存緩沖區。
            ● 可以在不停止服務的情況下便捷地修改單個隊列的最大隊列數量。
            ● 可以實時查看隊列狀態(入隊列位置、出隊列位置、未讀隊列數量、最大隊列數量)。
            ● 可以查看指定隊列ID(隊列點)的內容,包括未出、已出的隊列內容。
            ● 查看隊列內容時,支持多字符集編碼。
            ● 源代碼不超過800行,適合二次開發。

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



            1、HTTPSQS 1.7 壓力測試:

            采用Apache ab命令進行壓力測試,開啟10個線程,放入10萬條文本數據(每條512字節)到隊列中:
            使用HTTP Keep-Alive時:23018 requests/sec
            關閉HTTP Keep-Alive時:11840 requests/sec

            采用Apache ab命令進行壓力測試,開啟10個線程,從隊列中取出10萬條文本數據(每條512字節):
            使用HTTP Keep-Alive時:25982 requests/sec
            關閉HTTP Keep-Alive時:13294 requests/sec

            詳細測試內容:http://code.google.com/p/httpsqs/wiki/BenchmarkTest

            生產環境應用:在金山游戲官網中,新聞、論壇帖子、客服公告、SNS社區等發生的增、刪、改操作,文本內容實時寫入HTTPSQS隊列,全站搜索引擎增量索引準實時(1分鐘內)更新的數據源取自HTTPSQS。HTTPSQS 2009年12月18日上線至今,運行穩定,既有來自Web服務器的入隊列操作,也有來自命令行腳本的批量入、出隊列操作。



            2、HTTPSQS 的生產環境應用:

            ●金山通行證(https://my.xoyo.com
            隊列應用類型:手機短信上行、手機短信下發、郵件下發
            隊列應用要求:穩定性高,存儲數據量大
            隊列部署結構:一主、一備兩臺 HTTPSQS 熱備模式

            ●金山用戶行為分析系統(http://kbi.xoyo.com
            隊列應用類型:用戶鼠標點擊、訪問URL原始數據采集
            隊列應用要求:并發性能高,存儲數據量大
            隊列部署結構:多臺 HTTPSQS 應用層哈希分布式模式

            ●金山網絡游戲運營平臺 KingEyes
            隊列應用類型:用戶操作日志記錄

            ●金山逍遙網站內搜索
            隊列應用類型:索引準實時更新。在金山游戲官網中,新聞、論壇帖子、客服公告、SNS社區等發生的增、刪、改操作,文本內容實時寫入HTTPSQS隊列,全站搜索引擎增量索引準實時(1分鐘內)更新的數據源取自HTTPSQS。

            ●金山逍遙網全站通用評論系統
            隊列應用類型:評論發表

            ●金山《劍俠情緣》電視連續劇四大角色人物選秀活動(http://zt.xoyo.com/haixuan/
            隊列應用類型:用戶上傳的照片異步裁剪、縮放處理

            ●新浪郵箱(http://mail.sina.com.cn
            隊列應用類型:用戶登陸日志記錄



            3、HTTPSQS 編譯安裝:
            [文章作者:張宴 本文版本:v1.0 最后修改:2009.11.01 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/dips/]

            2009年10月28日,在金山逍遙技術支持部內部分享會上,介紹了Gearman分布式計算框架與金山逍遙DIPS分布式圖片處理平臺,以下是PPT圖片:

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

            CSDN SD2.0大會官網:http://sd2china.csdn.net/

            新浪科技SD2.0大會專題:http://tech.sina.com.cn/focus/CSDN_2009/

            24日Web分場:http://sd2china.csdn.net/schedule#schedule3

            《高性能Web服務器Nginx及相關新技術的應用實踐》PPT下載:


            FLash版本在線瀏覽:


          Tags: , , ,
            [文章作者:張宴 本文版本:v1.1 最后修改:2010.09.03 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/tcsql/]

            曾經有人提出,一般數據庫緩存分為四種。第一種:單個對象的緩存(一個對象就是數據庫一條記錄),對于單個對象的臨時緩存或永久緩存,用HashMap就可以了,Key-Value方式的Memcached、Memcachedb、Tokyo Tyrant都可以,或者直接對查詢數據庫的網頁采用Squid做緩存,沒什么太難的;第二種:列表緩存,就像論壇里帖子的列表;第三種:記錄條數的緩存,比如一個論壇板塊里有多少個帖子,這樣才方便實現分頁。第四種:復雜一點的group,sum,count查詢,比如一個論壇里按點擊數排名的最HOT的帖子列表。第一種比較好實現,后面三種比較困難,雖然可以通過各種方法來解決,但截至目前,似乎還沒有使用即簡單、并發處理能力又強、實時性又高的解決辦法。



            TCSQL為列表頁的實時緩存而生,是金山逍遙網技術支持部平臺組以Tokyo Cabinet DBM為底層存儲與索引,結合類似Memcached的Key-Value內存對象緩存,借鑒SQL語句的SELECT、INSERT、UPDATE、DELETE思想與功能開發的實時列表緩存數據庫,能夠較好地解決上述前三種類別,特別是第二種、第三種類別的高并發讀寫問題。

            TCSQL采用HTTP GET/POST協議+JSON數據交換格式在客戶端、服務器端之間進行數據交互,支持HTTP協議的任何客戶端或語言(例如JavaScript、PHP、JSP、Perl、Python等),都能夠連接TCSQL服務器進行操作。這就意味著,一些查詢量非常大的應用,甚至可以直接使用運行在用戶瀏覽器端的JavaScript代碼訪問TCSQL數據庫,當然,為了安全起見,你可以在中間用Nginx配以rewrite規則,對TCSQL做個反向代理,限制一下查詢權限。

            利用開源的MySQL UDF自定義函數擴展lib_mysqludf_urlencode、lib_mysqludf_urlencode,以及我們平臺組周洋同學編寫的lib_mysqludf_http_post擴展,配以MySQL觸發器,我們可以在MySQL的某張表發生插入、更新、刪除操作時,自動將數據同步到TCSQL數據庫,使得TCSQL可以當MySQL從庫一樣使用。

            TCSQL實時列表緩存數據庫單機能夠支撐1萬以上的并發連接,QPS(每秒查詢率)能夠達到5000~15000次。

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

            以下是TCSQL在10000并發連接情況下的查詢速度(服務器為浪潮NF190服務器,兩顆雙核Xeon(TM) CPU 2.80GHz、4GB內存、1萬轉SCSI硬盤。):

            1、第一種類型A:主鍵查詢并取出倒序第1條記錄(“=”運算):12155次請求/秒

            查詢內容:http://192.168.8.34:3888/?command=select&type=*&where=pkey:NUMEQ:隨機數值&order_by=pkey&order_sort=NUMDESC&limit_skip=0&limit_max=1

            測試結果:
          引用
          Benchmarking: 10000 clients, running 60 sec.

          Speed=729324 pages/min, 8031913 bytes/sec.
          Requests: 60777 susceed, 0 failed.


            2、第一種類型B:其他索引鍵查詢并取出倒序第1條記錄(“=”運算):11897次請求/秒

            查詢內容:http://192.168.8.34:3888/?command=select&type=*&where=uid:NUMEQ:隨機數值&order_by=pkey&order_sort=NUMDESC&limit_skip=0&limit_max=1

            測試結果:
          引用
          Benchmarking: 10000 clients, running 60 sec.

          Speed=713856 pages/min, 7865884 bytes/sec.
          Requests: 59488 susceed, 0 failed.


            3、第二種類型:根據復合條件查詢并取出倒序前10條記錄:8778次請求/秒(相當于SELECT * FROM table WHERE dateline >= 隨機時間戳 AND idtype = '變換的文本' ORDER BY pkey DESC LIMIT 0,10)

            查詢內容:http://192.168.8.34:3888/?command=select&type=*&where=dateline:NUMGE:隨機時間戳|idtype:STREQ:變換的文本&order_by=pkey&order_sort=NUMDESC&limit_skip=0&limit_max=10

            測試結果:
          引用
          Benchmarking: 10000 clients, running 60 sec.

          Speed=526680 pages/min, 8971878 bytes/sec.
          Requests: 43890 susceed, 0 failed.


            4、第三種類型:統計符合查詢條件的記錄數量:9160次請求/秒(相當于SELECT count(*) FROM table WHERE dateline >= 隨機時間戳 AND idtype = '變換的文本')

            查詢內容:http://192.168.8.34:3888/?command=select&type=count&where=dateline:NUMGE:隨機時間戳|idtype:STREQ:變換的文本

            測試結果:
          引用
          Benchmarking: 10000 clients, running 5 sec.

          Speed=549648 pages/min, 714542 bytes/sec.
          Requests: 45804 susceed, 0 failed.


            發布版本:
            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;
          ?>

            本文已有最新版本:

            請點擊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上也安裝成功)
          分頁: 1/2 第一頁 1 2 下頁 最后頁 [ 顯示模式: 摘要 | 列表 ]
          在线精品国产在线视频