大型網站性能監測、分析與優化常見問題Q&A

圖片描述
@tanwen110 (唐文),曾負責騰訊四大平臺之一網絡媒體平臺的總體運維、運營規劃工做;曾任百度T7架構師和百度性能優化TOPIC、百度UAQ、APM平臺負責人;暢銷書《海量運維、運營規劃之道》做者; mmTrix創始人,後併入上市公司高升控股(000971.SZ),出任技術VP。html

在互聯網環境日益複雜的今天,性能優化的價值在不斷提高。從用戶體驗到成本,各個方面均可產生收益,尤爲在大型項目上這種收益更是呈現指數級的增長;另外一方面,找到與競爭對手的性能差距,也是幫助產品超越對手的重要手段,性能的本質提高將大大助力項目突破難關。前端

圖片描述

購買連接:http://item.jd.com/11962556.htmlredis

Q:基於rest的微服務,有什麼好的監控方案推薦的,最好是對系統影響最小的數據庫

A:自定義給agent上報再經過關聯關係可視化,前、後期的工做都較多。後端

Q:網站怎麼作好防刷,分佈式的多個節點怎麼作好監控有啥好的建議不?緩存

A:大一些的企業都有統一的七層接入層,在GSLB與LVS VIP之間,全部請求都會實時分析,同時會根據平常碰見的實際狀況作好應對的策略模板,如封禁,清洗,導流等。滯後些的作法是打進來,在日誌或邏輯層分析。性能優化

Q:對於高性能網站性能優化來講,因爲涉及的方面太多太廣,該先從哪方面着手呢,有沒有什麼步驟能作到有的放矢,作的事少而經濟效益比較高。服務器

A:前期系統、網絡優化收益最大,一勞永逸,全部產品線收益。其次是前端優化,前端決定了渲染內容、結構和邏輯,針對性的優化收益也是很是明顯的。但前端跟產品線走,並且產品迭代容易覆蓋掉以前的優化收益。後端和移動性能優化須要的時間較長,出成果較慢。網絡

Q:高併發下遇到瓶頸,一直對瓶頸的切入點很差把控,應該從哪方面開始入手呢?架構

A:致使瓶頸出現的緣由不少,架構中的每一層均可能產生瓶頸和性能問題,須要具體問題具體分析。並且天天層和邏輯都存在容量和代碼自己的可能。瓶頸定位是一個系統的工程。

Q: 使用 APM(應用性能管理)工具進行系統監控的原理通常是改寫原來的字節碼程序,植入本身的代碼,請問,這種監控方式你推薦嗎?這種方式對系統影響有多大

A: 前端JS和後端監測及移動的SDK、語言類的SDK是侵入式的,都會產生必定的反作用,一般能夠抽樣來減小這部分反作用。JS類的通常在150~200ms左右,語言類的要看具體的邏輯和訪問量。

Q: 大型網站上,通常經過什麼方式監控性能的?

A: 用戶端主要是PC真機監測、PC JS監測,都屬於真實用戶監測。移動Web App使用JS監測,移動Native App使用SDK的方式。以上兩類監測數據都較完整;有損失的監測還有在七層統一的接入也能夠作請求到後端及後端返回數據的相關監測,後端打點等也是經常使用的方式。

Q:你好,請問你對分佈式系統監控系統的設計時傾向於每一個節點獨立監控,而後在系統空閒的時候手動蒐集;仍是創建一個分佈式的監控系統實時監控。感受後者會增長系統複雜度讓系統更難維護,可是前者會讓蒐集數據過少。如何權衡呢?謝謝

A:看企業所處的階段,早期和小規模用前者,成長型企業用分佈式。可持續看第二種的價值更大,複雜度、下降複雜度與價值去平衡。

Q:咱們作了一個響應式拖拽建站系統,如今有個問題,如何監控每個站點(域名)的流量狀況,全部的http請求,而圖片和視頻這些資源可能會使用一些CDN的服務。我描述的不是很專業,還請不吝賜教。能夠說幾個點,我如今沒有方向。

A: 由於使用CDN和多站點,多域名。CDN的流量數據在CDN服務商的日誌中有才能體現。這兩部分數據直接拼接是很困難的。可能根據PV、UV等經驗值,從源站上反推。

Q:主要是經過什麼進行性能監測的?目前以爲大型網站合理利用緩存很重要。

A: 目前主要有如下兩種類型: 一、EUM,End user monitoring,最終用戶性能監測。經過在最終用戶設備上安裝客戶端的方式,經過主動監測得到採樣的性能數據,Keynote是EUM的鼻祖,國內基調、博睿也屬於EUM。

二、RUM,Real user monitoring ,真實用戶性能監測。經過嵌碼的方式得到全用戶真實性能數據。嵌碼方式分三種:網頁嵌JS、移動APP嵌SDK、服務器端嵌代理。Newrelic和Appdynamics都支持這三種方式,國內基調、OneAPM也基本支持這三種方式。

Q: 您認爲在將來隨着固態硬盤等硬件成本下降、類redis內存數據庫或cdn等緩存技術的發展,給性能測試的挑戰是什麼,咱們是更應該着手架構仍是代碼邏輯仍是其餘方面?謝謝!

A: 硬件和緩存會影響後端的性能,性能是一個複雜的夠成,每每用戶端、終端產品形態,前端、網絡是性能的重災區。第二個問題,推薦從用戶側作性能優化更容易出收益,後端的優化代價和門檻都較高。

Q: 對APM服務有啥好的建議,包括選擇,推薦

A: 首先須要理解各廠商和開源項目的原理,每家特色及技術團隊的背景都不一樣,再結合多家優勢解決面臨的問題。目前國內、國外排前的廠商在網上也容易找到。若是是互聯網企業,TO C類業務,我推薦用JS監測,PC、移動都容易上手,上線就有數據。

Q: 你好,以前在站點運營中常遇到「以空間換時間」的狀況 好比加內存 升配置 加寬帶 請教一些比較經濟適用的方法 (其實程序的成本也是很高的,優化程序須要時間,程序只能說按照各框架規則寫出常規的程序)雖然以前那些作法省去了開發成本 但無疑是增長了運營成本維護成本

A: 帶寬的發生主要是前端內容,這裏決定了主要成本,訪問日誌中能夠分析出TOP帶寬消耗的元素,針對帶寬大戶進行優化就好,性能和成本雙重收益。後端升硬件配置,在時間和人力及不肯定性的狀況與沒有選擇的,但與架構、代碼並行優化也是須要的。

本集Q&A來源於開源中國高手問答活動
圖片描述

相關文章
相關標籤/搜索