網站或介面響應時間較長應該如何排查?
我就簡單說一下:
1.假如你的網站開啟很久,什麼原因呢,先從最外層排查。
瀏覽器按F12,看看Network哪個檔案時間最長,這個是為了排查有可能css或者js外掛引用了一些被國內牆住的地址,一直請求不到,所以時間很久。找到相關的地方註釋,或者引用本地的。
2.如果檔案引用什麼的都沒問題,看介面吧,先自己寫個指令碼訪問內網訪問一下介面,看看是否時間很長,如果很長,追進介面,逐條分析,找到sql去mysql執行一下,看看時間是否很久,如果很久,就要優化SQL問題了,expain一下SQL看看索引情況啥的,針對性優化。資料量太大的能分表就分表,能分庫就分庫。如果SQL沒啥問題,那可能就是寫的邏輯程式碼的問題了,一行行審程式碼,找到耗時的地方改造,優化邏輯。
3.如果引用檔案,和介面訪問都沒問題,那可能是網路問題,比如你們用的是電信機房,使用者在聯通訪問,很慢。你換個其他教育網,聯通網啥的環境試一下看看是否慢,如果慢,那你們就要採用CDN加速策略,或者想其他辦法了。
相關推薦
網站或介面響應時間較長應該如何排查?
我就簡單說一下: 1.假如你的網站開啟很久,什麼原因呢,先從最外層排查。 瀏覽器按F12,看看Network哪個檔案時間最長,這個是為了排查有可能css或者js外掛引用了一些被國內牆住的地址,一直請求不到,所以時間很久。找到相關的地方註釋,或者引用本地的。 2.如果檔案引用
網站或接口響應時間較長應該如何排查?
引用 ash 圖片 響應 ask java href 產生 ext 假如你的網站打開很久,什麽原因呢,先從最外層排查。瀏覽器按F12,看看Network哪個文件時間最長,這個是為了排查有可能css或者js插件引用了一些被國內墻住的地址,一直請求不到,所以時間很久。找到相關的
網站響應時間過長的原因及解決方法
網站打不開 網站程序 cas ron height 出口 javascrip 運算 access 遇到過類似問題,我認為有以下幾個原因: 1、網站服務器故障維修(這種情況只能等段
Epoll 連線無響應或響應時間過長
Epoll有兩種模式,LT模式 與 ET模式。預設情況下是LT模式,由於ET模式在高併發,高流量的情況下,處理效率會高於ET模式,所以也就採用了ET模式。 伺服器一直執行良好,跑幾千機器人也沒有什麼問題。但突然之間發現,機器人在反覆掉線上線的測試後,會出現一種情況:伺服器端
服務器響應時間過長
服務器響應時間服務器網站響應時間過長的問題解決方法如下: 1、機器的配置。包括服務器端與客戶機端的硬件配置程度,同樣的網絡環境下,雙核的服務器的運算能力肯定要強一些,毫無疑問的,同樣的網絡環境下,用一臺賽揚的機器和奔四雙核處理器的電腦,打開同樣的網頁,速度,也肯定不一樣。 2、服務器軟件。軟件多少、穩定和軟件
關於.Net mvc 專案在本地vs執行響應時間過長無法訪問時,解決方法!
最近可能是剛升級了電腦使用了window10作業系統,總是遇到了一些以前沒有遇到過的事情! 今早來到公司本來準備寫bug的,但是當我開啟vs執行的時候發現今天的電腦響應的時間明顯的要比之前開啟網頁除錯的時間要長的多,到最後不但沒有開啟,而且還提示了一個這樣的問題! 如圖: 這就蛋
spark-submit時上傳spark依賴到hdfs時間較長問題解決
spark-submit時,發現上傳spark依賴到hdfs 時間長達數分鐘,現象如下方截圖: 這個日誌之後在上傳程式依賴的jar,根據不同網路負荷,需要耗時數十秒甚至數分鐘,導致任務提交速度超級慢,在官網上查到出現這種現象的原因:https://spark.apache.org/do
網站載入 Waiting (TTFB) 時間過長的原因和解決辦法
https://www.wpzhiku.com/wating-ttfb-too-long/ 什麼是 Waiting (TTFB) 時間 TTFB 是 Time to First Byte 的縮寫,指的是瀏覽器開始收到伺服器響應資料的時間(後臺處理時間+重定向時間),是反
響應時間多長才是合適的
介面響應時間一直是影響使用者對於軟體主觀滿意度的一個重要因素,包括定性和定量兩個因素: 定性方面的影響因素包括: 1、使用者的期望,這包括了使用者對於產品的熟悉程度,使用者的其他生理及心理特點以及操作的頻繁程度; 2、某些產品的使用環境在客觀上要求響應時間越快越好; 3、產
JVM六:查詢最最耗cpu的執行緒或執行緒時間最長並定位程式碼
jstack可以定位到執行緒堆疊,根據堆疊資訊我們可以定位到具體程式碼,所以它在JVM效能調優中使用得非常多。下面我們來一個例項找出某個Java程序中最耗費CPU的Java執行緒並定位堆疊資訊,用到的命令有ps、top、printf、jstack、grep。 第一步先找出Java程序ID,伺服器上的Java
【譯】怎麼精確判斷終端使用者響應時間過長的原因
譯者:原始文章有點效能測試工具軟文的感覺,畢竟文章來源於某工具官方部落格。高手請略過。 對於我這種新手,此文還是給我帶來一些驚喜,從上到下地,從表象到根源地,定位他們遇到效能問題-響應時間過長-的根本原因,有具體的步驟,思考和判斷依據,這就是一個比較不錯效能測試分析例項。可以更清楚看到效能測試如何分析定位,
Tomcat響應時間過長,超時報錯的解決辦法。
有時間電腦太卡,會遇到tomcat響應時間過長,超時報錯 解決辦法修改eclipse工作空間下的:start-timeout 配置時間(他的預設配置時間是45 可以修改成更大的值) 1: 修改路徑:(E:\eclipseFile\.metadata\.plugins\or
lvs叢集 NAT模式rr輪詢失敗或輪詢時間過長問題
首先,略過前面配置不提,director和rs1,2都是使用虛擬機器。直接表現問題:director主機:curl vip 輪詢正常,但是使用物理機訪問vip輪詢失敗或者要等待好長時間。經過驗證發現:是虛機效能問題:起始狀態:ActiveConn都為0當訪問物理機vip時,
Android程式冷啟動白屏時間較長
Instant Run在我們使用AndroidStudio編譯apk的時候,使用的gradle tool版本較高的話,程式會在啟動的時候去初始化Instant Run,從而導致啟動時間較長,例如: buildscript { repositories {
Java heap space造成tomcat響應時間過長,原因在JVM記憶體分配太小,解決方法
使用Java程式從資料庫中查詢大量的資料時出現異常:java.lang.OutOfMemoryError: Java heap space 在JVM中如果98%的時間是用於GC且可用的 Heap size 不足2%的時候將丟擲此異常資訊。 JVM堆的設定是指java程式
為什麼場景的平均響應時間比是實際操作的響應時間要長
對時間的解釋: 1、DNS Resolution:瀏覽訪問一個網站的時候,一般用的是域名,需要DNS伺服器把域名解析為IP地址,這個過程就是域名解析時間. 2、Connection:解析出Web Server的IP地址後,瀏覽器請求被髮送到了一個Web Server,然後瀏覽器和Web Server 之間需要
【fiddler】fiddler 延長某個特定資源或介面的返回時長
有這樣一種場景——需要對某個介面或者靜態資源返回時長延長一定的毫秒數 1、可以使用Chrome開發工具中的network condition選項,可以模擬不同網路狀態下的訪問情況,但是這個不能對具體的某個資源或介面 2、使用fiddler來攔截某個特定的
淘寶ip地址庫介面會導致TTFB時間變長,網站開啟速度變慢
前一段時間閒來無事發現別人的網站上有顯示當前使用者城市的功能,就自己也整了一個 這是淘寶ip地址庫呼叫方法 然後問題就出現了,網站開啟速度慢的要死 用F12發現是TTFB太慢,然後百度了,發現了問題的原因:https://q.cnblogs.com/q/99729/ 總結一下把:首先,我遇到的問題的原
C# SQL語句執行時間過長在操作完成之前超時時間已過或伺服器未響應問題的解決
SqlCommand sold_cmd = new SqlCommand(sql_sold,conn); sold_cmd.CommandTimeout = 300; SqlCommand detail_c
網站流量與效能分析指標——PV、UV、PR、IP、QPS、併發數、吞吐量、響應時間
QPS:每秒查詢率(Query Per Second) ,每秒的響應請求數,也即是最大吞吐能力。 QPS = req/sec = 請求數/秒 QPS統計方式 [一般使用 http_load 進行統計] QPS = 總請求數 / ( 程序總數 * 請求時間 ) QPS:單個程序每秒請求伺服器的成功次數