資訊專欄INFORMATION COLUMN
摘要：后端和移動性能優(yōu)化需要的時間較長，出成果較慢。大型網(wǎng)站上，一般通過什么方式監(jiān)控性能的用戶端主要是真機監(jiān)測監(jiān)測，都屬于真實用戶監(jiān)測。目前主要有以下兩種類型，，最終用戶性能監(jiān)測。，，真實用戶性能監(jiān)測。
@tanwen110 （唐文），曾負責(zé)騰訊四大平臺之一網(wǎng)絡(luò)媒體平臺的整體運維、運營規(guī)劃工作；曾任百度T7架構(gòu)師和百度性能優(yōu)化TOPIC、百度UAQ、APM平臺負責(zé)人；暢銷書《海量運維、運營規(guī)劃之道》作者； mmTrix創(chuàng)始人，后并入上市公司高升控股（000971.SZ），出任技術(shù)VP。
在互聯(lián)網(wǎng)環(huán)境日益復(fù)雜的今天，性能優(yōu)化的價值在不斷提升。從用戶體驗到成本，各個方面都可產(chǎn)生收益，尤其在大型項目上這種收益更是呈現(xiàn)指數(shù)級的增加；另一方面，找到與競爭對手的性能差距，也是幫助產(chǎn)品超越對手的重要手段，性能的本質(zhì)提升將大大助力項目突破難關(guān)。
購買鏈接：http://item.jd.com/11962556.html
Q：基于rest的微服務(wù)，有什么好的監(jiān)控方案推薦的，最好是對系統(tǒng)影響最小的
A：自定義給agent上報再通過關(guān)聯(lián)關(guān)系可視化，前、后期的工作都較多。
Q：網(wǎng)站怎么做好防刷，分布式的多個節(jié)點怎么做好監(jiān)控有啥好的建議不？
A：大一些的企業(yè)都有統(tǒng)一的七層接入層，在GSLB與LVS VIP之間，所有請求都會實時分析，同時會根據(jù)日常遇見的實際情況做好應(yīng)對的策略模板，如封禁，清洗，導(dǎo)流等。滯后些的做法是打進來，在日志或邏輯層分析。
Q：對于高性能網(wǎng)站性能優(yōu)化來說，由于涉及的方面太多太廣，該先從哪方面著手呢，有沒有什么步驟能做到有的放矢，做的事少而經(jīng)濟效益比較高。
A：前期系統(tǒng)、網(wǎng)絡(luò)優(yōu)化收益最大，一勞永逸，所有產(chǎn)品線收益。其次是前端優(yōu)化，前端決定了渲染內(nèi)容、結(jié)構(gòu)和邏輯，針對性的優(yōu)化收益也是非常明顯的。但前端跟產(chǎn)品線走，而且產(chǎn)品迭代容易覆蓋掉之前的優(yōu)化收益。后端和移動性能優(yōu)化需要的時間較長，出成果較慢。
Q：高并發(fā)下遇到瓶頸，一直對瓶頸的切入點不好把控，應(yīng)該從哪方面開始入手呢？
A：導(dǎo)致瓶頸出現(xiàn)的原因很多，架構(gòu)中的每一層都可能產(chǎn)生瓶頸和性能問題，需要具體問題具體分析。而且每天層和邏輯都存在容量和代碼本身的可能。瓶頸定位是一個系統(tǒng)的工程。
Q: 使用 APM（應(yīng)用性能管理）工具進行系統(tǒng)監(jiān)控的原理一般是改寫原來的字節(jié)碼程序，植入自己的代碼，請問，這種監(jiān)控方式你推薦嗎？這種方式對系統(tǒng)影響有多大
A: 前端JS和后端監(jiān)測及移動的SDK、語言類的SDK是侵入式的，都會產(chǎn)生一定的副作用，通?？梢猿闃觼頊p少這部分副作用。JS類的一般在150~200ms左右，語言類的要看具體的邏輯和訪問量。
Q: 大型網(wǎng)站上，一般通過什么方式監(jiān)控性能的？
A: 用戶端主要是PC真機監(jiān)測、PC JS監(jiān)測，都屬于真實用戶監(jiān)測。移動Web App使用JS監(jiān)測，移動Native App使用SDK的方式。以上兩類監(jiān)測數(shù)據(jù)都較完整；有損失的監(jiān)測還有在七層統(tǒng)一的接入也可以做請求到后端及后端返回數(shù)據(jù)的相關(guān)監(jiān)測，后端打點等也是常用的方式。
Q:你好，請問你對分布式系統(tǒng)監(jiān)控系統(tǒng)的設(shè)計時傾向于每個節(jié)點獨立監(jiān)控，然后在系統(tǒng)空閑的時候手動搜集；還是建立一個分布式的監(jiān)控系統(tǒng)實時監(jiān)控。感覺后者會增加系統(tǒng)復(fù)雜度讓系統(tǒng)更難維護，但是前者會讓搜集數(shù)據(jù)過少。如何權(quán)衡呢？謝謝
A：看企業(yè)所處的階段，早期和小規(guī)模用前者，成長型企業(yè)用分布式。可持續(xù)看第二種的價值更大，復(fù)雜度、降低復(fù)雜度與價值去平衡。
Q：我們做了一個響應(yīng)式拖拽建站系統(tǒng)，現(xiàn)在有個問題，如何監(jiān)控每一個站點（域名）的流量情況，所有的http請求，而圖片和視頻這些資源可能會使用一些CDN的服務(wù)。我描述的不是很專業(yè)，還請不吝賜教?？梢哉f幾個點，我現(xiàn)在沒有方向。
A: 因為使用CDN和多站點，多域名。CDN的流量數(shù)據(jù)在CDN服務(wù)商的日志中有才能體現(xiàn)。這兩部分數(shù)據(jù)直接拼接是很困難的。可能根據(jù)PV、UV等經(jīng)驗值，從源站上反推。
Q：主要是通過什么進行性能監(jiān)測的？目前覺得大型網(wǎng)站合理利用緩存很重要。
A: 目前主要有以下兩種類型： 1、EUM，End user monitoring，最終用戶性能監(jiān)測。通過在最終用戶設(shè)備上安裝客戶端的方式，通過主動監(jiān)測獲得采樣的性能數(shù)據(jù)，Keynote是EUM的鼻祖，國內(nèi)基調(diào)、博睿也屬于EUM。
2、RUM，Real user monitoring ，真實用戶性能監(jiān)測。通過嵌碼的方式獲得全用戶真實性能數(shù)據(jù)。嵌碼方式分三種：網(wǎng)頁嵌JS、移動APP嵌SDK、服務(wù)器端嵌代理。Newrelic和Appdynamics都支持這三種方式，國內(nèi)基調(diào)、OneAPM也基本支持這三種方式。
Q: 您認為在未來隨著固態(tài)硬盤等硬件成本降低、類redis內(nèi)存數(shù)據(jù)庫或cdn等緩存技術(shù)的發(fā)展，給性能測試的挑戰(zhàn)是什么，我們是更應(yīng)該著手架構(gòu)還是代碼邏輯還是其他方面？謝謝！
A: 硬件和緩存會影響后端的性能，性能是一個復(fù)雜的夠成，往往用戶端、終端產(chǎn)品形態(tài)，前端、網(wǎng)絡(luò)是性能的重災(zāi)區(qū)。第二個問題，推薦從用戶側(cè)做性能優(yōu)化更容易出收益，后端的優(yōu)化代價和門檻都較高。
Q: 對APM服務(wù)有啥好的建議，包括選擇，推薦
A: 首先需要理解各廠商和開源項目的原理，每家特點及技術(shù)團隊的背景都不同，再結(jié)合多家優(yōu)點解決面臨的問題。目前國內(nèi)、國外排前的廠商在網(wǎng)上也容易找到。如果是互聯(lián)網(wǎng)企業(yè)，TO C類業(yè)務(wù)，我推薦用JS監(jiān)測，PC、移動都容易上手，上線就有數(shù)據(jù)。
Q: 你好，之前在站點運營中常遇到“以空間換時間”的情況 比如加內(nèi)存 升配置 加寬帶 請教一些比較經(jīng)濟適用的方法 （其實程序的成本也是很高的，優(yōu)化程序需要時間，程序只能說按照各框架規(guī)則寫出常規(guī)的程序）雖然之前那些做法省去了開發(fā)成本 但無疑是增加了運營成本維護成本
A: 帶寬的發(fā)生主要是前端內(nèi)容，這里決定了主要成本，訪問日志中可以分析出TOP帶寬消耗的元素，針對帶寬大戶進行優(yōu)化就好，性能和成本雙重收益。后端升硬件配置，在時間和人力及不確定性的情況與沒有選擇的，但與架構(gòu)、代碼并行優(yōu)化也是需要的。
本集Q&A來源于開源中國高手問答活動
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/8972.html
摘要：本文轉(zhuǎn)載自微信公眾號賬號，作者為海航生態(tài)科技技術(shù)研究院大數(shù)據(jù)開發(fā)工程師高顏。文章介紹了海航生態(tài)科技輿情大數(shù)據(jù)平臺的容器化改造經(jīng)驗，包括初期技術(shù)架構(gòu)應(yīng)用容器化架構(gòu)遷移持續(xù)發(fā)布與部署。 本文轉(zhuǎn)載自微信公眾號Docker（賬號：dockerone），作者為海航生態(tài)科技技術(shù)研究院大數(shù)據(jù)開發(fā)工程師高顏。 文章介紹了海航生態(tài)科技輿情大數(shù)據(jù)平臺的容器化改造經(jīng)驗，包括初期技術(shù)架構(gòu)、應(yīng)用容器化、架構(gòu)遷...
摘要：年由云智慧領(lǐng)航，天機數(shù)據(jù)護航的航母艦隊將沿著政企客戶的創(chuàng)新發(fā)展之路砥礪前行，專業(yè)專注創(chuàng)新服務(wù)更多的中大型行業(yè)客戶，助力中國企業(yè)在互聯(lián)網(wǎng)的大潮中追風(fēng)破浪 2016年是中國企業(yè)踐行互聯(lián)網(wǎng)+轉(zhuǎn)型的創(chuàng)新之年，是中國互聯(lián)網(wǎng)由消費互聯(lián)網(wǎng)向產(chǎn)業(yè)互聯(lián)網(wǎng)的晉級之年，也是云智慧由SaaS服務(wù)商脫胎換骨，華麗變身業(yè)務(wù)運維解決方案服務(wù)商，實現(xiàn)資源聚合、產(chǎn)業(yè)裂變之年。過去一年里，云智慧推出了面向企業(yè)核心業(yè)務(wù)全生...
摘要：安裝的包默認是的。所以我使用的來完成這些工作，同樣使用定時采樣定時匯報的方式來收集性能信息，并且官方宣稱耗費資源小于。以上只是通過持續(xù)檢查程序穩(wěn)定性的一個基本方法。 PHP 7.0發(fā)布，網(wǎng)上關(guān)于新版的介紹很多，介于 7.0 在正式發(fā)布之前已經(jīng)發(fā)過若干個 Beta、8個 RC，應(yīng)該不會出現(xiàn)重大問題。今日我將一臺機器升級至 PHP 7.0 并將有關(guān)信息記錄如下。 本人使用 Ubuntu 1...
摘要：性能最好具有可量化可監(jiān)測以及可改動的特性。下文是一份年的前端性能優(yōu)化清單，闡述了作為前端開發(fā)人員，為了確保反饋速度以及瀏覽器兼容性我們需要考慮的問題。地圖設(shè)計的決定違背了性能理念，所以他在這份清單內(nèi)的順序有待考慮。 2017前端性能優(yōu)化清單 你開始使用漸進啟動了么？是不是已經(jīng)使用過React和Angular中tree-shaking和code-splitting兩個工具？有沒有用過Br...
摘要：性能最好具有可量化可監(jiān)測以及可改動的特性。下文是一份年的前端性能優(yōu)化清單，闡述了作為前端開發(fā)人員，為了確保反饋速度以及瀏覽器兼容性我們需要考慮的問題。地圖設(shè)計的決定違背了性能理念，所以他在這份清單內(nèi)的順序有待考慮。 2017前端性能優(yōu)化清單 你開始使用漸進啟動了么？是不是已經(jīng)使用過React和Angular中tree-shaking和code-splitting兩個工具？有沒有用過Br...
閱讀 1252·2023-04-26 02:20
閱讀 3375·2021-11-22 14:45
閱讀 4199·2021-11-17 09:33
閱讀 1040·2021-09-06 15:00
閱讀 1519·2021-09-03 10:30
閱讀 3931·2021-07-26 22:01
閱讀 1028·2019-08-30 15:54
閱讀 567·2019-08-30 15:43
