<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/3 第一頁 1 2 3 下頁 最后頁 [ 顯示模式: 摘要 | 列表 ]
            傳承自 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/
            最近配置了幾臺Web服務器,將安裝筆記貼出來吧。沒時間像以前那樣,將文章寫的那樣系統了,請見諒。詳細配置,可以看以前的舊文章:

            http://blog.www.lukangtou.cn/nginx_php_v6

            1、安裝Nginx:
          mkdir -p /Data/tgz
          cd /Data/tgz
          yum install wget
          yum install pcre
          yum install openssl*
          yum -y install gcc gcc-c++ autoconf libjpeg libjpeg-devel libpng libpng-devel freetype freetype-devel libxml2 libxml2-devel zlib zlib-devel glibc glibc-devel glib2 glib2-devel bzip2 bzip2-devel ncurses ncurses-devel curl curl-devel e2fsprogs e2fsprogs-devel krb5 krb5-devel libidn libidn-devel openssl openssl-devel openldap openldap-devel nss_ldap openldap-clients openldap-servers make
          yum -y install gd gd2 gd-devel gd2-devel
          /usr/sbin/groupadd www
          /usr/sbin/useradd -g www www
          ulimit -SHn 65535
          wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.32.tar.gz
          tar zxvf pcre-8.32.tar.gz
          cd pcre-8.32
          ./configure --prefix=/Data/apps/pcre
          make && make install
          cd ../

          wget http://nginx.org/download/nginx-1.5.2.tar.gz
          tar zxvf nginx-1.5.2.tar.gz
          cd nginx-1.5.2
          ./configure --user=www --group=www --prefix=/Data/apps/nginx --with-http_stub_status_module --with-http_ssl_module --with-pcre=/Data/tgz/pcre-8.32 --with-http_realip_module --with-http_image_filter_module
          make
          make install
          cd ../

          Tags: , , , ,

          被CC攻擊

          [不指定 2013-5-21 11:58 | by 張宴 ]
            昨晚開始,我博客在國外的256M內存小VPS,遭到大量IP的CC攻擊,帶寬被占滿,機房為了保證其他VPS的正常訪問,對我的VPS訪問進行了限制。沒辦法,只好用幾KB/秒的速度,將未備份的幾百兆數據遷移回來(幸好內容未變動的幾個G數據,本地已經有備份)。因為域名未備案,于是放在了家中的北京聯通ADSL +  cubieboard 上,恢復了服務。2M的ADSL,上行只有512K帶寬,速度會慢點,等有時間了,將圖片、文件放在別的地方。
            [文章作者:張宴 本文版本:v1.0 最后修改:2011.08.05 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/file_get_contents/]

            有時候,運行 Nginx、PHP-CGI(php-fpm) Web服務的 Linux 服務器,突然系統負載上升,使用 top 命令查看,很多 php-cgi 進程 CPU 使用率接近100%。后來,我通過跟蹤發現,這類情況的出現,跟 PHP 的 file_get_contents() 函數有著密切的關系。

            大、中型網站中,基于 HTTP 協議的 API 接口調用,是家常便飯。PHP 程序員們喜歡使用簡單便捷的 file_get_contents("http://example.com/") 函數,來獲取一個 URL 的返回內容,但是,如果 http://example.com/ 這個網站響應緩慢,file_get_contents() 就會一直卡在那兒,不會超時。

            我們知道,在 php.ini 中,有一個參數 max_execution_time 可以設置 PHP 腳本的最大執行時間,但是,在 php-cgi(php-fpm) 中,該參數不會起效。真正能夠控制 PHP 腳本最大執行時間的是 php-fpm.conf 配置文件中的以下參數:
            默認值為 0 秒,也就是說,PHP 腳本會一直執行下去。這樣,當所有的 php-cgi 進程都卡在 file_get_contents() 函數時,這臺 Nginx+PHP 的 WebServer 已經無法再處理新的 PHP 請求了,Nginx 將給用戶返回“502 Bad Gateway”。修改該參數,設置一個 PHP 腳本最大執行時間是必要的,但是,治標不治本。例如改成 <value name="request_terminate_timeout">30s</value>,如果發生 file_get_contents() 獲取網頁內容較慢的情況,這就意味著 150 個 php-cgi 進程,每秒鐘只能處理 5 個請求,WebServer 同樣很難避免“502 Bad Gateway”。

            要做到徹底解決,只能讓 PHP 程序員們改掉直接使用 file_get_contents("http://example.com/") 的習慣,而是稍微修改一下,加個超時時間,用以下方式來實現 HTTP GET 請求。要是覺得麻煩,可以自行將以下代碼封裝成一個函數。
            當然,導致 php-cgi 進程 CPU 100% 的原因不只有這一種,那么,怎么確定是 file_get_contents() 函數導致的呢?

            首先,使用 top 命令查看 CPU 使用率較高的 php-cgi 進程。

          top - 10:34:18 up 724 days, 21:01,  3 users,  load average: 17.86, 11.16, 7.69
          Tasks: 561 total,  15 running, 546 sleeping,   0 stopped,   0 zombie
          Cpu(s):  5.9%us,  4.2%sy,  0.0%ni, 89.4%id,  0.2%wa,  0.0%hi,  0.2%si,  0.0%st
          Mem:   8100996k total,  4320108k used,  3780888k free,   772572k buffers
          Swap:  8193108k total,    50776k used,  8142332k free,   412088k cached

            PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                              
          10747 www       18   0  360m  22m  12m R 100.6 0.3    0:02.60 php-cgi                                                                                                              
          10709 www       16   0  359m  28m  17m R 96.8  0.4    0:11.34 php-cgi                                                                                                              
          10745 www       18   0  360m  24m  14m R 94.8  0.3    0:39.51 php-cgi                                                                                                              
          10707 www       18   0  360m  25m  14m S 77.4  0.3    0:33.48 php-cgi                                                                                                              
          10782 www       20   0  360m  26m  15m R 75.5  0.3    0:10.93 php-cgi                                                                                                              
          10708 www       25   0  360m  22m  12m R 69.7  0.3    0:45.16 php-cgi                                                                                                              
          10683 www       25   0  362m  28m  15m R 54.2  0.4    0:32.65 php-cgi                                                                                                              
          10711 www       25   0  360m  25m  15m R 52.2  0.3    0:44.25 php-cgi                                                                                                              
          10688 www       25   0  359m  25m  15m R 38.7  0.3    0:10.44 php-cgi                                                                                                              
          10719 www       25   0  360m  26m  16m R  7.7  0.3    0:40.59 php-cgi

            找其中一個 CPU 100% 的 php-cgi 進程的 PID,用以下命令跟蹤一下:
          strace -p 10747

            如果屏幕顯示:
          select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
          poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
          select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
          poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
          select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
          poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
          select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
          poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
          select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
          poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
          select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
          poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
          select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
          poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
          select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
          poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
          select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
          poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
          select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
          poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)

            那么,就可以確定是 file_get_contents() 導致的問題了。
            [文章作者:張宴 本文版本:v1.2 最后修改:2010.05.24 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/nginx_0day/]

            注:2010年5月23日14:00前閱讀本文的朋友,請按目前v1.1版本的最新配置進行設置。

            昨日,80Sec 爆出Nginx具有嚴重的0day漏洞,詳見《Nginx文件類型錯誤解析漏洞》。只要用戶擁有上傳圖片權限的Nginx+PHP服務器,就有被入侵的可能。

            其實此漏洞并不是Nginx的漏洞,而是PHP PATH_INFO的漏洞,詳見:http://bugs.php.net/bug.php?id=50852&edit=1

            例如用戶上傳了一張照片,訪問地址為http://www.domain.com/images/test.jpg,而test.jpg文件內的內容實際上是PHP代碼時,通過http://www.domain.com/images/test.jpg/abc.php就能夠執行該文件內的PHP代碼。

            網上提供的臨時解決方法有:

            方法①、修改php.ini,設置cgi.fix_pathinfo = 0;然后重啟php-cgi。此修改會影響到使用PATH_INFO偽靜態的應用,例如我以前博文的URL:http://blog.www.lukangtou.cn/read.php/348.htm 就不能訪問了。

            方法②、在nginx的配置文件添加如下內容后重啟:if ( $fastcgi_script_name ~ \..*\/.*php ) {return 403;}。該匹配會影響類似 http://www.domain.com/software/5.0/test.php(5.0為目錄),http://www.domain.com/goto.php/phpwind 的URL訪問。

            方法③、對于存儲圖片的location{...},或虛擬主機server{...},只允許純靜態訪問,不配置PHP訪問。例如在金山逍遙網論壇、SNS上傳的圖片、附件,會傳送到專門的圖片、附件存儲服務器集群上(pic.xoyo.com),這組服務器提供純靜態服務,無任何動態PHP配置。各大網站幾乎全部進行了圖片服務器分離,因此Nginx的此次漏洞對大型網站影響不大。



            本人再提供一種修改nginx.conf配置文件的臨時解決方法,兼容“http://blog.www.lukangtou.cn/demo/0day/phpinfo.php/test”的PATH_INFO偽靜態,拒絕“http://blog.www.lukangtou.cn/demo/0day/phpinfo.jpg/test.php”的漏洞攻擊:
          location ~* .*\.php($|/)
          {
                if ($request_filename ~* (.*)\.php) {
                      set $php_url $1;
                }
                if (!-e $php_url.php) {
                      return 403;
                }

                fastcgi_pass  127.0.0.1:9000;
                fastcgi_index index.php;
                include fcgi.conf;
          }


            也可將以下內容寫在fcgi.conf文件中,便于多個虛擬主機引用:
          if ($request_filename ~* (.*)\.php) {
              set $php_url $1;
          }
          if (!-e $php_url.php) {
              return 403;
          }

          fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
          fastcgi_param  SERVER_SOFTWARE    nginx;

          fastcgi_param  QUERY_STRING       $query_string;
          fastcgi_param  REQUEST_METHOD     $request_method;
          fastcgi_param  CONTENT_TYPE       $content_type;
          fastcgi_param  CONTENT_LENGTH     $content_length;

          fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
          fastcgi_param  SCRIPT_NAME        $uri;
          fastcgi_param  REQUEST_URI        $request_uri;
          fastcgi_param  DOCUMENT_URI       $document_uri;
          fastcgi_param  DOCUMENT_ROOT      $document_root;
          fastcgi_param  SERVER_PROTOCOL    $server_protocol;

          fastcgi_param  REMOTE_ADDR        $remote_addr;
          fastcgi_param  REMOTE_PORT        $remote_port;
          fastcgi_param  SERVER_ADDR        $server_addr;
          fastcgi_param  SERVER_PORT        $server_port;
          fastcgi_param  SERVER_NAME        $server_name;

          # PHP only, required if PHP was built with --enable-force-cgi-redirect
          fastcgi_param  REDIRECT_STATUS    200;




            附:文章修改歷史

            ● [2010年05月21日] [Version 1.0] 新建

            ● [2010年05月23日] [Version 1.1] 針對網友michael提出的“如果構造一個形如/..trojan.jpg/dummy.php/?abcd=1,似乎可以繞過防范的nginx配置”,進行了配置修改,防范了此類情況發生。提供測試的URL如下,拒絕漏洞訪問:
            http://blog.www.lukangtou.cn/demo/0day/phpinfo.jpg (里面是PHP代碼)
            http://blog.www.lukangtou.cn/demo/0day/phpinfo.jpg/.php
            http://blog.www.lukangtou.cn/demo/0day/phpinfo.jpg/dummy.php
            http://blog.www.lukangtou.cn/demo/0day/phpinfo.jpg/dummy.php/?abcd=1

            同時兼容正常的PATH_INFO偽靜態請求,測試URL如下:
            http://blog.www.lukangtou.cn/demo/0day/phpinfo.php (這是正常的PHP文件)
            http://blog.www.lukangtou.cn/demo/0day/phpinfo.php/test
            http://blog.www.lukangtou.cn/demo/0day/phpinfo.php/news123.html
            http://blog.www.lukangtou.cn/read.php/348.htm

            ● [2010年05月24日] [Version 1.2] 修正文字描述錯誤。
          Tags: , ,
          引用
            新華網北京4月20日電 國務院決定,為表達全國各族人民對青海玉樹地震遇難同胞的深切哀悼,2010年4月21日舉行全國哀悼活動,全國和駐外使領館下半旗志哀,停止公共娛樂活動。

            4月21日全國哀悼日,將去除網站全站所有站點色彩(變灰),悼念遇難同胞,愿死者安息。

            金山逍遙網旗下站點眾多,雖然官網都有統一的頁頭、頁尾,但是,還有一部分站點(例如用戶中心、注冊充值頁面、游戲客戶端內嵌網站、活動專題頁等)頁頭、頁尾不相同。但是,所有站點采用的都是Nginx服務器,95%以上的站點都經過Nginx負載均衡服務器,因此只需要在Nginx負載均衡服務器上,利用sub_filter指令在輸出的HTML中增加一行:

          <style type="text/css">html {filter:progid:DXImageTransform.Microsoft.BasicImage(grayscale=1); }</style>


            就可以實現在IE及IE內核瀏覽器下,所有網站變灰色。步驟如下:

            1、重新編譯Nginx,增加http_sub_module模塊:
          wget http://nginx.org/download/nginx-0.8.35.tar.gz
          tar zxvf nginx-0.8.35.tar.gz
          cd nginx-0.8.35
          ./configure --user=www --group=www --prefix=/usr/local/webserver/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module
          make && make install
          pkill -9 nginx
          /usr/local/webserver/nginx/sbin/nginx



            2、在nginx.conf配置文件的http {...}大括號內增加以下兩行:
          sub_filter  '</head>'  '<style type="text/css">html {filter:progid:DXImageTransform.Microsoft.BasicImage(grayscale=1); }</style></head>';
          sub_filter_once on;


            保存后,重新加載配置文件:
          /usr/local/webserver/nginx/sbin/nginx -t
          /usr/local/webserver/nginx/sbin/nginx -s reload



            3、如果某些帶有Flash的頁面仍顯示彩色,或瀏覽器上下滾動條拖動時Flash FLV播放器變花(例如劍網3、劍俠世界官網分流頁),將Flash改為JS輸出(本例為SWFObject):
          <script type="text/javascript" src="http://v.xoyo.com/site/v.xoyo.com/web/js/swf.js"></script>
          <div id="video_content"></div>
          <script type="text/javascript">
          <!--
              var video_player_so = new SWFObject("http://api.v.xoyo.com/external/player.swf?autostart=true&config=http://api.v.xoyo.com/external/video-542.swf", "sotester", "439", "246", "7");
              video_player_so.addParam("wmode", "opaque");
              video_player_so.addParam("allowfullscreen","true");
              video_player_so.addParam("allowscriptaccess","always");
              video_player_so.write("video_content");
          //-->
          </script>


            這樣,整個頁面,包括Flash播放器中的視頻就都變灰色了。
          Tags:
            書名:《實戰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: , , , , , , , , , , , , , ,
            [文章作者:張宴 本文版本:v6.3 最后修改:2010.07.26 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/nginx_php_v6/]

            前言:本文是我撰寫的關于搭建“Nginx + PHP(FastCGI)”Web服務器的第6篇文章。本系列文章作為國內最早詳細介紹 Nginx + PHP 安裝、配置、使用的資料之一,為推動 Nginx 在國內的發展產生了積極的作用。本文可能不斷更新小版本,請記住原文鏈接“http://blog.www.lukangtou.cn/nginx_php_v6/”,獲取最新內容。第6篇文章主要介紹了Nginx 0.8.x新的平滑重啟方式,將PHP升級到了5.2.14,修正了PEAR問題。另將MySQL 5.1.x升級到了5.5.x系列,配置文件變更較大。

            鏈接:《2007年9月的第1版》、《2007年12月的第2版》、《2008年6月的第3版》、《2008年8月的第4版》、《2009年5月的第5版

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

            Nginx ("engine x") 是一個高性能的 HTTP 和反向代理服務器,也是一個 IMAP/POP3/SMTP 代理服務器。 Nginx 是由 Igor Sysoev 為俄羅斯訪問量第二的 Rambler.ru 站點開發的,它已經在該站點運行超過三年了。Igor 將源代碼以類BSD許可證的形式發布。

            Nginx 超越 Apache 的高性能和穩定性,使得國內使用 Nginx 作為 Web 服務器的網站也越來越多,其中包括新浪博客、新浪播客、網易新聞、騰訊網、搜狐博客等門戶網站頻道,六間房、56.com等視頻分享網站,Discuz!官方論壇、水木社區等知名論壇,盛大在線、金山逍遙網等網絡游戲網站,豆瓣、人人網、YUPOO相冊、金山愛詞霸、迅雷在線等新興Web 2.0網站。



            Nginx 的官方中文維基:http://wiki.nginx.org/NginxChs



            在高并發連接的情況下,Nginx是Apache服務器不錯的替代品。Nginx同時也可以作為7層負載均衡服務器來使用。根據我的測試結果,Nginx 0.8.46 + PHP 5.2.14 (FastCGI) 可以承受3萬以上的并發連接數,相當于同等環境下Apache的10倍。

            根據我的經驗,4GB內存的服務器+Apache(prefork模式)一般只能處理3000個并發連接,因為它們將占用3GB以上的內存,還得為系統預留1GB的內存。我曾經就有兩臺Apache服務器,因為在配置文件中設置的MaxClients為4000,當Apache并發連接數達到3800時,導致服務器內存和Swap空間用滿而崩潰。

            而這臺 Nginx 0.8.46 + PHP 5.2.14 (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.46 + PHP 5.2.14 (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上也安裝成功)
            [文章作者:張宴 本文版本:v1.1 最后修改:2009.12.01 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/bo-blog_nginx_rewrite/]

            Bo-Blog是一款采用PHP開發的單用戶博客程序,本人的博客也采用的是Bo-Blog,個人覺得bo-blog的排版、易用性要比WordPress好得多,但擴展性不如WordPress。

            很多朋友向我詢問過,Bo-Blog的Nginx Rewrite規則如何寫。由于Bo-Blog官網只提供了Apache的Rewrite規則,這里,我將自己從 Bo-Blog 的 Apache Rewrite 規則轉換而來的 Bo-Blog 2.1.1 的 Nginx Rewrite 重寫規則貼在此處,供需要的朋友使用:
          引用
             if (!-e $request_filename)
             {
                rewrite ^/post/([0-9]+)/?([0-9]+)?/?([0-9]+)?/?$ /read.php?entryid=$1&page=$2&part=$3 last;
                rewrite ^/page/([0-9]+)/([0-9]+)/?$ /index.php?mode=$1&page=$2 last;
                rewrite ^/starred/([0-9]+)/?([0-9]+)?/?$ /star.php?mode=$1&page=$2 last;
                rewrite ^/category/([^/]+)/?([0-9]+)?/?([0-9]+)?/?$ /index.php?go=category_$1&mode=$2&page=$3 last;
                rewrite ^/archiver/([0-9]+)/([0-9]+)/?([0-9]+)?/?([0-9]+)?/?$ /index.php?go=archive&cm=$1&cy=$2&mode=$3&page=$4 last;
                rewrite ^/date/([0-9]+)/([0-9]+)/([0-9]+)/?([0-9]+)?/?([0-9]+)?/?$ /index.php?go=showday_$1-$2-$3&mode=$4&page=$5 last;
                rewrite ^/user/([0-9]+)/?$ /view.php?go=user_$1 last;
                rewrite ^/tags/([^/]+)/?([0-9]+)?/?([0-9]+)?/?$ /tag.php?tag=$1&mode=$2&page=$3 last;
                rewrite ^/component/id/([0-9]+)/?$ /page.php?pageid=$1 last;
                rewrite ^/component/([^/]+)/?$ /page.php?pagealias=$1 last;

                #Force redirection for old rules
                rewrite ^/read\.php/([0-9]+)\.htm$ http://$host/post/$1/ permanent;
                rewrite ^/post/([0-9]+)\.htm$ http://$host/post/$1/ permanent;
                rewrite ^/post/([0-9]+)\_([0-9]+)\.htm$ http://$host/post/$1/$2/ permanent;
                rewrite ^/post/([0-9]+)\_([0-9]+)\_([0-9]+)\.htm$ http://$host/post/$1/$2/$3/ permanent;
                rewrite ^/index\_([0-9]+)\_([0-9]+)\.htm$ http://$host/page/$1/$2/ permanent;
                rewrite ^/star\_([0-9]+)\_([0-9]+)\.htm$ http://$host/starred/$1/$2/ permanent;
                rewrite ^/category\_([0-9]+)\.htm$ http://$host/category/$1/ permanent;
                rewrite ^/category\_([0-9]+)\_([0-9]+)\_([0-9]+)\.htm$ http://$host/category/$1/$2/$3/ permanent;
                rewrite ^/archive\_([0-9]+)\_([0-9]+)\.htm$ http://$host/archiver/$1/$2/ permanent;
                rewrite ^/archive\_([0-9]+)\_([0-9]+)\_([0-9]+)\_([0-9]+)\.htm$ http://$host/archiver/$1/$2/$3/$4/ permanent;
                rewrite ^/showday\_([0-9]+)\_([0-9]+)\_([0-9]+)\.htm$ http://$host/date/$1/$2/$3/ permanent;
                rewrite ^/showday\_([0-9]+)\_([0-9]+)\_([0-9]+)\_([0-9]+)\_([0-9]+)\.htm$ http://$host/date/$1/$2/$3/$4/$5/ permanent;

                #Filename alias
                rewrite ^/([a-zA-Z0-9_-]+)/?([0-9]+)?/?([0-9]+)?/?$ /read.php?blogalias=$1&page=$2&part=$3 last;
             }


            PS:2009-12-01修正一處錯誤,之前文章中的if (!-x更換為if (!-e
            點擊在新窗口中瀏覽此圖片

            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: , , ,
            本文已有最新版本:

            請點擊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上也安裝成功)
            [文章作者:張宴 本文版本: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.0 最后修改:2008.11.28 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/post/382/]

            今天在配置Nginx + PHP + MediaWiki中,發現一個問題:MediaWiki所在的Nginx虛擬主機綁定了多個域名,但是不管通過什么域名訪問MediaWiki首頁,都會被跳轉到其中的一個域名上。Nginx配置文件中沒有相關的rewrite跳轉規則,那么就應該是MediaWiki的PHP程序做的跳轉,但是,遍歷了MediaWiki目錄下的所有文件以及查詢了MySQL數據庫中的每個表,都沒有發現記錄有這個域名。后來,通過查看源代碼發現MediaWiki是根據$_SERVER['SERVER_NAME']做的跳轉,順藤摸瓜,發現了下列問題:

            在一個Nginx虛擬主機中,可以綁定多個server_name,例如:
            點擊在新窗口中瀏覽此圖片

            而server_name的先后順序的不同,對PHP程序中使用$_SERVER["SERVER_NAME"]或getenv('SERVER_NAME')獲取服務器域名是有影響的:
          Tags: ,
            [文章作者:張宴 本文版本:v1.0 最后修改:2008.11.19 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/post/379/]

            在生產應用中,某臺“Nginx+PHP+MySQL”接口數據服務器,扮演的角色十分重要,如果服務器硬件或Nginx、MySQL發生故障,而短時間內無法恢復,后果將非常嚴重。為了避免單點故障,我設計了此套方案,編寫了failover.sh腳本,實現了雙機互備、全自動切換,故障轉移時間只需幾十秒。

            一、雙機互備、全自動切換方案:
            1、拓撲圖:
            點擊在新窗口中瀏覽此圖片

            2、解釋:
            (1)、假設外網域名blog.www.lukangtou.cn解析到外網虛擬IP 72.249.146.214上,內網hosts設置db10對應內網虛擬IP 192.168.146.214

            (2)、默認情況下,由主機綁定內、外網虛擬IP,備機作為備份,當主機的MySQL、Nginx或服務器出現故障無法訪問時,備機會自動接管內、外網虛擬IP。兩臺服務器都啟動負責監控、自動切換虛擬IP的守護進程/usr/bin/nohup /bin/sh /usr/local/webserver/failover/failover.sh 2>&1 > /dev/null &

            (3)、主機和備機上的MySQL服務器互為主從,互相同步。在主機處于活動狀態(即由主機綁定虛擬IP)時,讀寫主機的MySQL,寫到主機的數據會同步到備機;在備機處于活動狀態時,讀寫備機的MySQL,寫到備機的數據會同步到主機(如果主機上的MySQL死掉暫時無法同步,主機上的MySQL恢復后,數據會自動從備機上同步過來,反之亦然)。

            (4)、主機處于活動狀態時,每20秒會把/data0/htdocs/(網頁、程序、圖片存放目錄)、/usr/local/webserver/php/etc/(php.ini等配置文件目錄)、/usr/local/webserver/nginx/conf/(Nginx配置文件目錄)三個目錄下的文件通過rsync推送到備機服務器上的對應目錄(增量推送,兩臺服務器上一樣的文件不會重復推送),反之如果備機處于活動狀態時,每20秒會嘗試把文件推送到主機。rsync的配置文件見兩臺服務器的/etc/rsyncd.conf,rsync守護進程的啟動命令為rsync --daemon

            3、自動切換流程
            (1)、主機默認綁定內、外網虛擬IP,當主機的MySQL、Nginx無法訪問或服務器宕機,主機上的failover.sh守護進程會自動摘除自己綁定的內、外網虛擬IP(如果主機上的failover.sh死掉,無法摘除自己綁定的虛擬IP也沒關系),備機上的failover.sh守護進程會自動接管備機原來綁定的內、外網虛擬IP,并發送ARPing包給內、外網網關更新MAC,強行接管。
          Tags: , , , ,
            [文章作者:張宴 本文版本:v1.0 最后修改:2008.10.28 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/post/375/]

            VPS(全稱Virtual Private Server)是利用最新虛擬化技術在一臺物理服務器上創建多個相互隔離的虛擬私有主機。它們以最大化的效率共享硬件、軟件許可證以及管理資源。對其用戶和應用程序來講,每一個VPS平臺的運行和管理都與一臺獨立主機完全相同,因為每一個VPS均可獨立進行重啟并擁有自己的root訪問權限、用戶、IP地址、內存、過程、文件、應用程序、系統函數庫以及配置文件。

            VPS服務器最重要的指標就是內存大小,多個VPS服務器可以共享一顆CPU,但不能共享同一塊內存。內存越大,價格越貴。

            下面,以我的博客所在的VPS為例,介紹在128M內存下對 Nginx 0.7.x + PHP 5.2.6(FastCGI)+ MySQL 5.1 的優化。

            至于 Nginx + PHP + MySQL 的安裝配置,可參見:《Nginx 0.7.x + PHP 5.2.6(FastCGI)搭建勝過Apache十倍的Web服務器(第4版)



            優化后的效果:

            提供HTTP服務的1個Nginx進程占用11M物理內存,5個php-cgi進程每個占用8M左右物理內存,1個MySQL服務器占用7M物理內存,加上兩個占用內存不大的Nginx和php-cgi父進程,Nginx + PHP + MySQL 系列總共只占用47.7%的物理內存,即62M物理內存(128M * 47.7% ≈ 62M)。

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

            另外,VPS服務器系統自身和其它程序也會使用一些內存,但128M內存的VPS已經夠用??傮w而言,經過優化后,128M內存的VPS跑 Nginx + PHP + MySQL 效果不錯。當然,如果有Money購買更大內存的VPS,就更好了。



            優化項如下:
          Tags: , , , ,
          分頁: 1/3 第一頁 1 2 3 下頁 最后頁 [ 顯示模式: 摘要 | 列表 ]
          在线精品国产在线视频