minio java client 使用okhttp作為底層的http實現，在產品包里面局域網上傳文件的速度一直只有400~800KB/s，經過一天排查發現是-Djava.compile=none禁用了即時編譯導致。
發現問題的場景
minio-java的使用架構圖是這樣的：
[Minio Server]<--nginx <== Proxy(Socks5 Sever) <== Agent(minio-java on top of okhttp)
and
[Minio Server]<--nginx <== Browser(minio-js api)
行雲管家發布的第一個私有雲版本（即4.0），由於網絡需要完全隔離，行雲管家的團隊網盤功能，無法使用阿里雲的OSS以及騰訊雲的COS作為媒介，經過多方考察，我們選用了MINIO作為服務端存儲的解決方案。minio-java適配很順利，畢竟它是兼容亞馬遜S3的，而阿里雲的OSS跟S3穿的是一條褲子，minio-java底層使用的是okhttp，添加socks代理支持也不在話下。
問題來了，正式發版以后，一個同事測試文件采集，上傳一個1.2G的文件用了50分鍾左右，私有部署跟Proxy以及Agent都安裝在一台機器上，帶寬理論上來說至少是百兆，速度應該不會低於10MB/s才正常。實測發現，Agent在minio-java情況下的上傳速度不超過800KB/s.
排查問題
是不是MINIO Server的問題？
檢查了MINIO Server的配置，都是是默認的，使用團隊網盤網頁上傳文件速度能接近帶寬速度（minio-js api），證明MINIO Server和前置的nginx都沒有問題。
是不是okhttp使用代理導致的？
Socks5代理Server是在Proxy進程里面啟動的，從開發上線到現在只經歷大概兩個版本的迭代，如果有隱藏bug確實不容易暴露的。我這么排查：還是用Agent采集文件，不過網盤分別是OSS和COS，速度都可以達到2~5MB/s，都走Socks5代理，這個速度是正常的，遠遠超過minio-java的速度。所以可以證明不是代理導致（我的代理程序還是相當靠譜的）。
定位到Wrapper
我在idea里面啟動Agent實例測試，發現速度接近帶寬速度。idea里面的進程跟安裝后的Agent最大的區別是：Agent是被java service wrapper包裝啟動的，而Java代碼是一模一樣的。於是我替換Agent的jre，調整內存等參數，都沒找到問題。
然后我升級了wrapper的版本到最新版，速度依然很慢。
定位到java.compile=none
我把速度正常的進程啟動參數和安裝Agent的啟動參數拿下來逐一對比，排除了一些明顯不可能的參數之后，發現安裝Agent里面有一個參數java.compile=none，把這個參數去掉以后，Agent文件采集的速度果然恢復正常：達到15MB/s。
速度慢的原因
Java程序是通過解釋器（Interpreter）進行解釋執行的，當虛擬機發現某些代碼執行非常頻繁時，會把這些代碼認定為熱點代碼。為了提高熱點代碼的執行效率，在運行時，即時編譯器（JIT，Just In Time Compiler）會把熱點代碼編譯成本地平台相關的機器碼。隨着時間的推移，編譯器逐漸發揮作用，把越來越多的代碼編譯成本地代碼之后，可以獲得更高的執行效率。
虛擬機參數：java.compile=none是禁用即時編譯的意思，去掉這個配置即可（默認是開啟的）。我已經忘記這個參數是怎么配置上去的了，或許是wrapper的默認配置？