我想更好地瞭解谷歌的雲控制檯爲Stackdriver跟蹤顯示呼叫詳細信息的方式和調試一些性能問題我的應用程序。 大多數請求與內存緩存設下重重的工作/ get操作，我這裏有一些問題，但我不明白的是爲什麼有電話之間的很長一段時間的差距。我已經上傳了2張截圖。谷歌應用程序引擎 - 雲控制檯爲Stackdriver跟蹤細節
所以，你可以看到，呼叫@ 1025ms了2ms的，但有它和網址抓取電話@ 5235ms之間超過4秒。首先，我的代碼在這一點上並不是密集的（並且完整的請求顯示了大約9000ms的未交付時間），其次，運行相同代碼的大多數類似請求沒有這些差距（即，重複請求不具有相同的行爲）。但是我也在其他請求上看到了這個問題，我無法複製它們。
請指教！
編輯：
我已經上傳從其他的Appstats截圖。這是一個「正常」的請求，通常需要幾百ms運行（最大1s），並且也在localhost（開發）中。我無法找到任何可以進一步調試的東西。我覺得我缺少一些簡單的東西，比如基礎層面的東西，關於應用引擎的DO和DO NOT。
鑑於這是很少發生的，實際的處理時間（由跨長表示）很短，我懷疑是某種App Engine的縮放動作在後臺發生。例如，減速可能是由於將新實例添加到應用程序中引起的。您可以通過查看App Engine儀表板上的活動圖或使用AppStats進一步深入研究（請參閱this SO後）。在跟蹤時間軸視圖
顯示App Engine的事件是什麼，我們一直在想了一會兒的事，因爲這將極大地縮短了這樣情況的分析過程。
我知道的這樣的間隙的以下常見原因（「untraced時間」）：
該請求實際上是在這些間隙期間CPU-約束。
要檢查這個問題，請轉到日誌查看器 並查看受影響的傳入HTTP請求的細節。需要注意的是 這裏還有從跟蹤的細節到日誌 進入一個方便直接的聯繫。在請求日誌條目，查找cpu_ms場，其中規定履行請求所需的
CPU毫秒。這是CPU實際執行應用程序代碼花費的毫秒數，以基準1.2 GHz Intel x86 CPU表示。如果實際使用的CPU速度比基準速度快，則CPU的毫秒數可能會大於實際時鐘時間[..]。 （doc）。
該指標也是protoPayload.megaCycles可用。
下面是具有大量untraced時間緩慢請求的示例的日誌條目：
2001:... - - [02/Mar/2017:19:20:22 +0100] "GET/HTTP/1.1" 200 660 - "Mozilla/5.0 ..." "example.com" ms=4966 **cpu_ms=11927** cpm_usd=7.376e-8 loading_request=1 instance=... app_engine_release=1.9.48 trace_id=...
的cpu_ms字段是（）在這個例子中請求unusally高，表明大部分的untraced的時間花在應用程序本身（或運行時）上。
爲什麼請求處理程序使用那麼多CPU？通常，幾乎不可能精確地確定CPU時間花在哪裏，但如果您知道給定請求中應該發生的情況，則可以更輕鬆地縮小它的範圍。兩個常見原因是：
這是對新啓動的App Engine實例的第一個請求。 JVM需要加載類和JIT編譯熱門方法 - 預計會顯着影響第一個請求（可能還有更多）。請在請求日誌條目中查找loading_request = 1，以檢查您的請求是否因此而緩慢。考慮Configuring Warmup Requests to Improve Performance。
普羅蒂普，你要專注你的調查篩選出這樣的裝載請求在日誌查看器的情況下，採用這種先進的過濾器：
protoPayload.megaCycles > 10000 and protoPayload.wasLoadingRequest=false
應用程序代碼的某些部分由被大規模放緩過度使用反射。這是特定於App Engine標準環境的，安全管理器限制反射的使用。只有緩解才能減少反思。請注意，App Engine服務基礎架構不斷髮展，所以此提示可能會比以後更早過期。
如果問題在dev應用程序服務器本地可重現，您可以使用一個分析器（或者可能只是jstack）來縮小它的範圍。在其他一些情況下，我實際上必須遞增地平分應用程序代碼，添加更多日誌語句，重新部署等，直到找到有問題的代碼。
其實有到未在App Engine環境標準覆蓋開箱通過爲Stackdriver跟蹤後端untraced電話。我目前知道的唯一例子是Cloud SQL。考慮使用Google Cloud Trace for JDBC與Cloud SQL進行交互。
該應用程序是多線程的（很棒！），並且遇到一些自己產生的同步問題。我在野外看到的示例：
我知道，激活將Appstats會對應用程序的性能產生影響，這是也是如此Stakdriver痕跡？ –
否 - GAE上的跟蹤功能內置於語言運行時，並且不會對您的應用程序產生可觀的性能影響。這意味着要按照規模生產，我們只對每個服務收到的請求的一小部分進行抽樣。 –
嗨，摩根，我已經激活了appstats，但我似乎無法找到某些東西可以繼續工作（我編輯了我的文章）。有任何想法嗎？ –