• <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ò)編程示例 系列》計(jì)劃中的第六篇文章原本是“用于測試兩臺(tái)機(jī)器的帶寬的 pingpong 程序”,pingpong 協(xié)議的程序已經(jīng)在《muduo 與 boost asio 吞吐量對比》和《muduo 與 libevent2 吞吐量對比》兩篇文章中介紹過了,所以我改為寫另外一個(gè)有點(diǎn)意思的主題。

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

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

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

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

             

            幻燈片35

            幻燈片36

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

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

             

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


            Muduo 中限制并發(fā)連接數(shù)的做法簡單得出奇。以在《Muduo 網(wǎng)絡(luò)編程示例之零:前言》中出場過的 EchoServer 為例,只需要為它增加一個(gè) int 成員,表示當(dāng)前的活動(dòng)連接數(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() 中判斷當(dāng)前活動(dòng)連接數(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ā)送一個(gè)簡單的響應(yīng),表明本服務(wù)程序的負(fù)載能力已經(jīng)飽和,提示客戶端嘗試下一個(gè)可用的 server(當(dāng)然,下一個(gè)可用的 server 地址不一定要在這個(gè)響應(yīng)里給出,客戶端可以自己去 name service 查詢),這樣方便客戶端快速 failover。

             

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

            posted on 2011-04-27 00:03 陳碩 閱讀(4913) 評論(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ā)(單機(jī)2萬+)、短連接、小流量(整體網(wǎng)絡(luò)流量不大)的TCP服務(wù)器?請指點(diǎn)。謝謝!  回復(fù)  更多評論   

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

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

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

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

            比如說可能有幾十萬上百萬個(gè)用戶,每個(gè)用戶都會(huì)連接到服務(wù)器在很短時(shí)間內(nèi)(10秒內(nèi))做些數(shù)據(jù)交互,估計(jì)最大同時(shí)在線的并發(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,每個(gè)連接存活時(shí)間 10 秒,可以計(jì)算出至少每秒鐘要 accept 3000 個(gè)連接,并斷開 3000 個(gè)舊連接(假設(shè)客戶端主動(dòng)斷開連接,這樣服務(wù)器不進(jìn)入 time-wait 狀態(tài))。
            對于服務(wù)端,每 accept 一個(gè)連接需要收兩個(gè) packet,發(fā)一個(gè) packet。
            每斷開一個(gè)連接需要收兩個(gè) packet,發(fā)兩個(gè) packet。
            這樣一生一滅,操作系統(tǒng)每秒鐘要處理 6~7 * 3000 = 18,000 ~ 21,000 個(gè) packet。你確定你的服務(wù)器還有資源處理業(yè)務(wù)嗎?
            如果是單線程,平均每個(gè)連接的業(yè)務(wù)處理時(shí)間只有 0.3 毫秒,來得及完成任務(wù)嗎?

            對于 muduo,需要做的優(yōu)化是修改 Acceptor::handleRead(),每次 accept N 個(gè)連接,而不是 1 個(gè)。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ì)死循環(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)閉那個(gè) 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)核版本號(hào)有關(guān)系。  回復(fù)  更多評論   

            <2025年8月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            隨筆分類

            隨筆檔案

            相冊

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久天天躁狠狠躁夜夜不卡| 91精品国产9l久久久久| 久久久99精品一区二区| 久久久久亚洲av毛片大| 久久免费看黄a级毛片| 国产人久久人人人人爽| 亚洲一区二区三区日本久久九| 99久久亚洲综合精品网站| 久久亚洲国产精品123区| 蜜臀av性久久久久蜜臀aⅴ| 久久精品国产一区二区三区| 人妻少妇久久中文字幕一区二区 | 国产精品禁18久久久夂久| 一本久久久久久久| 久久无码人妻一区二区三区| 久久久久亚洲爆乳少妇无| 国产成人精品久久一区二区三区| 亚洲国产成人精品91久久久| 夜夜亚洲天天久久| 国产精品99久久99久久久| 国产偷久久久精品专区| 香蕉99久久国产综合精品宅男自 | 思思久久好好热精品国产| 91久久成人免费| 精品久久久久久中文字幕| 中文无码久久精品| 亚洲精品美女久久777777| 日韩欧美亚洲综合久久 | 久久精品无码一区二区WWW| 久久精品国产一区二区电影| 久久夜色tv网站| 久久国产精品久久国产精品| 久久婷婷五月综合97色| 久久久久人妻精品一区 | 亚洲国产日韩欧美综合久久| 激情久久久久久久久久| 94久久国产乱子伦精品免费 | 少妇久久久久久久久久| 色8久久人人97超碰香蕉987| 人妻少妇久久中文字幕| 国内精品久久久久伊人av|