1. <tt id="5hhch"><source id="5hhch"></source></tt>
    1. <xmp id="5hhch"></xmp>

  2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

    <rp id="5hhch"></rp>
        <dfn id="5hhch"></dfn>

      1. 創業者說:項目需要多少服務器之用戶訪問模型

        時間:2024-08-16 04:34:19 創業資訊 我要投稿
        • 相關推薦

        創業者說:項目需要多少服務器之用戶訪問模型

          創業是一個永恒的話題,本文分享“3N技術創投”董事長兼創始人、常盈網絡創始人、一塊去旅游網創始人兼CTO梁劍坤先生在創業過程中的技術心得,為《創業者說:我這個項目需要多少臺服務器?》的技術干貨分享的第2篇,重點講的是“用戶訪問模型”問題,供大家參考(技術大牛們可以根據自己的專業能力,選擇忽略)。

          我這個項目需要多少臺服務器?這是我過去多年經常被問的一個問題,跟著這個問題一起來的,其實還有另外三個問題:1.需要多大硬盤存儲容量才夠?2.需要占用多少網絡帶寬?3.當用戶不斷增多,這個系統以后要怎么擴展?

          硬盤容量的問題上期已經講過了。這次開始進入核心的主題:到底需要多少臺服務器?地球人都知道,需要多少臺服務器是和用戶數/訪問量密切相關的。如果只有很少人訪問你的系統,一臺服務器肯定是夠的(這不是廢話嗎)。關鍵的問題是:一臺服務器到底能支撐多少用戶?

          一、用戶訪問模型

          在回答這個問題之前,必須先建立“用戶訪問模型”。同樣多的用戶數,如果這些用戶平均1 個月只來訪問1 次,那么實際上服務器沒多少壓力。但如果這些用戶平均每幾分鐘都來訪問1 次,顯然要求就不一樣了。所以,實際上“一臺服務器到底能支撐多少用戶”在不同的項目里,答案都是不一樣的,因為每個項目的用戶訪問頻率都不同,簡單說就是“用戶訪問模型”不同。

          1、日活用戶量

          “用戶訪問模型”里的第一個變量,通?梢院唵伪磉_為“平均每天的活躍用戶數”,簡稱“日活用戶數”,意思就是每天來訪問你這個系統的平均用戶數,到底是多少個。“日活用戶數”相同的系統還不能說明其“用戶訪問模型”就是相同的。不同的系統,用戶每天訪問的時間區間、時間段長度是不一樣的。比如閱讀類的應用,可能碎片化分布在除了 睡眠時段的每個小時里;而外賣訂餐類的應用,就只有中午、傍晚兩個高峰時段加起來可能 不到3‐4 個小時有訪客。于是,外賣訂餐類的應用,同樣的“日活用戶數”,在高峰時間對 服務器造成的訪問壓力可能要大于閱讀類的應用,因為用戶都擠在一起了。

          2、每天高峰時間段長度

          為了描述用戶集中訪問的程度,我們通常簡單地用“每天高峰時間段長度”來定義。例如,我們可以假設“每天的訪問量都集中發生在4 小時內”,或“每天的訪問量都集中發生在5分鐘內”(現場投票往往就是這樣的)。

          3、用戶交互次數

          不同的應用,用戶的每次訪問對系統所造成的壓力,其實也是不同的。例如閱讀類的應用,用戶在打開一篇文章的時候會對系統發出一組訪問請求(若干圖片文字的組合),然后用戶在接下來的若干分鐘里,就自己去閱讀這篇文章了,閱讀期間不會對系統產生任何新的負載(假定這個網頁不會自動加載個什么動態廣告之類的玩意)。而電商類的應用,可能用戶要不停地在不同商品頁面之間來回切換比較價格、規格等信息,平均可能瀏覽幾十上百個商品詳情頁面才會下一張訂單。于是,同樣1 個用戶在線使用相同的時間長度,不同的應用會有不同的“用戶交互次數”,我們在“用戶訪問模型”中定義為“平均每次訪問的交互次數”。

          4、平均每次請求響應時間

          同樣1 次交互操作,不同的應用可能產生的負載強度也是不同的。還是以閱讀為例,一篇文章如果包含10 個圖片,打開這篇文章所需要的服務器請求次數可能就是11(文章本身+10 張圖片,忽略可能有的其他特效腳本或廣告)。而對監測健康狀況的應用來說,可能每分鐘才 會連接服務器1 次,把過去1 分鐘內檢測到的呼吸、心跳等信息上傳到服務器。我們用“平 均每次交互所需請求次數”來定義這種差異。最后,同樣是一次請求,不同的應用對響應時間會有所差異。動作類游戲應用可能要求響應時間在毫秒級,而普通商品查詢的應用可以容忍的響應時間則可能在3‐7 秒之間。我們把這 個差異定義為“平均每次請求響應時間”。

          二、服務器并發請求數

          有了上述變量的定義和評估之后,我們可以計算出“服務器并發請求數”:服務器并發請求數=日活躍用戶數*平均每次訪問的交互次數*平均每次交互所需請求次數/(每天高峰時段小時數*3600)*平均每次請求響應時間(秒)

          計算得到的結果,可以簡單地用每1000 個“服務器并發請求數”需要1 臺服務器來估算所需服務器的數量。這里的“1000”只是一個很含糊的參考值,實際上這和具體的“程序猿” 寫程序的水平很有關系,也和具體部署系統軟件的運維“攻城獅”的經驗很有關系。如果找Jeikul 來寫程序并且實施,這個數字可能可以到3000 以上(吹牛不用負責的吧?);如果找Jeikul為了趕項目工期而勉強招聘的實習生來寫程序并且實施的話,這個數字可能只有300(是不是很想吐血?)

          另外,服務器的強勁程度也很有影響,我們總不能要求一臺1 萬塊錢單CPU 傳統機械硬盤的服務器跟一臺5 萬塊錢N 多CPU/內存并且裝了SSD 硬盤的服務器有相同的表現吧?“1000”這個數字可以簡單看作是一臺價格大概2 萬元左右、雙CPU 共8 核(在產型號)、16/32G 內存、10000 轉以上機械硬盤配置的普通服務器的表現。

          總結

          上述“用戶訪問模型”其實只是很抽象的概括,具體到不同的應用其實要引入很多具體不同的變量,既然是創業,必然是定制開發;既然是定制開發,就不可能有統一的公式,必須具 體問題具體分析。

        【創業者說:項目需要多少服務器之用戶訪問模型】相關文章:

        跳槽、行業前景、模型等創業者想問的,鄧力這樣說02-27

        創業者需要“創業者大腦”03-26

        創業者如何真正讀懂用戶需求03-16

        創業者的人格素質模型03-26

        創業者需要具備哪些素質07-04

        成功創業者需要具備的思維05-11

        女性創業者需要堅守的原則03-25

        軟件創業者需要具備的能力02-12

        窗簾創業者需要知道什么11-11

        返鄉創業者需要更多關注01-08

        国产高潮无套免费视频_久久九九兔免费精品6_99精品热6080YY久久_国产91久久久久久无码

        1. <tt id="5hhch"><source id="5hhch"></source></tt>
          1. <xmp id="5hhch"></xmp>

        2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

          <rp id="5hhch"></rp>
              <dfn id="5hhch"></dfn>