創業是一個永恆的話題，本文分享「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 轉以上機械硬碟配置的普通伺服器的表現。
總結
上述「使用者走訪模型」其實只是很抽像的概括，具體到不同的套用其實要引入不少具體不同的變數，既然是創業，必然是定製開發；既然是定製開發，就不可能有統一的公式，必需具 體問題具體分析。
好啦，現在你已曉得你的系統需要多少台伺服器了，但你曉得這N 台伺服器怎麼組網部署形成一個能有效運轉的系統嗎？下一期，詳細為你解答！
（轉載請聯絡作者，微信公家號：benshoushe；微博：@笨手蛇）。
創業是一個永恆的話題，本文分享「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 轉以上機械硬碟配置的普通伺服器的表現。
總結
上述「使用者走訪模型」其實只是很抽像的概括，具體到不同的套用其實要引入不少具體不同的變數，既然是創業，必然是定製開發；既然是定製開發，就不可能有統一的公式，必需具 體問題具體分析。
好啦，現在你已曉得你的系統需要多少台伺服器了，但你曉得這N 台伺服器怎麼組網部署形成一個能有效運轉的系統嗎？下一期，詳細為你解答！兩岸商貿,在家工作,網路創業,創業賺錢思惟,微商平台,賺新台幣
（轉載請聯絡作者，微信公家號：benshoushe；微博：@笨手蛇）。
留言列表
