什麼是session？什麼是cookie？

這裏是修真院後端小課堂，每篇分享文從

【背景介紹】【知識剖析】【常見問題】【解決方案】【編碼實戰】【擴展思考】【更多討論】【參考文獻】

八個方面深度解析後端知識/技能，本篇分享的是：

【什麼是session？什麼是cookie？session和cookie有什麼區別？什麼場景適用於session？什麼場景適用於cookie？    】

1.背景介紹
 

什麼是壓測？

 

壓力測試是經過不斷向被測系統施加「壓力」，測試系統在壓力狀況下的性能表現， 考察當前軟硬件環境下系統所能承受的最大負荷並幫助找出系統瓶頸所在， 也就是咱們能夠模擬巨大的工做負荷以查看應用程序在峯值使用狀況下如何執行操做。

 

爲何要進行壓力測試？

 

壓力測試其實有兩個目的，一是測試應用在高併發狀況下是否會報錯，進程是否會掛掉； 二是測試應用的抗壓能力，預估應用的承載能力，爲運維同窗提供擴容的依據。 第一點很好理解，作好這一點就能夠保證上線以後不出問題了。解釋下第二點，咱們都知道就是架構設計的再優秀，代碼寫的再好， 應對高併發單實例始終是有限的。因此一般是在知足第一點的前提下， 再根據可能到來的高併發壓力來計算須要多少實例來承載，而這就須要咱們壓出極限。

 

接口開發完成以後就能夠進行第一次壓力測試。這一次壓力測試能夠簡單壓一下， 在本機進行就能夠。壓力測試的目的是檢查代碼在高併發下是否會報錯。 另外，編譯型語言要觀察是否存在內存泄漏。 由於本機性能有限，通常來講按照100、200、300、500進程數進行壓力測試， 壓到500若是沒有報錯就能夠進行疲勞測試，觀察內存佔用。

 

2.知識剖析
 

什麼Jmeter?

 

Jmeter 是一款使用Java開發的，開源免費的，測試工具， 主要用來作功能測試和性能測試（壓力測試/負載測試）. 並且用Jmeter 來測試 Restful API, 很是好用。 同時，JMeter能夠幫助你對你的應用程序進行迴歸測試。經過你建立的測試腳本和assertions來驗證你的程序返回了所期待的值。 爲了更高的適應性，JMeter容許你使用正則表達式來建立這些assertions.

 

一、Test Plan (測試計劃)：用來描述一個性能測試， 包含與本次性能測試全部相關的功能。也就說本的性能測試的全部內容是於基於一個計劃的。

 

二、Threads （Users）線程 用戶

 

1) setup thread group 可用於執行預測試操做。這些類型的線程執行測試前進行按期線程組的執行。

 

2) teardown thread group. 可用於執行測試後動做。這些類型的線程執行測試結束後執行按期的線程組。

 

3) thread group(線程組). 這個就是咱們一般添加運行的線程。通俗的講一個線程組,，能夠看作一個虛擬用戶組，線程組中的每一個線程均可以理解爲一個虛擬用戶。 線程組中包含的線程數量在測試執行過程當中是不會發生改變的。

 

Ramp-Up Period：單位是秒，默認時間是1秒。它指定了啓動全部線程所花費的時間， 若是你須要Jmeter當即啓動全部線程，將此設定爲0便可

 

循環次數：表示每一個線程執行多少次請求。

 

三、採樣器（Samplers）它們是每個測試計劃的基本要素，一切都圍繞這些採樣器而工做：採樣器執行請求（基於配置的請求）， 這些請求產生一個或多個響應，後續將被分析。

 

四、監聽器(Listeners)：負責收集測試結果，同時也被告知告終果顯示的方式。 監聽器以報表、樹型結構、或簡明的日誌文件的形式分析結果。 功能是對取樣器的請求結果顯示、統計一些數據（吞吐量、KB/S……）等。

 

五、斷言(Assertions)：用於來判斷請求響應的結果是否如用戶所指望，是否正確。 斷言通常用來設置檢查點，用以保證性能測試過程當中的數據交互是否與預期一致。

 

六、定時器(Timers)：負責定義請求（線程）之間的延遲間隔，模擬對服務器的連續請求。 用於操做之間設置等待時間，等待時間是性能測試中經常使用的控制客戶端QPS的手段。若是不指定，JMeter會一個請求完成後當即執行下一個請求，沒有任何等待時間。

 

七、邏輯控制器(Logic Controllers)：容許自定義JMeter發送請求的行爲邏輯，它與Sampler結合使用能夠模擬複雜的請求序列。

 

八、前置處理器和後置處理器負責在生成請求以前和以後完成工做。 前置處理器經常用來修改請求的設置，後置處理器則經常用來處理響應的數據。

 

九、配置節點(Configuration nodes) 經過使用配置元素你能夠將不一樣的參數傳遞給取樣器請求。他們提供了建立變量（不一樣的和動態的）的一種方式，這些參數以後被採樣器所使用。 在採樣器被執行前，參數所屬節點啓動時，這些參數被執行；這就是爲何採樣器能夠依賴這些變量。

 

測試計劃元素執行順序

 

1–配置節點

 

2–前置處理器

 

3–定時器

 

4–取樣器

 

5–後置處理器（只在有結果可用狀況下執行）

 

6–斷言（只在有結果可用狀況下執行）

 

7–監聽器（只在有結果可用狀況下執行）

 

3.常見問題
 

吞吐量與帶寬的區分

 

利用BadBoy生成測試計劃（測試腳本）

 

4.解決方案
 

吞吐量和帶寬是很容易搞混的一個詞，二者的單位都是Mbps.先讓咱們來看二者對應的英語， 吞吐 量:throughput ; 帶寬: Max net bitrate 。當咱們討論通訊鏈路的帶寬時，通常是指鏈路上每秒所能傳送的比特數。 咱們能夠說以太網的帶寬是10Mbps。可是，咱們須要區分鏈路上的可用帶寬（帶 寬）與實際鏈路中每秒所能傳送的比特數（吞吐量）。 咱們傾向於用「吞吐量」一次來表示一個系統的測試性能。這樣，由於實現受各類低效率因素的影響， 因此由 一段帶寬爲10Mbps的鏈路鏈接的一對節點可能只達到2Mbps的吞吐量。 這樣就意味着，一個主機上的應用可以以2Mbps的速度向另外的一個主機發送 數據。

 

6.擴展思考
 

如何正確作WEB應用的壓力測試
 

1) 首先說一下如何產生壓力，產生壓力的方法有不少，一般能夠寫腳本產生壓力機器人對服務器進行發包和收包操做， 也可使用現有的工具(像jmeter、LoadRunner這些），因此說產生壓力其實並不難，難點在於產生的壓力是否是真實地反映了實際用戶的操做場景。 舉個例子來講，對遊戲來講單純的併發登錄場景在整個線上環境中的佔比可能並不大(新開服等特殊狀況除外)， 相反「登錄-開始戰鬥-結束戰鬥」、不一樣用戶執行不一樣動做這種「混合模式」佔了更大的比重。 因此如何從實際環境中提煉出具體的場景比重，而且把這種比重轉化成實際壓力是一個重要的關注點。

 

2)產生壓力以後，一般咱們能夠拿到TPS、響應時延等性能數據，那麼如何定位性能問題呢？ TPS、響應時延只能告訴你服務器是否存在問題，但不能幫助你定位問題。這些表面背後是整個後臺處理邏輯綜合做用的結果， 這時候能夠先關注系統的CPU、內存、IO、網絡，對比在tps、時延達到瓶頸時這些系統數據的狀況，肯定性能問題是系統哪一部分形成的， 而後再回到代碼的邏輯中逐個優化這些點。

 

3)當服務器的總體性能就能夠相對穩定下來，這時候就須要對本身服務器的承載能力有一個預估， 經過產生真實壓力、對比系統數據，大體能夠對單套系統的處理能力有個真實的評價，而後結合業務規模配置服務器數量。

 

7.參考文獻
 

https://www.jianshu.com/p/c25...

 

http://www.51testing.com/html...

 

 

 

 

 

1.吞吐量與帶寬的區分

 

當咱們討論通訊鏈路的帶寬時，通常是指鏈路上每秒所能傳送的比特數。 咱們能夠說以太網的帶寬是10Mbps。可是，咱們須要區分鏈路上的可用帶寬（帶 寬）與實際鏈路中每秒所能傳送的比特數（吞吐量）。 咱們傾向於用「吞吐量」一次來表示一個系統的測試性能。這樣，由於實現受各類低效率因素的影響， 因此由 一段帶寬爲10Mbps的鏈路鏈接的一對節點可能只達到2Mbps的吞吐量。 這樣就意味着，一個主機上的應用可以以2Mbps的速度向另外的一個主機發送 數據。

 

2. JMeter的做用？

 

.JMeter能夠用於測試靜態或者動態資源的性能（文件、Servlets、Perl腳本、java對象、數據庫和查詢、ftp服務器或者其餘的資源）。JMeter用於模擬在服務器、網絡或者其餘對象上附加高負載以測試他們提供服務的受壓能力，或者分析他們提供的服務在不一樣負載條件下的總性能狀況。你能夠用JMeter提供的圖形化界面分析性能指標或者在高負載狀況下測試服務器/腳本/對象的行爲。

 

3.測試計劃元素執行順序?

 

1–配置節點

 

2–前置處理器

 

3–定時器

 

4–取樣器

 

5–後置處理器（只在有結果可用狀況下執行）

 

6–斷言（只在有結果可用狀況下執行）

 

7–監聽器（只在有結果可用狀況下執行）