原文網址：https://plumbr.eu/blog/gc-impact-on-throughput-and-latency
譯文網址：http://blog.dontcareabout.us/2014/03/gc-throughput.html
BBS 版以 markdown 語法撰寫
______________________________________________________________________
有一類問題是每一個 Java application 都會遇到的，那就是 GC。
當 GC 正常運作時，它是一個美妙的發明；
當它沒有運作、或是 GC 用出乎意料的方式運作，
那你的朋友就會翻臉變成仇人。
這篇文章是關於 GC 造成的暫停時間。
或著更精確地說：為什麼你要在意這些暫停時間？
前幾篇文章，我用 Apple CEO [Tim Cook] 針對 iPad 需求與建廠的規劃，
來[解釋 throughput 與延遲時間][T and L]。
這裡我將沿用同一個例子：
* 我們有一個生產線每秒可以製造一台 iPad。
所以**這條生產線的 throughput 是每天 86400 台 iPad**。
* 從外殼成型開始到驗收測試結束，一台 iPad 需要 4 小時的時間。
所以**這條生產線的延遲時間是 4 個小時**。
上述系統以及計算結果，是假設生產線每天不間斷地運作 24 小時。
但是所有生產線都需要保養，對應到 JVM 就是執行 GC。
舉例來說，作小型保養可以在不怎麼中斷製程的情況下處理完畢；
可能是幫機器上油、或是把塑模設備旁邊地板的垃圾撿起來。
這些操作行為跟 JVM 中的 minor GC 相似，你必須作這些維護。
不過，因為實作寫得太聰明，所以對系統效能來說沒什麼影響。
跟 Tim Cook 一樣，還是得面對長時間的維護任務。
這些任務得停止整個生產線，
相當於執行 full GC 時 JVM 需要暫停 thread 以作一些整理的工作。
現在假設在幾個月不間斷的服務之後，
我們想像中的生產線卡住了，
技術團隊需要 4 個小時才能解決問題，
這段時間生產線是停止的。
我們要如何計算影響程度？
一如往常，影響程度可以從兩個不同面相去評估：
* **throughput 的影響**：
停機的這 4 個小時代表有 14400 秒沒辦法做出 iPad。
以 throughput 來看，在這特定的一天當中，
系統的產能會從 86400 降到 72000。
這代表 **throughput 損失了約 16.5%**。
* **延遲時間的影響**：
如果一台 iPad 在中斷作業的時候仍然在生產線上，
則它的完成時間會長達 8 個小時而不是 4 個小時。
這表示**在最壞的情況下延遲時間增加了 100%**。
如果你還記得，其實 Cook [並不在意延遲時間][T and L]。
對他而言，重點在於長時間區段內的整體 throughput。
所以 Cook 決定以盡可能不影響 throughput 的方式來調整生產流程。
軟體開發也需要做出類似的決定。
如果你有負責處理訂單的 Java EE application，
那麼 GC 暫停超過 4 秒，肯定會降低系統的 throughput。
但對大多數的人而言，這不是主要議題。
另一方面，試圖在清理空間的這四秒鐘內作某些事情的使用者，
會覺得我們的系統很遲鈍。
讓使用者覺得服務操作起來很遲鈍，這是商業軟體的大忌。
這個故事告訴我們什麼？
明智地選擇你的目標，
並且確定你有搞清楚 throughput 跟延遲時間的區別。
然後確保你瞭解 GC 的影響，
無論是監看 GC 的 log 或是找尋意料外的 full GC 動作，
並且調整 application 以及 GC 來將影響降到最低。
如果你看到這邊，那我還有一個有趣的故事。
請看我們的[舊文章]，並考慮關注[我們的 Twitter]。
[Tim Cook]: http://en.wikipedia.org/wiki/Tim_Cook
[T and L]: https://plumbr.eu/blog/
throughput-and-latency-performance-tuning-made-simple
[舊文章]: https://plumbr.eu/blog
[我們的 Twitter]: https://twitter.com/intent/
follow?region=follow_link&screen_name=javaplumbr