❶ 性能測試主要測試什麼
問題一：軟體測試中性能測試需要關注什麼 性能測試需要關注的第3件事，就是被測系統所處的操作系統環境。要破譯它，必須要學會凌駕它的命令，不論是windows，unix，還是liunx，皆如此。淘寶用的是liunx，於是我們自然要學會活用liunx命令。在性能測試過程中，我們往往要查詢伺服器資源使用情況，例如cpu,load,i/o等。此時，top命令、uptime命令、iostat命令就顯得尤為重要。在性能測試過程中，我們往往要查詢伺服器的log信息。此時，cd命令、vi/vim命令、cat命令、grep命令、tail命令就能大顯身手。在性能測試過程中，我們往往要查看某個進程使用的虛擬內存和物理內存。此時，cat /proc/pid/status就十分有用。在性能測試過程中，我們往往要查看某個文件佔用了大量的空間。此時，find命令派上用場。此處不一一列舉。上述這些命令，均可以根據實際情況，配以對應的參數，進行更好的跟蹤來採集所需要的數據。liunx命令的靈活應用，配合shell的語法規則，能寫出許多非常使用的小腳本。這些東西，對於性能測試，及性能測試結果分析，都有相當重要的意義。
問題二：軟體性能測試需要會什麼 這個你算問對人了。給你說幾點吧，為什麼性能測試在軟體測試裡面算是吃香的，因為他的要求也比較多，需要掌握：網路方面、資料庫方面（Oracle、sqlserver、mysql）、操作系統（如Linux方面）、腳本（如shell）、性能測試工具、資源監控工具、瓶頸定位工具，以及分析問題的能力。除此在外要對Java或要有一定了解。尤其是內存機制方面。如果你想成為一名合格的性能測試工程師的話 ，慢慢學吧
問題三：性能測試應該做哪些准備 環境搭建：這個根據實際規劃，我在企業內做過的性能測試搭建的環境都是和用戶上線使用的實際環境一樣的。
數據准備：個人感覺是整個工作里第二耗時的，需要真實模擬用戶數據，這個不是單單的創建幾個帳號就完事的，每個用戶基本都會有不太一樣的配置，實際操作的時候部署數據的腳本都寫到手軟。
腳本編譯：選擇性能工具編譯性能腳本，你需要跑什麼業務流程就編譯什麼樣的腳本。
腳本執行：用規劃好的用戶數執行腳本，這個一般持續很長時間，時間太短不足以暴露伺服器等的性能瓶頸，性能測試中最耗時的就是這個步驟。
收集日誌：在執行腳本完成後收集到的能客觀反應系統性能的日誌、報表文件，比如LR的報告、資料庫的AWR日誌等等。
分析結果：分析收集到的日誌、報表，找出性能瓶頸或是得出性能指標結果。這個一般需要對資料庫或者底層非常了解的專業人士來分析，一般測試人員只需要提供收集到的報告就差不多了。
生成報告：將上面所有的性能測試活動整理總結，輸出測試報告。
問題四：要做好性能測試，該掌握些什麼？ 這類問題之前也被問到很多次了，所以這次乾脆整理一下，發個主題供同行們參考。如果需要補充，也歡迎大家留言一起討論。 如果想真的做好性能測試，需要學習的東西還是比較多的。簡單列一下吧。 1. 精通性能測試的基本概念，過程，方法論，了解性能工程；
3. 扎實的計算機專業基礎知識，包括計算機組成原理、操作系統、資料庫原理、計算機網路原理；
4. 熟悉至少1個常用的資料庫產品，例如SQL Server或者 Oracle，能進行一般的資料庫管理操作，熟悉SQL腳本的使用，熟悉常用的數據調優工具和常用的counter；
5. 熟悉至少一個操作系統的原理，Windows或者Linux都可以，熟悉操作系統的體系架構、操作系統的重要基礎概念，以及內存管理、存儲/文件系統、驅動/硬體的管理、網路協議的實現及構成、性能的監控方法和原理，熟悉常用的counter；
6. 熟悉至少一個web server 產品，例如apache，了解一般的配置和常用的counter；
7. 熟悉至少一個應用伺服器產品，例如tomcat，了解一般的配置，熟悉常用的伺服器性能監控方法和原理，熟悉常用的counter；
8. 至少熟悉TCP/IP協議，熟悉HTTP協議，至少見過並了解三層、四層交換或者路由器的使用和配置。了解常用的與網路性能相關的counter；
9. 了解一般的大型企業應用的部署架構和應用架構；
10. 了解知名大型web應用、高並發量、高流量、實時響應要求高的超大規模網站的架構和優化歷程；
11. 熟悉統計學的基礎知識、常用分析方法以及實驗設計方法，了解數學建模相關的知識；
12. 熟悉專屬行業的業務知識和用戶場景，例如電信行業的OSS系統所涉及的業務知識和用戶場景，證券交易系統所涉及的業務知識和用戶場景；
13. 大量的實際性能測試及優化經驗；
14. 積極的參與到各類圈子、社團的討論和交流、分享中。 暫時先想到了這么多，有興趣的朋友可以一起討論一下，相信每個人都有自己不同的經歷和感想，可以跟其他人分享一下，提供參考。
另外，我之前也整理發布過不少性能測試方面的資料，從入門級的文章到 升級的必讀都有一些，有興趣可以參考。
問題五：性能測試的內容 性能測試 在軟體的質量保證中起著重要的作用，它包括的測試內容豐富多樣。中國軟體評測中心將性能測試概括為三個方面：應用在客戶端性能的測試、應用在網路上性能的測試和應用在伺服器端性能的測試。通常情況下，三方面有效、合理的結合，可以達到對系統性能全面的分析和瓶頸的預測。 應用在客戶端性能測試的目的是考察客戶端應用的性能，測試的入口是客戶端。它主要包括並發性能測試、疲勞強度測試、大數據量測試和速度測試等，其中並發性能測試是重點。並發性能測試是重點並發性能測試的過程是一個負載測試和壓力測試的過程，即逐漸增加負載，直到系統的瓶頸或者不能接收的性能點，通過綜合分析交易執行指標和資源監控指標來確定系統並發性能的過程。負載測試（Load Testing）是確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統組成部分的相應輸出項，例如通過量、響應時間、CPU負載、內存使用等來決定系統的性能。負載測試是一個分析軟體應用程序和支撐架構、模擬真實環境的使用，從而來確定能夠接收的性能過程。壓力測試（Stress Testing）是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。並發性能測試的目的主要體現在三個方面：以真實的業務為依據，選擇有代表性的、關鍵的業務操作設計測試案例，以評價系統的當前性能；當擴展應用程序的功能或者新的應用程序將要被部署時，負載測試會幫助確定系統是否還能夠處理期望的用戶負載，以預測系統的未來性能；通過模擬成百上千個用戶，重復執行和運行測試，可以確認性能瓶頸並優化和調整應用，目的在於尋找到瓶頸問題。當一家企業自己組織力量或委託軟體公司代為開發一套應用系統的時候，尤其是以後在生產環境中實際使用起來，用戶往往會產生疑問，這套系統能不能承受大量的並發用戶同時訪問? 這類問題最常見於採用聯機事務處理(OLTP)方式資料庫應用、Web瀏覽和視頻點播等系統。這種問題的解決要藉助於科學的軟體測試手段和先進的測試工具。舉例說明：電信計費軟體眾所周知，每月20日左右是市話交費的高峰期，全市幾千個收費網點同時啟動。收費過程一般分為兩步，首先要根據用戶提出的電話號碼來查詢出其當月產生費用，然後收取現金並將此用戶修改為已交費狀態。一個用戶看起來簡單的兩個步驟，但當成百上千的終端，同時執行這樣的操作時，情況就大不一樣了，如此眾多的交易同時發生，對應用程序本身、操作系統、中心資料庫伺服器、中間件伺服器、網路設備的承受力都是一個嚴峻的考驗。決策者不可能在發生問題後才考慮系統的承受力，預見軟體的並發承受力，這是在軟體測試階段就應該解決的問題。大多數公司企業需要支持成百上千名用戶，各類應用環境以及由不同供應商提供的元件組裝起來的復雜產品，難以預知的用戶負載和愈來愈復雜的應用程序，使公司擔憂會發生投放性能差、用戶遭受反應慢、系統失靈等問題。其結果就是導致公司收益的損失。如何模擬實際情況呢? 找若乾颱電腦和同樣數目的操作人員在同一時刻進行操作，然後拿秒錶記錄下反應時間？ 這樣的手工作坊式的測試方法不切實際，且無法捕捉程序內部變化情況，這樣就需要壓力測試工具的輔助。測試的基本策略是自動負載測試，通過在一台或幾台PC機上模擬成百或上千的虛擬用戶同時執行業務的情景，對應用程序進行測試，同時記錄下每一事務處理的時間、中間件伺服器峰值數據、資料庫狀態等。通過可重復的、真實的測試能夠徹底地度量應用的可擴展性和性能，確定問題所在以及優化系統性能。預先知道了系統的承受力，就為最終用戶規劃整個運行環境的配置提供了有力的依據。並發性能測試前的准備工作測試環境：配置......>>
問題六：軟體性能測試的目的 為了驗證系統是否達到用戶提出的性能指標，同時發現系統中存在的性能瓶頸，起到優化系統的目的。
問題七：軟體測試一般都用到哪些工具 測試工具分為很多種，主要如下：
測試管理工具：MQC，TestManager，QACenter，其中缺陷跟蹤還可以使用：變更管理工具
功能測試自動化：QTP，RFP，QARun，Silk
性能測試工具：Loadrunner，Robot，QAload，WAS，Silk Performance
單元、白盒測試工具：Junit,Jmeter，devpartner，骸probe，Purify Plus
安全測試： Appscan，Fortify
問題八：手機軟體的測試主要有哪些方面去測試，性能測試用什麼去測試好？ 羅列幾個比較有代表性的方向：
功能測試
性能測試
穩定性測試
安全測試
兼容性測試
網路環境測試
位置定位測試等
如何做性能測試：
明確測試目標，了解性能測試需求
編寫性能測試計劃
分析性能測試需求
編寫性能測試方案、設計測試場景
相關資源准備(人力資源、硬體資源、軟體資源)
測試程序開發，腳本維護、測試數據准備、測試監控准備
執行性能測試並收集測試結果
分析結果
系統調優及再測試
現今的安卓開發環境，碎片化現象十分嚴重。安卓機型鋪天蓋地，很多中小型研發團隊缺少測試環境，也沒有資金和精力購全機型，這時就引入了一個雲真機測試的概念。WeTest平台的雲真機測試 wetest.qq/... 平台提供上千台真實的安卓主流機型，隨時隨地進行測試，提供截圖、實時日誌和各種性能數據。
如果以上回答能幫助到你那就最好不過了~
問題九：測試主板性能的軟體有哪些 WinBench 99可以用來測試各個部件的性能的。你可以用3DMARK測試一下電腦各個部件的性能，一般上3DMARK所有項目都通過的話，就說明主板和其他部分沒有什麼沖突的問題了。
問題十：app的性能測試到底是測什麼意思 app的性能測試要關注
包體大小、CPU 佔用率、圖片處理器每秒刷新的幀數、內存使用、電量、流量等等
❷ 如何使用正確的姿勢進行搜索
安裝
如果你有 linux，並且恰好也有 docker， 那麼請運行如下命令：
sudo docker run -d -p 9200:9200 -p 9300:9300 elasticsearch
你要是看到一串 id， 恭喜你， 你已經有了自己的搜索了！就是這么簡單！
我們來驗證一下搜索服務：
ubuntu:~$ curl localhost:9200
{
"status" : 200,
"name" : "Adonis",
"cluster_name" : "elasticsearch",
"version" : {
"number" : "1.7.1",
"build_hash" : "",
"build_timestamp" : "2015-07-29T09:54:16Z",
"build_snapshot" : false,
"lucene_version" : "4.10.4"
},
"tagline" : "You Know, for Search"
}
返回值 200！你成功了！這個結果除了告訴你 Elastic Search 已經啟動好之外，還顯示了版本號，build 信息，lucene 版本等信息。
如果你不用 Linux 或者 Docker，放心，情況也不復雜。首先你需要 Java，然後去官網下載，解壓，運行既可。
使用
Elastic Search 的初級功能十分易用。Restful 請求就可以完成一切操作。所以接下來的體驗，你只需要一個命令行即可，但是為了直觀方便，你也可以選擇官方推薦的 Marvel 或者 Postman。
相信很多人都是吃貨，下面，我用中國第九大菜系食堂菜作為搜索的原數據演示 Elastic Search 的用法。
插入數據
首先來一道勉強正常的菜，蘋果燉牛肉。
ubuntu:~$ curl -XPOST localhost:9200/food/canteen?pretty -d '{title: "蘋果燉牛肉", source: "sjtu"}'
{
"_index" : "food",
"_type" : "canteen",
"_id" : "AU8HEQxfW68mQc8rk4AS",
"_version" : 1,
"created" : true
}
有點迷糊？那來稍微介紹一點背景知識，看看上面的命令都做了啥。
Elastic Search 使用 document 方式存儲， 類似 MongoDB。它不僅高效而且分布式擴展性極佳，基於赫赫有名的 Lucene 搭建，在搜索界的地位就如同傑倫小公舉在歌壇的地位一般。很多人可能有關系型資料庫開發的經驗，下面來張 Elastic Search 和 MySQL 的術語類比圖，幫助理解。
MySQL
Elastic Search
Database Index
Table Type
Row Document
Column Field
Schema Mappping
Index Everything Indexed by default
SQL Query DSL
上面例子中，localhost:9200是服務地址，Elastic Search 默認利用 9200 作為 Rest 服務的埠，9300 作為內部通信介面和 Java 客戶端介面。food是 index，canteen是 type，裡面的數據形成document。值得注意的是，跟其他 NoSQL 資料庫一樣，Schema 不需要預先定義，直接插入數據即可，Elastic Search會智能地分析每個 Field 的值並自動建立索引。每個 document 都有一個 id，如果不指定則會自動生成。可以看到插入成功之後，生成了"_id" : "AU8HEQxfW68mQc8rk4AS"。插入命令使用 Post 請求，方便使用和測試。
另外，在上面的例子中，我加入了?pretty主要是讓結果的 json 顯示更好看。
獲取數據
雖然數據已經存好了，但是沒有直接取到，總是心有不安，下面這條命令即可以查看數據：
ubuntu:~$ curl -XGET localhost:9200/food/canteen/AU8HEQxfW68mQc8rk4AS?pretty
{
"_index" : "food",
"_type" : "canteen",
"_id" : "AU8HEQxfW68mQc8rk4AS",
"_version" : 1,
"found" : true,
"_source":{title: "蘋果燉牛肉", source: "sjtu"}
}
可以看到，請求改為了GET，請求形式為/index/type/id。
更新數據
再來一道菜，番茄炒菠蘿，用到我們剛才說的POST請求。
ubuntu:~$ curl -XPOST localhost:9200/food/canteen?pretty -d '{title: "番茄炒菠蘿", source: "sjtu"}'
{
"_index" : "food",
"_type" : "canteen",
"_id" : "AU8HQW0-W68mQc8rk4Ab",
"_version" : 1,
"created" : true
}
等等，這道菜是武漢大學的，看來我們得更新一下source。也許聰明的你已經猜到，發個PUT請求就可以搞定了。
ubuntu:~$ curl -XPUT localhost:9200/food/canteen/AU8HQW0-W68mQc8rk4Ab?pretty -d '{title: "番茄炒菠蘿", source: "whu"}'
{
"_index" : "food",
"_type" : "canteen",
"_id" : "AU8HQW0-W68mQc8rk4Ab",
"_version" : 2,
"created" : false
}
可以看到_version變成了2，表示更新過了。再GET一下確認結果。
ubuntu:~$ curl -XGET localhost:9200/food/canteen/AU8HQW0-W68mQc8rk4Ab?pretty
{
"_index" : "food",
"_type" : "canteen",
"_id" : "AU8HQW0-W68mQc8rk4Ab",
"_version" : 2,
"found" : true,
"_source":{title: "番茄炒菠蘿", source: "whu"}
}
可以看到，_source，也就是插入的原始數據，確實改變了。
刪除數據
繼續來一道菜，月餅炒辣椒！
ubuntu:~$ curl -XPOST localhost:9200/food/canteen?pretty -d '{title: "月餅炒辣椒", source: "fjnu"}'
{
"_index" : "food",
"_type" : "canteen",
"_id" : "AU8HRPoOW68mQc8rk4Ac",
"_version" : 1,
"created" : true
}
算了，好像太喪心病狂了，對吃貨的幼小心靈產生了暴擊，我們還是把它刪掉吧。
ubuntu:~$ curl -XDELETE localhost:9200/food/canteen/AU8HRPoOW68mQc8rk4Ac?pretty
{
"found" : true,
"_index" : "food",
"_type" : "canteen",
"_id" : "AU8HRPoOW68mQc8rk4Ac",
"_version" : 2
}
GET驗證一下是否真的被刪除了。
ubuntu:~$ curl -XGET localhost:9200/food/canteen/AU8HRPoOW68mQc8rk4Ac?pretty
{
"_index" : "food",
"_type" : "canteen",
"_id" : "AU8HRPoOW68mQc8rk4Ac",
"found" : false
}
顯示"found" : false，可見刪除確實成功了。
搜索數據
Elastic Search 支持相當復雜的搜索情形。像「有水果有肉有主食紅黃白相間成粒狀」這種可以把 MySQL 的檢索虐得死去活來的查詢，Elastic Search 可以輕松告訴你這應該是名菜「哈密瓜年糕牛肉粒」。下面看看最簡單卻很實用的搜索：查詢所有值。
ubuntu:~$ curl -XGET localhost:9200/food/canteen/_search?pretty
{
"took" : 1,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"failed" : 0
},
"hits" : {
"total" : 2,
"max_score" : 1.0,
"hits" : [ {
"_index" : "food",
"_type" : "canteen",
"_id" : "AU8HEQxfW68mQc8rk4AS",
"_score" : 1.0,
"_source":{title: "蘋果燉牛肉", source: "sjtu"}
}, {
"_index" : "food",
"_type" : "canteen",
"_id" : "AU8HQW0-W68mQc8rk4Ab",
"_score" : 1.0,
"_source":{title: "番茄炒菠蘿", source: "whu"}
} ]
}
}
可以看到，形如GET _search即可。結果會顯示所有給定 index 和 type 下的 document。hits下麵包含找到的具體內容。_score表示相關程度，分數越高表示越相關，搜索引擎對於結果的排序都是通過類似的機制完成。
再來一個簡單地查詢，查找source是sjtu的菜。
ubuntu:~$ curl -XGET localhost:9200/food/canteen/_search?pretty -d '{"query":{"match":{"source":"sjtu"}}}'
{
"took" : 35,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"failed" : 0
},
"hits" : {
"total" : 1,
"max_score" : 0.30685282,
"hits" : [ {
"_index" : "food",
"_type" : "canteen",
"_id" : "AU8HEQxfW68mQc8rk4AS",
"_score" : 0.30685282,
"_source":{title: "蘋果燉牛肉", source: "sjtu"}
} ]
}
}
這里用到了match query來搜索，可以看到_score的變化。
❸ QoS之擁塞管理與擁塞避免（3）
一、擁塞管理
硬體轉發隊列是長度有限的FIFO隊列，任何報文離開必須經過出介面硬體隊列，如果出介面的硬體轉發隊列存儲空間滿了，擁塞就產生了；
即使調整硬體轉發隊列長度，越長的硬體轉發隊列會使時延敏感的數據包在隊列中等待更長時間，引入過多的等待延時；
通過配置軟體隊列，實現將不同敏感程度的報文放到不同的隊列中，並使用不同的調度機制來保證敏感報文的網路質量，解決多種業務爭用有限的硬體隊列資源的情況；
兩種隊列機制：
（1）基於隊列的擁塞管理機制queue-profile
華為設備可以使用Queue-profile來全局定義可應用到介面的軟體隊列，當硬體隊列擁塞時，Queue-profile隊列系統開始起作用；
系統最多可定義優先順序為0-7的8個隊列，每個介面出方向都擁有4個或8個隊列，以隊列索引號標識，分別為0、1、2、3或0、1、2...、7；
設備根據本地優先順序和隊列之間的映射關系，自動將報文送入各隊列，然後按照各種隊列調度機制進行調度。
LAN介面上可用的調度機制有PQ、DRR、PQ+DRR、WRR、PQ+WRR；WAN介面上可用的調度機制有PQ、WFQ和PQ+WFQ；
如果queue-profile中定義了多個PQ隊列，則多個PQ間根據優先順序順序進行調度；
如果在queue-profile中定義了多個WFQ／WRR／DRR的隊列，PQ隊列調度完成後，再對DRR、WFQ或WRR隊列進行調度，共同分享剩餘帶寬；
因為PQ隊列優先調度，如果PQ隊列持續有數據包，可能會出現隊列餓死的問題，建議對進入PQ隊列的報文進行限速，不要過多佔用帶寬；
（2）基於MQC的CBQ隊列技術
可以定義BE、AF、EF和LLQ隊列；
1、軟體隊列技術之qos queue-profile
queue profile最多可以定義8個隊列，隊列之間可以定義多種調度方式，以下是各種調度方式及其區別；
PQ調度
維護一個優先順序遞減的隊列系列，只有當更高優先順序的所有隊列為空時才服務低優先順序的隊列；
優點是能保證時延敏感報文的服務質量；
缺點是如果擁塞時較高優先順序隊列長時間有分組存在，低優先順序隊列就會由於得不到服務餓死；
WRR調度
RR調度會依次在不同隊列間提供等量服務，調度在隊列間輪流可以保證每個隊列都得到同等服務機會；
WRR根據每個隊列的重要程度分配權值，在不同隊列間按權值比例提供服務，調度一次權值減1，減為0不參與調度，所有隊列權值都減為0後重新開始下一輪調度；
由於WRR調度是以報文為單位的，同等調度機會下大尺寸報文獲得的帶寬大於小尺寸報文獲得的帶寬，每個隊列沒有固定的帶寬；
優點是隊列不會因長時間得不到服務餓死；
缺點是無法保證延遲敏感報文的服務質量；
DRR調度
DRR解決了WRR每個隊列沒有固定帶寬的問題；
DRR每次調度都會為每個隊列分配一次按權值比例得到的Deficit，只有隊列的Deficit大於0才可以發送報文，所以DRR的每個隊列可以按照權值比例獲得固定帶寬；
優點是隊列不會因長時間得不到服務餓死；
缺點是無法保證延遲敏感報文的服務質量；
WFQ調度
FQ把進入一個隊列的報文稱為流，系統對待每個流都是均等的，每個流都會平等地分享到當前可用的帶寬，例如介面帶寬1M，當前有n條流，每條流獲得帶寬是1/n M；
FQ還關心流隊列中報文的長度，如果在不同隊列間同時存在多個長報文和短報文等待發送，則短報文優先得到調度，這樣可以減緩各個流報文間的抖動；
WFQ在FQ的基礎上，增加權重使不同流權重值比例分配帶寬；
優點是每個隊列之間按權重值比例分配帶寬更公平；
缺點是無法保證延遲敏感報文的服務質量；
PQ+WRR／PQ+DRR／PQ+WFQ調度
PQ調度和WRR／DRR／WFQ調度都有各自優缺點，單純使用PQ調度，低優先順序隊列可能長時間得不到調度；而單純採用WRR／DRR／WFQ調度，低延時需求業務得不到優先調度；
通過將兩種調度方式結合起來，PQ+WRR、PQ+DRR、PQ+WFQ調度方式使低延時需求業務進入PQ隊列進行調度；而其他報文進入WRR／DRR／WFQ的隊列中進行調度；
隊列調度時，先調度PQ隊列，多個PQ隊列按優先順序順序進行調度；
PQ隊列調度完成後，再對WRR／DRR／WFQ隊列進行加權輪詢調度；
例如指定隊列4和5進行PQ調度，其他隊列0、1、2、3進行WRR調度；
根據不同業務需要給WRR各隊列設置不同的權值（預設權值為10），根據權值對各隊列進行調度，DRR和WFQ可以按權值比例為隊列分配固定帶寬；
PQ不需要權值，PQ總優先使用介面帶寬；
2、基於MQC的CBQ隊列技術
基於類的加權公平隊列CBQ，基於WFQ功能進行擴展，使用戶可以自己定義用戶類；
CBQ根據IP優先順序或者DSCP優先順序、IP報文的五元組、入介面規則來對進入系統的報文進行分類，每個分類可以使用EF、LLQ、AF和BE類型的隊列，對於不匹配任何分類的報文，送入系統的默認BE類型的預設類；
1、EF隊列和LLQ隊列 限制隊列可使用的最大帶寬
滿足低時延業務；
華為提供的兩種類型的低延遲隊列EF和LLQ，LLQ隊列比EF隊列時延更低；
CBQ隊列最多隻允許為4個用戶類定義EF或LLQ隊列，最多可包含的LLQ和EF隊列之和為4；
每個EF和LLQ隊列按照配置順序進行絕對優先順序調度，先配置的隊列先被調度；
2、AF隊列 保證隊列可使用的最小帶寬
滿足需要帶寬保證的關鍵數據業務；
每個AF隊列分別對應一類用戶報文，用戶可以設定每類報文佔用的帶寬，在系統調度報文出隊的時候，按用戶為 各類報文設定的帶寬將報文出隊發送，可以實現各個類的隊列公平調度；
當介面有剩餘帶寬時，AF隊列按照權值分享剩餘帶寬；
對於AF隊列，當隊列長度達到隊列的最大長度時，預設採用尾丟棄的策略，但用戶還可以選擇用WRED丟棄策略；
3、BE隊列
滿足不需要嚴格Qos保證的盡力發送業務；
如果進入系統的報文沒有匹配用戶定義的所有類別，報文被送入系統定義的預設類；
允許為預設類配置AF隊列並配置帶寬，但是更多的情況是為預設類配置BE隊列；
BE隊列使用WFQ調度，進入BE隊列的流越多，每個流分享的帶寬越平均；
CBQ中，WFQ在調度報文入隊列之前，根據IP報文五元組和ToS優先順序自動進行流分類，並盡可能多的提供隊列，將每個流均勻地放入不同隊列中，從而在總體上均衡各個流的延遲；
在出隊的時候，WFQ按流的優先順序來分配流應佔用的帶寬，優先順序數值越大所得的帶寬就越多；
二、擁塞避免
擁塞避免是在隊列尾部提供的一種基於權值的RED機制，默認是直接在隊列尾部丟棄報文；
1、尾丟棄
當擁塞發生，隊列長度達到最大值後，所有新入隊列的報文都將因沒有緩存空間而被丟棄；
缺點是不加區分地丟包和引發TCP全局同步現象；
TCP全局同步現象就是在隊列中同時丟棄多個TCP連接的報文，造成多個TCP連接同時降低流量，之後又會在某個時間同時出現流量高峰，使網路流量起伏波動；
2、WRED
為解決TCP全局同步問題，RED提早隨機丟棄一些低級別報文，不同時丟包行為可以避免多個TCP連接同時降低發送速度出現TCP全局同步現象，並使TCP流量趨於平緩穩定；
報文依次進入隊列，當隊列深度到達最小閥值時開始丟包；
隨著隊列深度增加丟包率按線性比例增加，最高丟包率不超過設置的丟包率；
直至到達最高閥值後報文全部丟棄；
基於RED，WRED隊列支持基於DSCP或IP優先順序進行RED丟棄；
WRED中權值是IPP或DSCP，每個隊列可以針對每一種優先順序獨立設置丟棄報文的上下門限及丟包率，即每個權值都定義一個獨立的丟棄曲線；
WRED有兩種配置方式，一種是基於隊列queue-profile的WRED，另一種是CBQ下的WRED；
定義每個權值的丟棄曲線是通過定義丟棄模版來實現的，丟棄模板是隊列各優先順序WRED參數的集合；
（1）配置基於隊列queue-profile的WRED
將定義好的丟棄模版在隊列模版中關聯後應用到介面上，介面根據綁定的丟棄模版實現擁塞避免；
（2）配置CBQ下的WRED
丟棄模板在流行為中綁定後，在流策略下將流分類和對應的流行為關聯，並將流策略應用到介面上，可以實現對匹配流分類規則流量的擁塞避免；
❹ 什麼是saas模式
SaaS是Software-as-a-service（軟體即服務）。SaaS提供商為企業搭建信息化所需要的所有網路基礎設施及軟體、硬體運作平台，並負責所有前期的實施、後期的維護等一系列服務，企業無需購買軟硬體、建設機房、招聘IT人員，即可通過互聯網使用信息系統。
就像打開自來水龍頭就能用水一樣，企業根據實際需要，向SaaS提供商租賃軟體服務。
(4)mqc存儲擴展閱讀：
SaaS特性
最早的SaaS服務之一當屬在線電子郵箱，極大地降低了個人與企業使用電子郵件的門檻，進而改變了人與人、企業與企業之間的溝通方式。
發展至今，SaaS服務的種類與產品已經非常豐富，面向個人用戶的服務包括：在線文檔編輯、表格製作、日程表管理、聯系人管理等等;
面向企業用戶的服務包括：在線存儲管理、網上會議、項目管理、CRM(客戶關系管理)、ERP(企業資源管理)、HRM(人力資源管理)、在線廣告管理以及針對特定行業和領域的應用服務等等。
與傳統軟體相比，SaaS服務依託於軟體和互聯網，不論從技術角度還是商務角度都擁有與傳統軟體不同的特性，表現在：
互聯網
一方面，SaaS服務通過互聯網瀏覽器或WebServices/Web2.0程序連接的形式為用戶提供服務，使得SaaS應用具備了典型互聯網技術特點;另一方面，由於SaaS極大的縮短了用戶與SaaS提供商之間的時空距離，從而使得SaaS服務的營銷、交付與傳統軟體相比有著很大的不同。
多租戶
SaaS服務通常基於一套標准軟體系統為成百上千的不同客戶(又稱租戶)提供服務。這要求SaaS服務要能夠支持不同租戶之間數據和配置的隔離，從而保證每個租戶數據的安全與隱私，以及用戶對諸如界面、業務邏輯、數據結構等的個性化需求。
由於SaaS同時支持多個租戶，每個租戶又有很多用戶，這對支撐軟體的基礎設施平台的性能、穩定性、擴展性提出很大挑戰。
服務特性
SaaS使得軟體以互聯網為載體的服務形式被客戶使用，所以服務合約的簽定、服務使用的計量、在線服務質量的保證、服務費用的收取等等問題都必須考慮。而這些問題通常是傳統軟體沒有考慮到的。
SaaS(Software asaService，軟體即服務)是通過互聯網以服務形式交付和使用軟體的業務模式。在SaaS模式下，軟體使用者無需購置額外硬體設備、軟體許可證及安裝和維護軟體系統，通過互聯網瀏覽器在任何時間、任何地點都可以輕松使用軟體並按照使用量定期支付使用費。
參考資料：網路-saas模式