-
1 # 網際網路前沿消費
-
2 # 李淺墨
這個問題其實問得太過於寬泛，不可能有標準答案！因為伺服器支援的併發跟很多有關，比如伺服器本身的配置，網路頻寬的大小，還有本身程式的效能，網站靜態資源的大小等等！
如果你程式比較耗資源，幾時併發都能幹死你。一個頁面圖片幾十M，幾個使用者就卡死！
你可能張問得是，不考慮任何程式本身效能，在普遍的大家用的nginx或者apache情況下，這樣的配置加頻寬能支援多少併發。如果這樣，我覺得此配置併發一萬沒問題！
-
3 # 煙花時光
蟹妖~~關注極迭代，和小夥伴一起看↗↗↗4核8G+10M頻寬屬於比較好的機器了，能夠滿足大部分場景的需要。但要說能支援多少使用者，就不能這樣拍腦袋得到答案。使用者支撐數量是由很多因素構成的，比如用的語言、架構、處理的業務型別、資料大小等等，這是一個不斷調優的過程。首先需要確定業務型別不同的業務會有不同的特點，有些CPU佔用比較高，比如記憶體計算類的；有些記憶體佔用高，比如資料處理類的；有些需要大頻寬，比如網路爬蟲類的；有些磁碟佔用高，比如圖片和資料庫類的。同樣配置的機器跑不同的業務，效果就會天差地別，而且未用到的資源就大大的浪費了。根據自己的業務型別，調整機器的資源配比，是節省資金，提高支撐能力的好辦法。其次確定資料尺寸網路傳輸的資料尺寸決定了頻寬的佔用程度，尺寸越小頻寬越大，單位時間能夠接入和處理的使用者請求就更多。那麼減少無效的資料傳輸，減少請求包的大小，是提高使用者接入能力必須考慮的地方。採用合理的語言架構經過良好設計的系統，和隨意堆砌的系統，接入能力是完全不同的。為了解決資源浪費問題，可以採用Docker之類的容器化，微服務化，能夠有效的提高資源使用率，減少伺服器壓力。採用Nginx或Tengine、開啟NIO、開啟壓縮、以及設定靜態和區域性快取等，降低伺服器負載採用MongoDB、NoSQL資料庫，降低資料查詢壓力提高響應速度....總之一句話：盡力減少前端無效請求，後端盡力將請求在靠近使用者側解決掉，避免業務過長，堆積在後端底層。不斷測算和調優支撐的TPS數，是需要不斷監控不斷調優的。很多時候，一個微小的引數調整，都能帶來成倍的效能提高。一個數十秒的業務請求，也許調優後就能在幾十毫秒完成。真正的線上服務，持續監控和持續調優是長期進行的。♥♥♥♥♥ 請任性點贊，謝謝關注 -- 我是 極迭代 ，我為自己帶鹽 :)
-
4 # 雋永東方
可以大概預測到的是這款配置還是相對較高的配置，以我們官網來說，每天大概500ip，PV大概3000左右，同時線上人數最多不會超過50人吧，這種流量相對一個企業站來說還算可以，這個伺服器完全可以符合要求，目前運行了相當長時間，伺服器沒有出現過任何中斷，擷取Alexa的排名資料僅供參考：
從上方資料看得出來，顯示的速度是Fast，這個速度得分獲得Fast可不容易，我看過好多大型的官網都經常獲得的得分只是中等速度，當然Alexa只是一個參考工具，並不是非常準確，但至少可以側面反應當前站點執行的健康狀況。
我們官網目前採用的是WDCP控制面板下的LNAMP架構，搭載Godaddy SSL，nginx負責前端靜態頁面，apache負責後端動態解釋，整體效能基本是一個非常穩定的狀態，截圖WDCP的伺服器負載給大家看看：
從上圖可以看出伺服器負載幾乎沒太大負載，一般這個負載小於1就幾乎不用去擔心了。
因此結合我們官網的運營情況，我們可以得出你這款配置的峰值併發使用者應該可以到幾百個使用者，這裡有太多因素決定同時併發數了，比如網站圖片影片數量多少，資料庫是否和檔案伺服器分開，每個使用者在站點上開啟的頁面多少等都會影響伺服器負載。
另外這些資料其實都只是一個預估的資料，顯示情況遠比理想狀況複雜很多很多，比如你要是在這臺伺服器安裝配置一些額外的服務，而當前服務執行的程序可能就會直接對伺服器造成負載的提升等等，因此能支援多少使用者這種問題本身就是一個偽命題，要具體情況具體分析，不過可以肯定的是這個配置可以支援絕大部分企業站點的正常執行相當長時間。
最後想我們的解釋能給你一些有用的建議，祝你好運。
這個負載的提升是在伺服器沒有做任何動作的情況下進行的，類似這種時候，你們把伺服器資源用得很滿的那種碰到這種情況如何處理？當然這種情況肯定是很極端的情況，我估計是有攻擊發生，只是不明顯。
-
5 # 江蘺
我們用的貌似是2G那個，帶推流的1180塊那個，詳細懶得去查了，日8000多人速度也沒問題（併發幾百），不過阿里雲的cdn就貌似很不爽，要交25000塊！而且測試並不流暢。阿卡邁的開通流程很麻煩，想用網宿吧，網宿的服務好，但結果是讓我吃了大虧！各位小心網宿的推流陷阱！
-
6 # Selboo
這個要看具體業務實際情況
如果只是簡單 文字檔案 幾k 左右, 幾千沒問題.
如果是下載類, 不好說了.
你可以先使用 10Mbps 頻寬, 阿里雲後臺都有監控圖示. 不夠再加, 用不了在減
回覆列表
併發，是同時訪問網站的人數，這個一天支援幾十萬流量應該沒問題，如果在具體一些沒有資料很難估算。不同業務形態所需要的計算、儲存網路能力都不相同。我們來大概推導一下。
從頻寬來說，10Mbps＝10240KBps，有幾個假設：
1. 假設你的網站大部分都是下行流量，即大部分人都是看帖不回帖的。
2. 每個帖子或者頁面請求資料量（純JSON資料，不包括靜態內容）為5KB（具體要看你們的網站設計了）
3. 網站的平均響應時間為500毫秒，則每個請求需要的下行頻寬為 5KB/0.5S=10KBps
這樣的頻寬能支撐 10240KBps/10KBps=1024 個左右的併發請求數，當然，這只是根據頻寬計算出來的，如果瓶頸不在頻寬這裡，那麼你的併發請求數還要更少一些，這個是由你係統的最短短板決定的。
當然，併發請求數並不代表同時線上人數，假設線上的使用者中，5%的人會同時在某一秒中發起請求（高峰期估計就不止了），反推同時線上的人就是 1024/0.05=20480個，大約支援20480個人同時線上。
一次請求的資料量、響應時間、併發請求佔比這些都是隨便瞎估，需要按你的實際情況和經驗來取。