資訊專欄INFORMATION COLUMN
摘要：后端和移動性能優化需要的時間較長，出成果較慢。大型網站上，一般通過什么方式監控性能的用戶端主要是真機監測監測，都屬于真實用戶監測。目前主要有以下兩種類型，，最終用戶性能監測。，，真實用戶性能監測。
@tanwen110 （唐文），曾負責騰訊四大平臺之一網絡媒體平臺的整體運維、運營規劃工作；曾任百度T7架構師和百度性能優化TOPIC、百度UAQ、APM平臺負責人；暢銷書《海量運維、運營規劃之道》作者； mmTrix創始人，后并入上市公司高升控股（000971.SZ），出任技術VP。
在互聯網環境日益復雜的今天，性能優化的價值在不斷提升。從用戶體驗到成本，各個方面都可產生收益，尤其在大型項目上這種收益更是呈現指數級的增加；另一方面，找到與競爭對手的性能差距，也是幫助產品超越對手的重要手段，性能的本質提升將大大助力項目突破難關。
購買鏈接：http://item.jd.com/11962556.html
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: 目前主要有以下兩種類型： 1、EUM，End user monitoring，最終用戶性能監測。通過在最終用戶設備上安裝客戶端的方式，通過主動監測獲得采樣的性能數據，Keynote是EUM的鼻祖，國內基調、博睿也屬于EUM。
2、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來源于開源中國高手問答活動
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/8972.html
摘要：本文轉載自微信公眾號賬號，作者為海航生態科技技術研究院大數據開發工程師高顏。文章介紹了海航生態科技輿情大數據平臺的容器化改造經驗，包括初期技術架構應用容器化架構遷移持續發布與部署。 本文轉載自微信公眾號Docker（賬號：dockerone），作者為海航生態科技技術研究院大數據開發工程師高顏。 文章介紹了海航生態科技輿情大數據平臺的容器化改造經驗，包括初期技術架構、應用容器化、架構遷...
摘要：年由云智慧領航，天機數據護航的航母艦隊將沿著政企客戶的創新發展之路砥礪前行，專業專注創新服務更多的中大型行業客戶，助力中國企業在互聯網的大潮中追風破浪 2016年是中國企業踐行互聯網+轉型的創新之年，是中國互聯網由消費互聯網向產業互聯網的晉級之年，也是云智慧由SaaS服務商脫胎換骨，華麗變身業務運維解決方案服務商，實現資源聚合、產業裂變之年。過去一年里，云智慧推出了面向企業核心業務全生...
摘要：安裝的包默認是的。所以我使用的來完成這些工作，同樣使用定時采樣定時匯報的方式來收集性能信息，并且官方宣稱耗費資源小于。以上只是通過持續檢查程序穩定性的一個基本方法。 PHP 7.0發布，網上關于新版的介紹很多，介于 7.0 在正式發布之前已經發過若干個 Beta、8個 RC，應該不會出現重大問題。今日我將一臺機器升級至 PHP 7.0 并將有關信息記錄如下。 本人使用 Ubuntu 1...
摘要：性能最好具有可量化可監測以及可改動的特性。下文是一份年的前端性能優化清單，闡述了作為前端開發人員，為了確保反饋速度以及瀏覽器兼容性我們需要考慮的問題。地圖設計的決定違背了性能理念，所以他在這份清單內的順序有待考慮。 2017前端性能優化清單 你開始使用漸進啟動了么？是不是已經使用過React和Angular中tree-shaking和code-splitting兩個工具？有沒有用過Br...
摘要：性能最好具有可量化可監測以及可改動的特性。下文是一份年的前端性能優化清單，闡述了作為前端開發人員，為了確保反饋速度以及瀏覽器兼容性我們需要考慮的問題。地圖設計的決定違背了性能理念，所以他在這份清單內的順序有待考慮。 2017前端性能優化清單 你開始使用漸進啟動了么？是不是已經使用過React和Angular中tree-shaking和code-splitting兩個工具？有沒有用過Br...
閱讀 1211·2023-04-26 02:20
閱讀 3337·2021-11-22 14:45
閱讀 4111·2021-11-17 09:33
閱讀 971·2021-09-06 15:00
閱讀 1479·2021-09-03 10:30
閱讀 3837·2021-07-26 22:01
閱讀 990·2019-08-30 15:54
閱讀 530·2019-08-30 15:43
