關於伺服器在處理效能上的幾個指標

2021-09-26 21:17:15 字數 3110 閱讀 6835

整理一些伺服器效能的指標[email protected]

tps:transactions per second,意思是每秒事務數,具體事務的定義,都是人為的,可以乙個介面、多個介面、乙個業務流程等等。乙個事務是指事務內第乙個請求傳送到接收到最後乙個請求的響應的過程,以此來計算使用的時間和完成的事務個數。

以單介面定義為事務為例,每個事務包括了如下3個過程:

a.向伺服器發請求

b.伺服器自己的內部處理(包含應用伺服器、資料庫伺服器等)

c.伺服器返回結果給客戶端

如果每秒能夠完成n次這三個過程,tps就是n;

如果多個介面定義為乙個事務,那麼,會重複執行abc,完成一次這幾個請求,算做乙個tps。

qps:queries per second,意思是每秒查詢率,是一台伺服器每秒能夠響應的查詢次數(資料庫中的每秒執行查詢sql的次數),顯然,這個不夠全面,不能描述增刪改,所以,不建議用qps來作為系統效能指標。

qps(是每秒查詢率) = 併發數 /  平均響應時間

例如:如果一次性可以處理100個請求,每個請求耗時100毫秒.100÷0.1=1000,則qps = 1000

如果一次性可以處理50個請求,每個請求耗時200毫秒,50÷0.2=250,則qps = 250

公式:( 總pv數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(qps)

機器:峰值時間每秒qps / 單台機器的qps   = 需要的機器

問:每天300w pv 的在單台機器上,這台機器需要多少qps?

答:( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (qps) 

問:如果一台機器的qps是58,需要幾台機器來支援?

答:139 / 58 = 3 

kafka是高吞吐低延遲的高併發、高效能的訊息中介軟體,在大資料領域有極為廣泛的運用。配置良好的kafka集群甚至可以做到每秒幾十萬、上百萬的超高併發寫入。

一般rabbitmq的單機qps在萬級別之內,而kafka的單機qps可以維持在十萬級別,甚至可以達到百萬級。

很明顯的看出kafka的效能遠超rabbitmq。不過這也是理所當然的,畢竟2個訊息佇列實現的協議是不一樣的,處理訊息的場景也大有不同。rabbitmq適合處理一些資料嚴謹的訊息,比如說支付訊息,社交訊息等不能丟失的資料。kafka是批量操作切不報證資料是否能完整的到達消費者端,所以適合一些大量的營銷訊息的場景。

redis單機的話能夠提供5w左右的qps,如果是伺服器讀寫分離可以提供到10w. 關於redis-cluster 集群如果機器太多了會增加溝通互動的成本,所以集群的百萬左右差不多可以了.redis為記憶體型kv系統,處理的資料量要小於hbase與mongodb

hbase基於列儲存,提供三項座標方式定位資料,由於其qualifier的動態可擴充套件型(無需schema設計,可儲存任意多的qualifier),特別適合儲存稀疏表結構的資料(比如網際網路網頁類)。hbase不支援二級索引,讀取資料方面只支援通過key或者key範圍讀取,或者全表掃瞄。

mongodb在類sql語句操作方面目前比hbase具備更多一些優勢,有二級索引,支援相比於hbase更複雜的集合查詢等。bson的資料結構使得處理文件型資料更為直接。mongodb也支援mapreduce,但由於hbase跟hadoop的結合更為緊密,mongo在資料分片等mapreduce必須的屬性上不如hbase這麼直接,需要額外處理。

hbase與mongodb的讀寫效能正好相反,hbase寫優於隨機讀,mongodb似乎寫效能不如讀效能。hbase占用兩台機器能完成的事情,mongodb要占用更多的機器,但是代價就是hbase記錄下東西以後,只能事後通過全表檢索或按照索引範圍的方式進行整體分析,而不能對具體每個人的資料進行實時分析,更強調資料分析能力而不是實時資料查詢能力

擴充套件性表設計負載均衡

failover

事務適用資料量

rdbms

差靈活性較弱

差同步實現

支援萬級

hbase

強十億級行,百萬級列;動態列,每行列可不同。且引入列族和資料多版本概念。

強各元件都支援ha

mvcc, produce lock;行級事務

億級從 ibatis 到 mybatis,不只是名稱上的變化,mybatis 提供了更為強大的功能,同時並沒有損失其易用性,相反,在很多地方都借助於 jdk 的泛型和註解特性進行了簡化.

在 ibatis 中,namespace 不是必需的,且它的存在沒有實際的意義。在 mybatis 中,namespace 終於派上用場了,它使得對映檔案與介面繫結變得非常自然。mybatis中一條sql結束後可以有「;」,而ibatis會報錯,

演算法中執行次數最多的那條語句就是基本語句,通常是最內層迴圈的迴圈體。

只需計算基本語句執行次數的數量級,這就意味著只要保證基本語句執行次數的函式中的最高次冪正確即可,可以忽略所有低次冪和最高次冪的係數。這樣能夠簡化演算法分析,並且使注意力集中在最重要的一點上:增長率。

將基本語句執行次數的數量級放入大ο記號中。

果演算法中包含巢狀的迴圈,則基本語句通常是最內層的迴圈體,如果演算法中包含並列的迴圈,則將並列迴圈的時間複雜度相加。

temp=i; i=j; j=temp;
以上三條單個語句的頻度均為1,該程式段的執行時間是乙個與問題規模n無關的常數。演算法的時間複雜度為常數階,記作t(n)=o(1)。注意:如果演算法的執行時間不隨著問題規模n的增加而增長,即使演算法中有上千條語句,其執行時間也不過是乙個較大的常數。此類演算法的時間複雜度是o(1)。

sum=0;                 //(一次)  

for(i=1;i<=n;i++) //(n+1次)

for(j=1;j<=n;j++) //(n2次)

sum++; //(n2次)

因為θ(2n2+n+1)=n2(θ即:去低階項,去掉常數項,去掉高階項的常參得到),所以t(n)= =o(n2);

a=0;        //1

b=1; // 1

for (i=1;i<=n;i++) // n

t(n)=2+n+3(n-1)=4n-1=o(n).

該演算法程式的時間複雜度為 o(n)

高效能的伺服器處理框架

終於開始學習epoll了,雖然不明白的地方還是很多,但從理論到實踐,相信自己動手去寫乙個具體的框架後,一切會清晰很多。1 首先需要乙個記憶體池,目的在於 減少頻繁的分配和釋放,提高效能的同時,還能避免記憶體碎片的問題 能夠儲存變長的資料,不要很傻瓜地只能預分配乙個最大長度 基於slab演算法實現記憶...

關於Linux與Windows的在伺服器的一些區別

我們平時說學習運維要依託於linux系統,因為在伺服器領域linux基本取得了市場,那麼linux在伺服器領域與windows相比有哪些優勢呢?我們來看下 我們選擇伺服器主要是成本,安全穩定,這兩大方面來考量。成本 眾所周知,linux是免費的開源系統,而windows是閉源收費的作業系統,那麼在選...

一種高效能的伺服器處理框架

by obroot posted 2014年7月28日 0 comment 1 首先需要乙個記憶體池,目的在於 減少頻繁的分配和釋放,提高效能的同時,還能避免記憶體碎片的問題 能夠儲存變長的資料,不要很傻瓜地只能預分配乙個最大長度 基於slab演算法實現記憶體池是乙個好的思路 分配不同大小的多個塊,...