① Web測試的主要內容和測試方法有哪些
測試分類:
1、界面測試
1)給用戶的整體感:舒適感;憑感覺能找到想要找的信息;設計風格是否一致
2)各控制項的功能
2、功能測試
1)刪除/增加某一項:是否對其他項造成影響,這些影響是否都正確
2)列表默認值檢查
3)檢查按鈕功能是否正確:新建、編輯、刪除、關閉、返回、保存、導入、上一頁、下一頁、頁面跳轉、重置(常見錯誤)
4)字元串長度檢查:超出長度
5)字元類型檢查
6)標點符號檢查:空格、各種引號、Enter鍵
7)特殊字元:常見%、「、」
8)中文字元:是否亂碼
9)檢查信息完整:查看信息,查看所填信息是否完整更新;更新信息,更新信息與添加信息是否一致
10)信息重復:需唯一信息處,比如重復的名字或ID、重名是否區分大小寫、加空格
11)檢查刪除功能:不選擇任何信息,按Delete,看如何處理;選擇一個或多個進行刪除;多頁選、翻頁選刪除;刪除是否有提示
12)檢查添加和修改是否一致:添加必填項,修改也該必填;添加為什麼類型,修改也該什麼類型
13)檢查修改重名:修改時把不能重名的項改為已存在的內容
14)重復提交表單:一條已經成功提交的記錄,返回後再提交
15)檢查多次使用返回鍵:返回到原來頁面,重復多次
16)搜索檢查:存在或不存在內容,看搜索結果是否正確;多個搜索條件,同時輸入合理和不合理條件;特殊字元
17)輸入信息的位置
18)上傳下載文件檢查:功能是否實現,
上傳:上傳文件是否能打開、格式要求、系統是否有解釋信息、將不能上傳的文件格式修改後綴為可上傳的文件格式;
下載:下載是否能打開、保存、格式要求
19)必填項檢查:必填項未填寫;是否有提示,如加*;對必填項提示返回後,焦點是否自動定位到必填項
20)快捷鍵檢查:是否支持快捷鍵Ctrl+C、Ctrl+V、backspace;對不允許做輸入的欄位(如:下拉選項),對快捷方式是否也做了限制
21)Enter鍵檢查:輸入結束後按Enter鍵,系統如何處理
22)刷新鍵檢查:按瀏覽器刷新鍵如何處理
23)回退鍵檢查:按瀏覽器回退鍵如何處理
24)空格檢查:輸入項輸入一個或多個空格
25)輸入法半形全形檢查:比如,浮點型,輸入全形小數點「。」或「. 」,如4. 5;全形空格
26)密碼檢查:輸入加密方式的極限字元;密碼盡可能長
27)用戶檢查:不同種類管理員用戶的不同許可權,是否可以互相刪除、管理、編輯;一般用戶的許可權;注銷功能,老用戶注銷再注冊,是否為新用戶
28)系統數據檢查:數據隨業務過程、狀態的變化保持正確,不能因為某個過程出現垃圾數據,也不能因為某個過程而丟失數據。
29)系統可恢復性檢查:以各種方式把系統搞癱,測試系統是否可以迅速恢復
30)確認提示檢查:系統更新、刪除操作:是否有提示、取消操作;提示是否准確;事前、事後提示
31)數據注入檢查:對資料庫注入,特殊字元,對sql語句進行破壞
32)時間日期檢查:時間、日期、時間驗證:日期范圍是否符合實際業務;對於不符合實際業務的日期是否有限制
33)多瀏覽器驗證
3、性能測試
1)壓力測試:實際破壞一個Web應用系統,測試系統的反應,測試系統的限制和故障恢復能力
2)負載測試:在某一負載級別上的性能,包括某個時刻同時訪問Web的用戶數量、在線數據處理的數量
3)強度測試:測試對象在性能行為異常或極端條件下(如資源減少或用戶過多)的可接受性,以此驗證系統軟硬體水平
4)資料庫容量測試:通過存儲過程往資料庫表中插入一定數量的數據,看是否能及時顯示
5)預期指標的性能測試:在需求分析和設計階段會提出一些性能指標,對於預先確定的性能要求要首先進行測試
6)獨立業務性能測試:對核心業務模塊做用戶並發測試,包括同一時刻進行完全一樣的操作、同一時刻使用完全一樣的功能
7)組合業務性能測試:模擬多用戶的不同操作,最接近實際用戶使用情況,按用戶實際的實際使用人數比例來模擬各個模塊的組合並發情況
8)疲勞強度性能測試:系統穩定運行情況下,以一定負載壓力來長時間運行系統的測試
9)網路性能測試:准確展示帶寬、延遲、負載、埠的變化是如何影響用戶的相應時間的
10)大數據量性能測試:實時大數據量,模擬用戶工作時的實時大數據量;極限狀態下的測試,系統使用一段時間,積累一段數據量時能否正常運行,以及對前面兩種進行結合
11)伺服器性能測試:在進行用戶並發性能測試、疲勞強度、大數據量性能測試時,完成對伺服器性能的監控,並進行評估
12)一些特殊的測試:配置測試、內存泄漏的一些特殊測試
4、可用性測試(介面測試)
1)整體界面測試
2)多媒體測試
3)導航測試
5、客戶端兼容性
平台測試:windows;unix;macintosh;linux
瀏覽器測試:不同廠商的瀏覽器對Java、Javascript、ActiveX、plug-ins或不同的HTML的規格
不同的支持;框架和層次結構在不同瀏覽器也不同的顯示
6、安全性
安全性測試要求:
1)能夠對密碼試探工具進行防範
2)能夠防範對Cookie攻擊的常用手段
3)敏感數據保證不用明文傳輸
4)能防範通過文件名猜測和查看html文件內容獲取重要信息
5)能保證在網站收到工具後在給定時間內恢復,重要數據丟失不超過1小時
web的性能測試工具:
隨著Web2.0技術的迅速發展,許多公司都開發了一些基於Web的網站服務,通常在設計開發Web應用系統的時候很難模擬出大量用戶同時訪問系統的實際情況。
因此,當Web網站遇到訪問高峰時,容易發生伺服器響應速度變慢甚至服務中斷。
為了避免這種情況,需要一種能夠真實模擬大量用戶訪問Web應用系統的性能測試工具進行壓力測試,來測試靜態HTML頁面的響應時間,甚至測試動態網頁(包括ASP、PHP、JSP等)的響應時間,為伺服器的性能優化和調整提供數據依據。
1、企業級自動化測試工具WinRunner
MercuryInteractive公司的WinRunner是一種企業級的功能測試工具,用於檢測應用程序是否能夠達到預期的功能及正常運行。
2、工業標准級負載測試工具Loadrunner
LoadRunner是一種預測系統行為和性能的負載測試工具
3、全球測試管理系統testdirector
TestDirector是業界第一個基於Web的測試管理系統,它可以在您公司內部或外部進行全球范圍內測試的管理。
4、功能測試工具RationalRobot
IBMRationalRobot是業界最頂尖的功能測試工具,它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。
它集成在測試人員的桌面IBMRationalTestManager上,在這里測試人員可以計劃、組織、執行、管理和報告所有測試活動,包括手動測試報告。
這種測試和管理的雙重功能是自動化測試的理想開始。
5、單元測試工具xUnit系列
目前的最流行的單元測試工具是xUnit系列框架,常用的根據語言不同分為JUnit(java),CppUnit(C++),DUnit(Delphi),NUnit(.net),PhpUnit(Php)等等。
該測試框架的第一個和最傑出的應用就是由ErichGamma(《設計模式》的作者)和KentBeck(XP(ExtremeProgramming)的創始人)提供的開放源代碼的JUnit.
6、功能測試工具SilkTest
BorlandSilkTest2006屬於軟體功能測試工具,是Borland公司所提出軟體質量管理解決方案的套件之一。
這個工具採用精靈設定與自動化執行測試,無論是程序設計新手或資深的專家都能快速建立功能測試,並分析功能錯誤。
7、性能測試工具WAS
是由微軟的網站測試人員所開發,專門用來進行實際網站壓力測試的一套工具。
透過這套功能強大的壓力測試工具,您可以使用少量的Client端計算機模擬大量用戶上線對網站服務所可能造成的影響。
8、自動化白盒測試工具Jtest
Jtest是parasoft公司推出的一款針對java語言的自動化白盒測試工具,它通過自動實現java的單元測試和代碼標准校驗,來提高代碼的可靠性。
parasoft同時出品的還有C++test,是一款C/C++白盒測試工具。
9、功能和性能測試的工具JMeter
JMeter是Apache組織的開放源代碼項目,它是功能和性能測試的工具,100%的用java實現。
10、性能測試和分析工具WEBLOAD
webload是RadView公司推出的一個性能測試和分析工具,它讓web應用程序開發者自動執行壓力測試;webload通過模擬真實用戶的操作,生成壓力負載來測試web的性能。
(1)web服務性能監控擴展閱讀:
漏洞測試
企業網站做的越來越復雜、功能越來越強。不過這些都不是憑空而來的,是通過代碼堆積起來的。如果這個代碼只供企業內部使用,那麼不會帶來多大的安全隱患。
但是如果放在互聯網上使用的話,則這些為實現特定功能的代碼就有可能成為攻擊者的目標。
天眼舉一個簡單的例子。在網頁中可以嵌入SQL代碼。而攻擊者就可以利用這些SQL代碼來發動攻擊,來獲取管理員的密碼等等破壞性的動作。
有時候訪問某些網站還需要有某些特定的控制項。用戶在安裝這些控制項時,其實就有可能在安裝一個木馬(這可能訪問者與被訪問者都沒有意識到)。
為此在為網站某個特定功能編寫代碼時,就要主動出擊。從編碼的設計到編寫、到測試,都需要認識到是否存在著安全的漏洞。
天眼在日常過程中,在這方面對於員工提出了很高的要求。各個員工必須對自己所開發的功能負責。
已知的病毒、木馬不能夠在所開發的插件中有機可乘。通過這層層把關,就可以提高代碼編寫的安全性。
② 如何監控web伺服器主要性能指標
可以使用軟體開監控,拓建試試監控寶。會詳細記錄伺服器的數據指標
③ 如何保證Web伺服器安全
不但企業的門戶網站被篡改、資料被竊取,而且還成為了病毒與木馬的傳播者。有些Web管理員採取了一些措施,雖然可以保證門戶網站的主頁不被篡改,但是卻很難避免自己的網站被當作肉雞,來傳播病毒、惡意插件、木馬等等。筆者認為,這很大一部分原因是管理員在Web安全防護上太被動。他們只是被動的防禦。為了徹底提高Web伺服器的安全,筆者認為,Web安全要主動出擊。具體的來說,需要做到如下幾點。一、在代碼編寫時就要進行漏洞測試 現在的企業網站做的越來越復雜、功能越來越強。不過這些都不是憑空而來的,是通過代碼堆積起來的。如果這個代碼只供企業內部使用,那麼不會帶來多大的安全隱患。但是如果放在互聯網上使用的話,則這些為實現特定功能的代碼就有可能成為攻擊者的目標。筆者舉一個簡單的例子。在網頁中可以嵌入SQL代碼。而攻擊者就可以利用這些SQL代碼來發動攻擊,來獲取管理員的密碼等等破壞性的動作。有時候訪問某些網站還需要有某些特定的控制項。用戶在安裝這些控制項時,其實就有可能在安裝一個木馬(這可能訪問者與被訪問者都沒有意識到)。 為此在為網站某個特定功能編寫代碼時,就要主動出擊。從編碼的設計到編寫、到測試,都需要認識到是否存在著安全的漏洞。筆者在日常過程中,在這方面對於員工提出了很高的要求。各個員工必須對自己所開發的功能負責。至少現在已知的病毒、木馬不能夠在你所開發的插件中有機可乘。通過這層層把關,就可以提高代碼編寫的安全性。二、對Web伺服器進行持續的監控 冰凍三尺、非一日之寒。這就好像人生病一樣,都有一個過程。病毒、木馬等等在攻擊Web伺服器時,也需要一個過程。或者說,在攻擊取得成功之前,他們會有一些試探性的動作。如對於一個採取了一定安全措施的Web伺服器,從攻擊開始到取得成果,至少要有半天的時間。如果Web管理員對伺服器進行了全天候的監控。在發現有異常行為時,及早的採取措施,將病毒與木馬阻擋在門戶之外。這種主動出擊的方式,就可以大大的提高Web伺服器的安全性。 筆者現在維護的Web伺服器有好幾十個。現在專門有一個小組,來全天候的監控伺服器的訪問。平均每分鍾都可以監測到一些試探性的攻擊行為。其中99%以上的攻擊行為,由於伺服器已經採取了對應的安全措施,都無功而返。不過每天仍然會遇到一些攻擊行為。這些攻擊行為可能是針對新的漏洞,或者採取了新的攻擊方式。在伺服器上原先沒有採取對應的安全措施。如果沒有及時的發現這種行為,那麼他們就很有可能最終實現他們的非法目的。相反,現在及早的發現了他們的攻擊手段,那麼我們就可以在他們採取進一步行動之前,就在伺服器上關掉這扇門,補上這個漏洞。 筆者在這里也建議,企業用戶在選擇互聯網Web伺服器提供商的時候,除了考慮性能等因素之外,還要評估服務提供商能否提供全天候的監控機制。在Web安全上主動出擊,及時發現攻擊者的攻擊行為。在他們採取進一步攻擊措施之前,就他們消除在萌芽狀態。 三、設置蜜罐,將攻擊者引向錯誤的方向 在軍隊中,有時候會給軍人一些偽裝,讓敵人分不清真偽。其實在跟病毒、木馬打交道時,本身就是一場無硝煙的戰爭。為此對於Web伺服器採取一些偽裝,也能夠將攻擊者引向錯誤的方向。等到供給者發現自己的目標錯誤時,管理員已經鎖定了攻擊者,從而可以及早的採取相應的措施。筆者有時候將這種主動出擊的行為叫做蜜罐效應。簡單的說,就是設置兩個伺服器。其中一個是真正的伺服器,另外一個是蜜罐。現在需要做的是,如何將真正的伺服器偽裝起來,而將蜜罐推向公眾。讓攻擊者認為蜜罐伺服器才是真正的伺服器。要做到這一點的話,可能需要從如下幾個方面出發。 一是有真有假,難以區分。如果要瞞過攻擊者的眼睛,那麼蜜罐伺服器就不能夠做的太假。筆者在做蜜罐伺服器的時候,80%以上的內容都是跟真的伺服器相同的。只有一些比較機密的信息沒有防治在蜜罐伺服器上。而且蜜罐伺服器所採取的安全措施跟真的伺服器事完全相同的。這不但可以提高蜜罐伺服器的真實性,而且也可以用來評估真實伺服器的安全性。一舉兩得。 二是需要有意無意的將攻擊者引向蜜罐伺服器。攻擊者在判斷一個Web伺服器是否值得攻擊時,會進行評估。如評估這個網站的流量是否比較高。如果網站的流量不高,那麼即使被攻破了,也沒有多大的實用價值。攻擊者如果沒有有利可圖的話,不會花這么大的精力在這個網站伺服器上面。如果要將攻擊者引向這個蜜罐伺服器的話,那麼就需要提高這個蜜罐伺服器的訪問量。其實要做到這一點也非常的容易。現在有很多用來交互流量的團隊。只要花一點比較小的投資就可以做到這一點。 三是可以故意開一些後門讓攻擊者來鑽。作為Web伺服器的管理者,不僅關心自己的伺服器是否安全,還要知道自己的伺服器有沒有被人家盯上。或者說,有沒有被攻擊的價值。此時管理者就需要知道,自己的伺服器一天被攻擊了多少次。如果攻擊的頻率比較高,管理者就高興、又憂慮。高興的是自己的伺服器價值還蠻大的,被這么多人惦記著。憂慮的是自己的伺服器成為了眾人攻擊的目標。就應該抽取更多的力量來關注伺服器的安全。四、專人對Web伺服器的安全性進行測試 俗話說,靠人不如靠自己。在Web伺服器的攻防戰上,這一個原則也適用。筆者建議,如果企業對於Web服務的安全比較高,如網站伺服器上有電子商務交易平台,此時最好設置一個專業的團隊。他們充當攻擊者的角色,對伺服器進行安全性的測試。這個專業團隊主要執行如下幾個任務。 一是測試Web管理團隊對攻擊行為的反應速度。如可以採用一些現在比較流行的攻擊手段,對自己的Web伺服器發動攻擊。當然這個時間是隨機的。預先Web管理團隊並不知道。現在要評估的是,Web管理團隊在多少時間之內能夠發現這種攻擊的行為。這也是考驗管理團隊全天候跟蹤的能力。一般來說,這個時間越短越好。應該將這個時間控制在可控的范圍之內。即使攻擊最後沒有成功,Web管理團隊也應該及早的發現攻擊的行為。畢竟有沒有發現、與最終有沒有取得成功,是兩個不同的概念。 二是要測試伺服器的漏洞是否有補上。畢竟大部分的攻擊行為,都是針對伺服器現有的漏洞所產生的。現在這個專業團隊要做的就是,這些已發現的漏洞是否都已經打上了安全補丁或者採取了對應的安全措施。有時候我們都沒有發現的漏洞是無能為力,但是對於這些已經存在的漏洞不能夠放過。否則的話,也太便宜那些攻擊者了。
④ 如何通過WebView監控提升WebAPP性能
相對於需要專業移動開發人員的原生應用(Native APP),基於HTML5/CSS/JavaScript的WebAPP憑借開發者門檻低、迭代迅速、支持跨平台發布等特點,成為電商、銀行等網路服務、瀏覽類應用的首選,然而由於頁面渲染導致的性能差距是WebAPP與原生應用無法抗衡的最大原因,因此針對WebView組件的性能優化就顯得至關重要。
為什麼是WebView
WebAPP所顯示的Web頁面都是由一個叫做WebView的組件渲染出來的,每個網頁都有一個鏈接即URL,首先將URL轉換成NSURLRequest,然後用載入網頁的類WebView載入Request,使用 - (void)loadRequest:(NSURLRequest *)request這個方法,就能將網頁載入顯示出來。
目前iOS中有兩個載入網頁的類,分別是UIWebView和WKWebView,UIWebView是UIKit框架中的一個類,而WKWebView是WebKit框架中的類,從性能上來說WKWebView的性能高、穩定性好、佔用內存小,完全優於UIWebView。但由於WKWebView是iOS8提供的組件,因此系統版本低於iOS 8.0的iPhone/iPad用戶就無法正常使用WKWebView組件開發出來的APP。所以目前大部分開發人員還在使用性能、穩定性並不理想的UIWebView進行WebAPP開發,而本文所說的雲智慧透視寶WebView性能監控也是以UIWebView為主要優化目標。
要進行性能監控必須獲得WebAPP頁面載入全過程的性能數據,透視寶是通過向當前載入鏈接的html5、jsp、php網頁代碼中注入獲取數據的JS代碼,然後通過OC與JS交互,將數據傳遞給OC,然後再將數據整理發送到透視寶後端。
監控哪些WebView性能數據
透視寶能監控四大類數據:
行為數據:抓取用戶在移動端網頁點的行為操作,也就是點擊網頁的內容,分析用戶的行為
時間相應數據:分解一個鏈接從載入開始到完成這段時間內,每個階段的耗時
Ajax請求數據:抓取終端用戶響應時間,響應數據下載時間,數據響應成功的callback執行時間和ajax錯誤數據
JS錯誤數據:抓取載入鏈接的代碼錯誤信息
① 時間響應數據及數據計算公式
(圖片來源:51cto技術博客)
參見上圖,JS傳給透視寶的時間響應數據就是這些欄位,其中navigationStart是起點,所有的計算都需要依賴於它。分析移動端H5性能數據,其實就是測算HTML5、JSP、PHP等網頁元素在iOS上載入的時間長短,通過這些性能數據前段開發人員能夠准確發現性能問題並及時解決,下表是透視寶定義的響應時間分解數據及計算方案:
② 資源時序數據
每一個網頁都是有很多資源組成的,包括.js、.png、.jpg、.css、script等,每一個元素的載入都需要載入時間,資源時序數據就是准確記錄每一個元素的載入時間及類型,並把這些數據通過JS的performance介面直接獲得並傳給OC,不需要計算。
③ JS錯誤及ajax請求數據
JS錯誤指的是抓取網頁代碼的錯誤,包括錯誤類型及堆棧信息,直接定位錯誤。ajax請求的數據有請求的鏈接、uri、 終端用戶響應時間,響應數據下載時間,數據響應成功的callback執行時間和ajax錯誤數據。JS錯誤和ajax請求數據都是有JS代碼直接獲取到,不需要處理。
JS代碼注入
想要准確監測網頁性能就需要進行代碼注入,而只有拿到網頁的代碼才能注入, UIWebView這個類裡面除了三個載入鏈接的方法和4個代理方法,就沒有其他內容了,而這些方法並不能獲取到內容,所以我們就需要考慮其他方法。UIWebView在載入攔截的時候會進入NSURLProtocol這個類,而恰好這個類能拿到當前載入鏈接NSURLRequest,而且會走進這個類的 - (void)startLoading方法,這個方法在頁面load完成之前,頁面剛載入之後,所以就是我們所需要的。
創建一個類,繼承NSURLProtocol這個類,重寫startLoading方法,由於能拿到鏈接的request,所以我們就對這個鏈接發送請求,用原生態的NSURLConnection或者NSURLSession都可以,我們用的NSURLConnection這個類發送請求並設置代理,方法是這個 - (nullableinstancetype)initWithRequest:(NSURLRequest*)request delegate:(nullableid)delegate startImmediately:(BOOL)startImmediately,
NSURLConnection的代理方法中有一個能接受請求鏈接數據的方法, - (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data,得到的NSData是16進制的位元組流數據,通過utf8轉碼將位元組流轉換成字元串,然後發現這個字元串正好是這個當前載入網頁的代碼,
網頁代碼都是由標簽組成,都會有<head>這個標簽,我們就把JS代碼注入到<head>標簽之下,放在自己添加的<script>標簽中;代碼實現就是獲取字元串中<head>這個字元的位置,然後在其下面插入用<script>包裝的js代碼,然後轉回成新的NSData的位元組流數據。
由於頁面還沒有載入,我們已經改動代碼了,就需要把注入JS代碼的重新記載一次,需要用NSURLProtocol的代理屬性NSURLProtocolClient,用NSURLProtocolClient這個中的這個方法- (void)URLProtocol:(NSURLProtocol*)protocol didLoadData:(NSData*)data,將新的NSData載入一次,轉回成NSData是因為這個方法需要的是NSData數據。
當然上面只是介紹主要實現的一些方法,還需要用到NSURLConnection的其他代理方法,只是這些方法不需要添加什麼,按照常規處理就行了,就不一一介紹了。
性能數據獲取
載入鏈接過程中JS代碼就會通過performance介面獲取數據,然後獲取的這些數據需要傳給移動端,如何傳遞數據呢,傳遞數據的過程也叫OC與JS交互的過程。
獲取數據的時機:
由於不清楚什麼時候JS能拿到數據,所以從最開始就需要進行交互的監控,也就是載入鏈接的時候,因為透視寶SDK用來監控的所以我們不能直接使用這個方法,需要用到OC的運行時,動態載入機制,又叫hook。首先通過添加UIWebView的類目,添加類目是將UIWebView類的實現分散出來,每個類都是由NSbject繼承下去,所以每個類都有 (void)load方法,而且這個方法的執行是最早的,我們就在這個方法中使用OC的運行時runtime,使用一個方法交換UIWebView載入鏈接的三個方法的指針,這樣就會在執行載入方法之前執行我們交換出來的方法,在這個方法裡面我們傳遞一個與JS匹配的標識,通過標識相同來獲取數據,這樣做的目的就是能從最開始就監控數據的傳遞。
⑤ web伺服器訪問緩慢,作為運維人員,如何定位故障
遇到伺服器故障,問題出現的原因很少可以一下就想到。我們基本上都會從以下步驟入手:
一、盡可能搞清楚問題的前因後果
不要一下子就扎到伺服器前面,你需要先搞明白對這台伺服器有多少已知的情況,還有故障的具體情況。不然你很可能就是在無的放矢。
必須搞清楚的問題有:
故障的表現是什麼?無響應?報錯?
故障是什麼時候發現的?
故障是否可重現?
有沒有出現的規律(比如每小時出現一次)
最後一次對整個平台進行更新的內容是什麼(代碼、伺服器等)?
故障影響的特定用戶群是什麼樣的(已登錄的, 退出的, 某個地域的…)?
基礎架構(物理的、邏輯的)的文檔是否能找到?
是否有監控平台可用? (比如Munin、Zabbix、 Nagios、 New Relic…
什麼都可以)
是否有日誌可以查看?. (比如Loggly、Airbrake、 Graylog…)
最後兩個是最方便的信息來源,不過別抱太大希望,基本上它們都不會有。只能再繼續摸索了。
二、有誰在?
代碼如下:
$ w
$ last
用這兩個命令看看都有誰在線,有哪些用戶訪問過。這不是什麼關鍵步驟,不過最好別在其他用戶正幹活的時候來調試系統。有道是一山不容二虎嘛。(ne cook in
the kitchen is enough.)
三、之前發生了什麼?
$
history查看一下之前伺服器上執行過的命令。看一下總是沒錯的,加上前面看的誰登錄過的信息,應該有點用。另外作為admin要注意,不要利用自己的許可權去侵犯別人的隱私哦。
到這里先提醒一下,等會你可能會需要更新 HISTTIMEFORMAT
環境變數來顯示這些命令被執行的時間。對要不然光看到一堆不知道啥時候執行的命令,同樣會令人抓狂的。
四、現在在運行的進程是啥?
代碼如下:
$ pstree -a
$ ps aux
這都是查看現有進程的。 ps aux 的結果比較雜亂, pstree -a 的結果比較簡單明了,可以看到正在運行的進程及相關用戶。
五、監聽的網路服務
代碼如下:
$ netstat -ntlp
$ netstat -nulp
$
netstat -nxlp
我一般都分開運行這三個命令,不想一下子看到列出一大堆所有的服務。netstat -nalp倒也可以。不過我絕不會用 numeric 選項
(鄙人一點淺薄的看法:IP 地址看起來更方便)。
找到所有正在運行的服務,檢查它們是否應該運行。查看各個監聽埠。在netstat顯示的服務列表中的PID 和 ps aux 進程列表中的是一樣的。
如果伺服器上有好幾個Java或者Erlang什麼的進程在同時運行,能夠按PID分別找到每個進程就很重要了。
通常我們建議每台伺服器上運行的服務少一點,必要時可以增加伺服器。如果你看到一台伺服器上有三四十個監聽埠開著,那還是做個記錄,回頭有空的時候清理一下,重新組織一下伺服器。
六、CPU 和內存
代碼如下:
$ free -m
$ uptime
$ top
$
htop
注意以下問題:
還有空餘的內存嗎? 伺服器是否正在內存和硬碟之間進行swap?
還有剩餘的CPU嗎? 伺服器是幾核的? 是否有某些CPU核負載過多了?
伺服器最大的負載來自什麼地方? 平均負載是多少?
七、硬體
代碼如下:
$ lspci
$ dmidecode
$
ethtool
有很多伺服器還是裸機狀態,可以看一下:
找到RAID 卡 (是否帶BBU備用電池?)、 CPU、空餘的內存插槽。根據這些情況可以大致了解硬體問題的來源和性能改進的辦法。
網卡是否設置好?
是否正運行在半雙工狀態? 速度是10MBps? 有沒有 TX/RX 報錯?
八、IO 性能
代碼如下:
$ iostat -kx 2
$ vmstat 2 10
$ mpstat
2 10
$ dstat --top-io --top-bio
這些命令對於調試後端性能非常有用。
檢查磁碟使用量:伺服器硬碟是否已滿?
是否開啟了swap交換模式 (si/so)?
CPU被誰佔用:系統進程? 用戶進程? 虛擬機?
dstat 是我的最愛。用它可以看到誰在進行 IO: 是不是MySQL吃掉了所有的系統資源? 還是你的PHP進程?
九、掛載點 和 文件系統
代碼如下:
$ mount
$ cat /etc/fstab
$ vgs
$
pvs
$ lvs
$ df -h
$ lsof +D / /* beware not to kill your box
*/
一共掛載了多少文件系統?
有沒有某個服務專用的文件系統? (比如MySQL?)
文件系統的掛載選項是什麼: noatime?
default? 有沒有文件系統被重新掛載為只讀模式了?
磁碟空間是否還有剩餘?
是否有大文件被刪除但沒有清空?
如果磁碟空間有問題,你是否還有空間來擴展一個分區?
十、內核、中斷和網路
代碼如下:
$ sysctl -a | grep ...
$ cat
/proc/interrupts
$ cat /proc/net/ip_conntrack /* may take some time on busy
servers */
$ netstat
$ ss -s
你的中斷請求是否是均衡地分配給CPU處理,還是會有某個CPU的核因為大量的網路中斷請求或者RAID請求而過載了?
SWAP交換的設置是什麼?對於工作站來說swappinness 設為 60 就很好,
不過對於伺服器就太糟了:你最好永遠不要讓伺服器做SWAP交換,不然對磁碟的讀寫會鎖死SWAP進程。
conntrack_max 是否設的足夠大,能應付你伺服器的流量?
在不同狀態下(TIME_WAIT, …)TCP連接時間的設置是怎樣的?
如果要顯示所有存在的連接,netstat 會比較慢, 你可以先用 ss 看一下總體情況。
你還可以看一下 Linux TCP tuning
了解網路性能調優的一些要點。
十一、系統日誌和內核消息
代碼如下:
$ dmesg
$ less /var/log/messages
$
less /var/log/secure
$ less /var/log/auth
查看錯誤和警告消息,比如看看是不是很多關於連接數過多導致?
看看是否有硬體錯誤或文件系統錯誤?
分析是否能將這些錯誤事件和前面發現的疑點進行時間上的比對。
十二、定時任務
代碼如下:
$ ls /etc/cron* + cat
$ for user in
$(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done
是否有某個定時任務運行過於頻繁?
是否有些用戶提交了隱藏的定時任務?
在出現故障的時候,是否正好有某個備份任務在執行?
十三、應用系統日誌
這里邊可分析的東西就多了,
不過恐怕你作為運維人員是沒功夫去仔細研究它的。關注那些明顯的問題,比如在一個典型的LAMP(Linux+Apache+Mysql+Perl)應用環境里:
Apache & Nginx; 查找訪問和錯誤日誌, 直接找 5xx 錯誤, 再看看是否有 limit_zone 錯誤。
MySQL;
在mysql.log找錯誤消息,看看有沒有結構損壞的表, 是否有innodb修復進程在運行,是否有disk/index/query 問題.
PHP-FPM; 如果設定了 php-slow 日誌, 直接找錯誤信息 (php, mysql, memcache, …),如果沒設定,趕緊設定。
Varnish; 在varnishlog 和 varnishstat 里, 檢查 hit/miss比.
看看配置信息里是否遺漏了什麼規則,使最終用戶可以直接攻擊你的後端?
HA-Proxy;
後端的狀況如何?健康狀況檢查是否成功?是前端還是後端的隊列大小達到最大值了?
結論
經過這5分鍾之後,你應該對如下情況比較清楚了:
在伺服器上運行的都是些啥?
這個故障看起來是和 IO/硬體/網路 或者 系統配置 (有問題的代碼、系統內核調優, …)相關。
這個故障是否有你熟悉的一些特徵?比如對資料庫索引使用不當,或者太多的apache後台進程。
你甚至有可能找到真正的故障源頭。就算還沒有找到,搞清楚了上面這些情況之後,你現在也具備了深挖下去的條件。繼續努力吧!
⑥ 利用Windows自帶的性能監視器對WebService服務進行監控,通常使用哪些計數器,標准值是什麼
1. 處理器對象(Processor Object)
2. 系統對象(System Object)
3. SQL Server:緩沖區管理器對象( B u ffer Manager Object)
4. SQL Server:資料庫對象(Database Object)
5. SQL Server:常規統計對象(General Statistics Object)
6. SQL Server:閂對象(Latches Object)
7. SQL Server:鎖對象(Locks Object)
8. SQL Server:內存管理器對象(Memory Manager Object)
9. SQL Server:S Q L統計對象(SQL Statistics Object)
10. 邏輯磁碟對象(Logical Disk Object)
11. 物理磁碟對象(PhysicalDisk Object)
12. 內存
一條經驗規則是不要使你所監控的每個處理器的C P U使用率高於9 0%。峰值超過9 0%是可以接受的,但平均使用率超過9 0%則是應該避免的。
• 處理器時間百分比(%Processor Time) 處理器執行一個非空閑線程的時間百分比。用%1 0 0減去處理器空閑的總時間得出這個值。這是整個系統的C P U使用的一個好的指示器。
• 特權時間百分比(%Privileged Time) 處理器用於在特權模式下(即,執行操作系統功能和運行驅動器,如I / O )工作時間的百分比。這個時間包括C P U (或C P U )用於維護中斷和延遲過程調用( D P C )的時間。
• 用戶時間百分比(%User Time) 處理器用於在用戶模式工作的時間百分比。這種類型的工作是由應用產生的。通常,希望極大化用戶時間百分比的值,極小化特權時間百分比的值。
• 中斷時間百分比(%Interrupt Time) CPU忙於維護硬體中斷的時間百分比。系統中的許多硬體部件,如滑鼠、網路介面卡或磁碟控制器,都可以發出處理器中斷。你可以將中斷看作為Windows NT正常操作的一部分發生。
• 中斷數/秒(Interrupts/sec) 處理器每秒接收並處理的硬體中斷的數量。它不包括系統
D P C,系統D P C單獨計數。
系統對象與它的相關計數器衡量處理器上運行的線程的總計數據。雖然使用這些計數器不能觀察一個特定處理器的工作負載或一個特定線程的行為,但它們提供了有關整個系統性能有價值的內部信息。系統計數器如下所示:
• 處理器隊列長度(Processor Queue Length) 處理器隊列中的線程的數量。換句話說,它
是等待運行的線程數。即使你的系統具有多個處理器,但只有一個隊列用於處理器時間。計數器只記錄那些准備執行但仍處於等待的線程,不是那些正在運行的線程。
• 環境切換/秒(Context Switches/sec) 系統上的所有處理器從一個線程切換到另一個線程的組合比率。當一個正在運行的線程自動地放棄處理器,處理器由一個高優先順序的待命線程搶占時發生環境切換,或在用戶模式和特權(核心)模式之間切換,以使用一個執行或子系統的服務。這是線程的總和:計算機上運行在所有處理器上的所有線程的環境切換數/秒。
緩沖區管理器計數器提供了SQL Server使用的內存緩沖區的有關信息。這些計數器如下所示:
• 高速緩存命中率( B u ffer Cache Hit Ratio) 引用當前位於高速緩存中頁的需求的百分率。預先在內存中擁有頁,允許SQL Server避免請求從磁碟子系統執行一次物理I / O。因為訪問內存相對於訪問物理I / O,代價更小,一個高的緩沖區高速緩存命中率增強了系統的性能與吞吐量。如果你的系統很好地調整過,這個命中率應該是8 0%或更高。如果具有一個低的緩沖區高速緩存命中率,你應該為SQL Server分配更多的內存。如果你已將現有的所有內存都分配給了SQL Server,那麼需要增加系統中物理內存的數量。
• 高速緩存大小(頁)(Cache Size) 在SQL Server緩沖區高速緩存中的頁的數量。這個數量乘以8 K B,即可得到正在使用的以千位元組為單位的緩存數。
• 空閑緩沖區(Free Buffer) 空閑SQL Server內存緩沖區的數量。
• 讀的頁/秒(Page Reads/sec) 每秒請求的物理數據頁I / O的數量。
• 偷取的頁計數(Stolen Page Count) SQL Server用於緩沖區高速緩存的頁數,這些內存被給予系統中的另外一個進程。Windows NT回收這個內存以滿足其他系統部件的需要。
• 寫的頁/秒(Page Writes/sec) 由SQL Server執行的每秒寫的物理數據頁的數量。
資料庫對象計數器提供了有關SQL Server資料庫的信息,包括可用的空閑日誌空間量和資料庫中活動事務的數量。對於系統中的每個資料庫的每個計數器有一個實例。這些計數器包括如下:
• 日誌刷新等待/秒(Log Flush Wait/sec) 在能夠繼續執行前,必須等待日誌刷新的資料庫提交數量。
• 日誌使用的百分比(Percent Log Used) SQL Server實際使用的當前定義的日誌空間的百分比。
常規統計對象含有常規伺服器范圍活動的有關信息,它有一個計數器:
• 用戶連接數(User Connections) 系統中用戶連接的當前數量。
這個對象計數器提供了在內部SQL Server資源中有效的閂的信息。計數器如下:
• 平均閂等待時間(毫秒) ( Average Latch Wait Time) 閂請求在得到服務之前必須等待的平均時間,以毫秒為單位。
• 閂等待數/秒(Latch Waits/sec) 不能立即服務,被迫等待其他資源釋放的閂請求的數量。
鎖對象提供了由SQL Server提出的各個鎖請求的有關數據,例如鎖生命周期和死鎖。可以在系統上具有多個這些計數器的實例。計數器如下所示:
• 平均等待時間(毫秒) ( Average Wait Time) 每個鎖請求被迫等待的平均時間量,以毫秒為單位。
• 鎖到期數/秒(Lock Timeouts/sec) 在系統中過期的鎖請求的數量。
• 鎖等待數/秒(Lock Wa i t s / s e c )不能立即滿足,需要調用線程在給予鎖之前處於等待狀態的鎖請求的數量。
• 死鎖數/秒(Number of Deadlocks/sec) 導致產生死鎖的鎖請求的數量。
內存管理器對象含有有關SQL Server內存使用的信息,包括SQL Server正在使用的高速緩
存內存的數量。這個對象下的計數器如下所示:
• 內存授權掛起(Memory Grants Pending) 等待授予工作空間內存的進程的當前數量。
• S Q L高速緩存內存(KB)(SQL Cache Memory) SQL Server用於動態SQL 高速緩存的動態
內存數量。
• 目標伺服器內存( K B ) ( Ta rget Server Memory) SQL Server將會消耗的動態內存的總額。
• 總的伺服器內存( K B ) ( Total Server Memory) SQL Server當前消耗的動態內存的總額。
這個對象提供了系統上正在執行的S Q L查詢的有關信息,包括查詢編譯和重新編譯的數量的數據。它有如下計數器:
• 批請求/秒(Batch Requests/sec) 伺服器接收到的S Q L批請求的數量。
• SQL 編譯/秒(SQL Compilations/sec) SQL Server每秒執行的S Q L語句編譯的數量。
• S Q L重新編譯/秒(SQL Re-Compilations/sec) SQL Server每秒執行的S Q L語句重新編譯的數量。
邏輯磁碟對象提供了有關邏輯磁碟I / O性能的信息。邏輯磁碟計數器與Windows NT磁碟
系統管理員分配給邏輯磁碟驅動器的字母相關。這個對象含有如下計數器:
• 磁碟讀時間百分比(%Disk Read Time) 選中的邏輯磁碟忙於服務讀請求總共用去時間的
百分比。
• 磁碟寫時間百分比(%Disk Write Time) 選中的邏輯磁碟忙於服務寫請求總共用去時間
的百分比。
• 磁碟時間百分比(%Disk Time) 選中的邏輯磁碟忙於服務讀請求或寫請求總共用的時間
的百分比,是磁碟寫時間百分比與磁碟讀時間百分比的和。
• 空閑時間百分比(%Idle Time) 邏輯磁碟在采樣時間間隔中處於空閑狀態的時間百分比。
• 平均磁碟隊列長度( Avg. Disk Queue Length) 在采樣的時間間隔中,選中的邏輯磁碟讀請求和寫請求排隊的平均數量。
• 平均磁碟讀隊列長度( Avg. Disk Read Queue Length) 在采樣的時間間隔中,對選中的邏輯磁碟讀請求排隊的平均數量。
• 平均磁碟寫隊列長度( Avg. Disk Write Queue Length) 在采樣的時間間隔中,對選中的邏輯磁碟寫請求排隊的平均數量。
• 平均磁碟秒數/讀( Avg. Disk sec/Read) 從邏輯磁碟讀數據的平均時間,以秒為單位。
• 平均磁碟秒數/寫( Avg. Disk sec/Write) 向邏輯磁碟寫數據的平均時間,以秒為單位。
• 平均磁碟秒數/傳輸( ( Avg. Disk sec/Transfer) 從邏輯磁碟進行傳輸的平均時間,以秒為單位。
• 磁碟讀/秒(Disk Reads Bytes/sec) 邏輯磁碟上每秒讀位元組。
• 磁碟讀/秒(Disk Writes Bytes/sec) 邏輯磁碟上每秒寫位元組。
• 磁碟讀/秒(Disk Reads/sec) 邏輯磁碟上的讀操作比率。
• 磁碟寫/秒(Disk Writes/sec) 邏輯磁碟上的寫操作比率。
• 磁碟傳輸/秒(Disk Transfers/sec) 邏輯磁碟上的讀和寫操作的比率。
物理磁碟對象提供了有關物理磁碟I / O性能的信息。它的磁碟計數器與系統中的物理驅動器有關,並且只有當運行了D i s k P e r f服務時,它才被激活。這個對象下的計數器如下所示:
• 磁碟讀時間百分比(%Disk Read Time) 選中的物理磁碟忙於服務讀請求總共用的時間的百分比。
• 磁碟寫時間百分比(%Disk Write Time) 選中的物理磁碟忙於服務寫請求總共用的時間的百分比。
• 磁碟時間百分比(%Disk Time) 選中的物理磁碟忙於服務讀請求或寫請求總共用的時間的百分比,是磁碟寫時間百分比與磁碟讀時間百分比的和。
• 空閑時間百分比(%Idle Time) 物理磁碟在采樣時間間隔中處於空閑狀態的時間百分比。
• 平均磁碟隊列長度( Avg. Disk Queue Length) 在采樣的時間間隔中,選中的物理磁碟讀請求和寫請求排隊的平均數量。
• 平均磁碟讀隊列長度( Avg. Disk Read Queue Length) 在采樣的時間間隔中,選中的物理磁碟讀請求排隊的平均數量。
• 平均磁碟寫隊列長度( Avg. Disk Write Queue Length) 在采樣的時間間隔中,選中的物理磁碟寫請求排隊的平均數量。
• 平均磁碟秒數/讀( Avg. Disk sec/Read) 從物理磁碟讀數據的平均時間,以秒為單位。
• 平均磁碟秒數/寫( Avg. Disk sec/Write) 向物理磁碟寫數據的平均時間,以秒為單位。
• 平均磁碟秒數/傳輸( Avg. Disk sec/Transfer) 從物理磁碟進行傳輸的平均時間,以秒為單位。
• 磁碟讀/秒(Disk Reads Bytes/sec) 物理磁碟上每秒讀位元組。
• 磁碟讀/秒(Disk Writes Bytes/sec) 物理磁碟上每秒寫位元組。
• 磁碟讀/秒(Disk Reads/sec) 物理磁碟上的讀操作比率。
• 磁碟寫/秒(Disk Writes/sec) 物理磁碟上的寫操作比率。
• 磁碟傳輸/秒(Disk Transfers/sec) 物理磁碟上的讀和寫操作的比率。
內存在任何系統中都是一個非常有價值的資源。Windows NT不只允許過量使用內存,而且鼓勵你過量使用內存。Windows NT提供了一種透明機制,允許應用「相信」它們具有比系統中可用的物理內存更多的內存。當Windows NT處理應用時,它將不使用的內存頁調出(交換出)到磁碟上的頁文件中。在大多數系統中,頁調度是正常的,但過量的頁調度會削弱整個系統的性能。下面的計數器允許你監控系統的頁調度。
• 失效的頁/秒(Page Faults/sec) 每秒由處理器處理的失效頁的全部數量。當一個進程需
要的代碼或數據不在它的工作區(它的空間在物理內存中)中時,發生失效頁。這個計數
器包括硬的頁失效(那些需要磁碟訪問的)和軟的頁失效(在物理內存的其他地方發現了失
效頁)。
• 讀的頁/秒(Page Reads/sec) 讀取磁碟以解決硬的頁失效所需要的時間數(當一個進程需要的代碼或數據不在其工作區或內存中的其他地方,必須從磁碟提取這些代碼和數據時,發生硬的頁失效)。這個計數器包括為滿足在文件系統高速緩存(通常是應用請求的)以及在非高速緩存映像內存文件中的失效而進行的讀。
• 寫的頁/秒(Page Writes/sec) 將頁寫向磁碟以釋放物理內存空間的時間數。只有當頁在物理內存中被改變的時候,將頁寫入磁碟,這樣,它們更有可能含有數據,而不是代碼。
• 頁/秒(Pages/sec) 為解決硬的頁失效,所需要讀或寫磁碟的時間數。它是讀的頁/秒與寫的頁/秒的計數器的和。
⑦ 如何用java實現web伺服器的監控
Hyperic HQ集成了強大的監測和管理功能,它有開源版本,您可以直接使用它用來對web伺服器進行監控。
如果您想自己寫代碼實現,Hyperic HQ提供了一個伺服器各種性能指標採集的API,這個API包本身提供了各種平台(linux/MAC/window等)的兼容。