• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            陳碩的Blog

            Muduo 網(wǎng)絡(luò)編程示例之六:限制服務(wù)器的最大并發(fā)連接數(shù)

            Muduo 網(wǎng)絡(luò)編程示例之六:限制服務(wù)器的最大并發(fā)連接數(shù)

            陳碩 (giantchen_AT_gmail)

            Blog.csdn.net/Solstice  t.sina.com.cn/giantchen

            這是《Muduo 網(wǎng)絡(luò)編程示例》系列的第六篇文章。

            Muduo 全系列文章列表: http://blog.csdn.net/Solstice/category/779646.aspx

             

            本文已以大家都熟悉的 EchoServer 介紹如何限制服務(wù)器的并發(fā)連接數(shù)。

            本文的代碼見 http://code.google.com/p/muduo/source/browse/trunk/examples/maxconnection/

            《Muduo 網(wǎng)絡(luò)編程示例 系列》計劃中的第六篇文章原本是“用于測試兩臺機器的帶寬的 pingpong 程序”,pingpong 協(xié)議的程序已經(jīng)在《muduo 與 boost asio 吞吐量對比》和《muduo 與 libevent2 吞吐量對比》兩篇文章中介紹過了,所以我改為寫另外一個有點意思的主題。

            這篇文章中的“并發(fā)連接數(shù)”是指一個 server program 能同時支持的客戶端連接數(shù),連接系由客戶端主動發(fā)起,服務(wù)端被動接受(accept)連接。(如果要限制應(yīng)用程序主動發(fā)起的連接,則問題要簡單得多,畢竟主動權(quán)和決定權(quán)都在程序本身。)

            為什么要限制并發(fā)連接數(shù)?

            一方面,我們不希望服務(wù)程序超載,另一方面,更因為 file descriptor 是稀缺資源,如果出現(xiàn) file descriptor 耗盡,很棘手(跟 “malloc 失敗/new() 拋出 std::bad_alloc”差不多同樣棘手)。

            我在《分布式系統(tǒng)的工程化開發(fā)方法》一文中曾談到 libev 作者建議的一種應(yīng)對“accept()ing 時 file descriptor 耗盡”的辦法。

             

            幻燈片35

            幻燈片36

            Muduo 的 acceptor 正是這么實現(xiàn)的,但是,這個做法在多線程下不能保證正確,會有 race condition。(思考題:是什么 race condition?)

            其實有另外一種比較簡單的辦法:file descriptor 是 hard limit,我們可以自己設(shè)一個稍低一點的 soft limit,如果超過 soft limit 就主動關(guān)閉新連接,這樣就避免觸及“file descriptor 耗盡”這種邊界條件。比方說當前進程的 max file descriptor 是 1024,那么我們可以在連接數(shù)達到 1000 的時候進入“拒絕新連接”狀態(tài),這樣留給我們足夠的騰挪空間。

             

            Muduo 中限制并發(fā)連接數(shù)


            Muduo 中限制并發(fā)連接數(shù)的做法簡單得出奇。以在《Muduo 網(wǎng)絡(luò)編程示例之零:前言》中出場過的 EchoServer 為例,只需要為它增加一個 int 成員,表示當前的活動連接數(shù)。(如果是多線程程序,應(yīng)該用 muduo::AtomicInt32。)

            class EchoServer
            {
             public:
              EchoServer(muduo::net::EventLoop* loop,
                         const muduo::net::InetAddress& listenAddr,
                         int maxConnections);
            
              void start();
            
             private:
              void onConnection(const muduo::net::TcpConnectionPtr& conn);
            
              void onMessage(const muduo::net::TcpConnectionPtr& conn,
                             muduo::net::Buffer* buf,
                             muduo::Timestamp time);
            
              muduo::net::EventLoop* loop_;
              muduo::net::TcpServer server_;
              int numConnected_; // should be atomic_int
              const int kMaxConnections;
            };

            然后,在 EchoServer::onConnection() 中判斷當前活動連接數(shù),如果超過最大允許數(shù),則踢掉連接。

            void EchoServer::onConnection(const TcpConnectionPtr& conn)
            {
              LOG_INFO << "EchoServer - " << conn->peerAddress().toHostPort() << " -> "
                << conn->localAddress().toHostPort() << " is "
                << (conn->connected() ? "UP" : "DOWN");
            
              if (conn->connected())
              {
                ++numConnected_;
                if (numConnected_ > kMaxConnections)
                {
                  conn->shutdown();
                }
              }
              else
              {
                --numConnected_;
              }
              LOG_INFO << "numConnected = " << numConnected_;
            }
            

            這種做法可以積極地防止耗盡 file descriptor。

            另外,如果是有業(yè)務(wù)邏輯的服務(wù),可以在 shutdown() 之前發(fā)送一個簡單的響應(yīng),表明本服務(wù)程序的負載能力已經(jīng)飽和,提示客戶端嘗試下一個可用的 server(當然,下一個可用的 server 地址不一定要在這個響應(yīng)里給出,客戶端可以自己去 name service 查詢),這樣方便客戶端快速 failover。

             

            后文將介紹如何處理空閑連接的超時:如果一個連接長時間(若干秒)沒有輸入數(shù)據(jù),則踢掉此連接。辦法有很多種,我用 Time Wheel 解決。

            posted on 2011-04-27 00:03 陳碩 閱讀(4892) 評論(9)  編輯 收藏 引用 所屬分類: muduo

            評論

            # re: Muduo 網(wǎng)絡(luò)編程示例之六:限制服務(wù)器的最大并發(fā)連接數(shù) 2011-04-27 00:52 ouyang

            那對于TCP服務(wù)器來說,應(yīng)該限制最大并發(fā)連接數(shù)為多少合適呢?另外,Muduo是否適合用來開發(fā)大并發(fā)(單機2萬+)、短連接、小流量(整體網(wǎng)絡(luò)流量不大)的TCP服務(wù)器?請指點。謝謝!  回復(fù)  更多評論   

            # re: Muduo 網(wǎng)絡(luò)編程示例之六:限制服務(wù)器的最大并發(fā)連接數(shù) 2011-04-27 08:20 陳碩

            @ouyang
            > 限制最大并發(fā)連接數(shù)為多少合適呢?
            看應(yīng)用的復(fù)雜度,看多少個并發(fā)連接就把 CPU 或者 Memory 或者 IO 占滿,然后設(shè)一個比它略小的上限,以保證服務(wù)質(zhì)量。

            > Muduo是否適合用來開發(fā)大并發(fā)(單機2萬+)、短連接、小流量(整體網(wǎng)絡(luò)流量不大)的TCP服務(wù)器?
            應(yīng)該可以,可能要為短連接適當優(yōu)化一下 Acceptor。不過如果是短連接的話,單機并發(fā) 2萬+ 是指什么?同時有 2 萬個連接在線嗎?那這不是長連接嗎?  回復(fù)  更多評論   

            # re: Muduo 網(wǎng)絡(luò)編程示例之六:限制服務(wù)器的最大并發(fā)連接數(shù) 2011-04-27 13:12 ouyang

            比如說可能有幾十萬上百萬個用戶,每個用戶都會連接到服務(wù)器在很短時間內(nèi)(10秒內(nèi))做些數(shù)據(jù)交互,估計最大同時在線的并發(fā)數(shù)在幾萬(2-3萬)左右。不考慮其他因素(出口帶寬、服務(wù)器的內(nèi)存大小)等的影響,光TCP服務(wù)器這塊,如果采用Muduo,需要做些什么特色處理嗎?謝謝!  回復(fù)  更多評論   

            # re: Muduo 網(wǎng)絡(luò)編程示例之六:限制服務(wù)器的最大并發(fā)連接數(shù)[未登錄] 2011-04-27 14:54 陳碩

            @ouyang
            按照你提供的數(shù)據(jù),并發(fā)數(shù) 30000,每個連接存活時間 10 秒,可以計算出至少每秒鐘要 accept 3000 個連接,并斷開 3000 個舊連接(假設(shè)客戶端主動斷開連接,這樣服務(wù)器不進入 time-wait 狀態(tài))。
            對于服務(wù)端,每 accept 一個連接需要收兩個 packet,發(fā)一個 packet。
            每斷開一個連接需要收兩個 packet,發(fā)兩個 packet。
            這樣一生一滅,操作系統(tǒng)每秒鐘要處理 6~7 * 3000 = 18,000 ~ 21,000 個 packet。你確定你的服務(wù)器還有資源處理業(yè)務(wù)嗎?
            如果是單線程,平均每個連接的業(yè)務(wù)處理時間只有 0.3 毫秒,來得及完成任務(wù)嗎?

            對于 muduo,需要做的優(yōu)化是修改 Acceptor::handleRead(),每次 accept N 個連接,而不是 1 個。N 的值可能是 10。
            見下面這篇論文第 5.2 節(jié): http://www.cs.uwaterloo.ca/~brecht/papers/ols-2004.pdf
              回復(fù)  更多評論   

            # re: Muduo 網(wǎng)絡(luò)編程示例之六:限制服務(wù)器的最大并發(fā)連接數(shù) 2011-04-27 23:02 test

            紙上談兵吧
            不會死循環(huán)的  回復(fù)  更多評論   

            # re: Muduo 網(wǎng)絡(luò)編程示例之六:限制服務(wù)器的最大并發(fā)連接數(shù) 2011-04-27 23:10 陳碩

            @test
            這位名為“test”的網(wǎng)友,您測過嗎?  回復(fù)  更多評論   

            # re: Muduo 網(wǎng)絡(luò)編程示例之六:限制服務(wù)器的最大并發(fā)連接數(shù) 2011-04-27 23:43 test

            寫過很多類似代碼。
            超過ulimit maxfile的設(shè)置后,打印超出最大連接。 但不死循環(huán)  回復(fù)  更多評論   

            # re: Muduo 網(wǎng)絡(luò)編程示例之六:限制服務(wù)器的最大并發(fā)連接數(shù) 2011-04-27 23:48 陳碩

            @test
            那你怎么關(guān)閉那個 pending connection ?
            抑或根本不是 level-trigger reactor?  回復(fù)  更多評論   

            # re: Muduo 網(wǎng)絡(luò)編程示例之六:限制服務(wù)器的最大并發(fā)連接數(shù) 2011-04-28 00:15 test

            不處理。
            現(xiàn)在沒有環(huán)境 也不好測試, 搜索了下, 有人說和不同內(nèi)核版本號有關(guān)系。  回復(fù)  更多評論   

            <2011年4月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            1234567

            導(dǎo)航

            統(tǒng)計

            常用鏈接

            隨筆分類

            隨筆檔案

            相冊

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久夜色精品国产| 日产久久强奸免费的看| 久久久久人妻一区二区三区vr| 亚洲欧美日韩精品久久亚洲区| 久久久久久精品无码人妻| 久久人人爽人人爽人人片AV高清 | 国产成人久久激情91| 久久亚洲国产欧洲精品一| 亚洲国产成人精品无码久久久久久综合| 无码8090精品久久一区| 久久亚洲中文字幕精品有坂深雪 | 国产精品青草久久久久婷婷| 国产福利电影一区二区三区久久老子无码午夜伦不 | 伊人伊成久久人综合网777| 久久精品亚洲精品国产色婷| 伊人久久精品线影院| 久久伊人五月丁香狠狠色| 久久精品国产亚洲欧美| 久久SE精品一区二区| 久久久久国产一区二区| 97久久超碰国产精品旧版 | 久久国产色AV免费看| 久久久久久久免费视频| 久久久久亚洲AV综合波多野结衣 | 欧洲国产伦久久久久久久| AV无码久久久久不卡网站下载| 2021久久精品免费观看| 欧美午夜A∨大片久久| 国产精品成人99久久久久91gav| 国产偷久久久精品专区| 亚洲国产天堂久久综合| 久久精品国产亚洲精品| 精品久久久久久国产牛牛app| AV无码久久久久不卡网站下载| 中文精品久久久久人妻| 欧美日韩成人精品久久久免费看| 色综合久久中文综合网| 91精品国产91久久综合| 国产精品久久久亚洲| …久久精品99久久香蕉国产 | 国産精品久久久久久久|