幹壞事是進步最大的原動力
在 SSL Labs 上翻資料的時候發現看到台灣有些網站的 SSL 憑證在 Java Trust Store 內是不會取得信任授權的，但其他的都支援，像是這樣：
翻了幾個後發現都是 TWCA 的，在其他家都是這樣授權出來的 (Mozilla/Apple/Android/Windows)：(TWCA Root Certification Authority -> ) TWCA Global Root CA -> TWCA Secure SSL Certification Authority -> Final，也就是 TWCA 的兩個 Root CA 都在 trust store 內，走任何一條授權都可以拉出來。
印象中之前應該都是支援的... 先前是 cross sign 嗎？@_@
在解決 Cassandra 效能問題中大概就 ScyllaDB 特別有名，用 C++ 重寫一次使得效能大幅改善。而 Instagram 的人則是把底層的資料結構換掉，改用 RocksDB (這公司真的很愛自家的 RocksDB...)：「Open-sourcing a 10x reduction in Apache Cassandra tail latency」。
主要原因是他們發現 Cassandra 在處理資料的部份會有 JVM 的 GC 問題，而且是導致 Cassandra 效能差的主要原因：
Apache Cassandra is a distributed database with it’s own LSM tree-based storage engine written in Java. We found that the components in the storage engine, like memtable, compaction, read/write path, etc., created a lot of objects in the Java heap and generated a lot of overhead to JVM.
然後在換完後測試可以看到效能大幅提昇，也可以看到 GC 的延遲大幅降低：
In one of our production clusters, the P99 read latency dropped from 60ms to 20ms. We also observed that the GC stalls on that cluster dropped from 2.5% to 0.3%, which was a 10X reduction!
比較一下這兩者的差異：在 ScyllaDB 是全部都用 C++ 改寫 (資料結構不換)，這樣就直接解決掉 JVM 的 GC 問題。在 Rocksandra 則是在 profiling 後挑重點換掉 (這邊看起來是處理資料的 code，直接換成 RocksDB)，另外順便把一些界面抽象化... 兩個不一樣的解法，都解決了 JVM 的 GC 問題。
看到「JVM Anatomy Park」這篇，作者是 Red Hat 裡 OpenJDK 團隊的人，寫了二十則與 JVM 效能相關的主題，裡面提到每則大約花五到十分鐘可以看完，不過我覺得應該會再久一點 (需要翻資料交叉查)。
除了網頁版外，也提供 EPUB、MOBI 與 PDF 格式可以下載。
都是講效能相關的，從不同角度看。以第一個 Lock Coarsening and Loops 來說，已知這段程式碼：
synchronized (obj) {
// statements 1
}
synchronized (obj) {
// statements 2
}會被轉換成這樣等效的程式碼：
synchronized (obj) {
// statements 1
// statements 2
}作者就問了，那這樣的話，這段：
for (...) {
synchronized (obj) {
// something
}
}會不會轉成這段呢：
synchronized (this) {
for (...) {
// something
}
}答案是不會，但可以橋：
While lock coarsening does not work on the entire loop, another loop optimization — loop unrolling — sets up the stage for the regular lock coarsening, once the intermediate representation starts to look as if there are N adjacent lock-unlock sequences. This reaps the performance benefits, and helps to limit the scope of coarsening, to avoid over-coarsening over fat loops.
就大概是這樣的主題 XD 每天看個一兩篇慢慢消化還不錯...
扣除掉 fork 的程式碼後，研究人員在 GitHub 上還是發現有大量重複的程式碼：「DéjàVu: a map of code duplicates on GitHub」。
This paper analyzes a corpus of 4.5 million non-fork projects hosted on GitHub representing over 482 million files written in Java, C++, Python, and JavaScript. We found that this corpus has a mere 85 million unique files.
用 Java/C++/Python/JavaScript 寫的 4.5M 個專案有 482M 個檔案，但只有 85M 個檔案是不一樣的 XD
想一想其實也是... 現在愈來愈多工具產生程式碼了 XD (i.e. Scaffold)
Amazon Athena 支援 ODBC 了 (先前直接連結只支援 JDBC)：「Amazon Athena adds support for querying data using an ODBC driver」。
With the availability of a new ODBC driver, you can now connect popular business intelligence tools to Athena. This allows you to report and visualize all of your data in S3 with the tools of your choice. In addition to the ODBC driver, Customers can now connect to Amazon Athena using a JDBC driver, an API and via the AWS Console.
這讓非 Java 的程式語言可以更方便的接上去了，像是 PHP 的 PDO 支援 ODBC 但不支援 JDBC，要用就得想其他辦法：「PHP: PDO Drivers - Manual」。
在「zetcd: running ZooKeeper apps without ZooKeeper」這邊介紹了用 etcd 當作 ZooKeeper 伺服器。程式碼在「Serve the Apache Zookeeper API but back it with an etcd cluster」這邊可以看到。
不過可以看到有不少 overhead：
但 etcd 用 Go 寫 (省下 JVM tuning？)，可能是個不錯的誘因...
ajermakovics/jvm-mon 這個專案可以看 JVM 的情況 (像是 heap 與 gc 的狀態)：
花俏了點，不過是個頗有趣的東西... 隔壁的 patric-r/jvmtop 應該會比較實用一些。
這篇是兩年前在 StackOverflow 上的問題：「Why is printing “B” dramatically slower than printing “#”?」。
問問題的人這段程式跑了 8.52 秒：
Random r = new Random();
for (int i = 0; i < 1000; i++) {
for (int j = 0; j < 1000; j++) {
if(r.nextInt(4) == 0) {
System.out.print("O");
} else {
System.out.print("#");
}
}
System.out.println("");
}而把上面的 # 換成 B 就變成 259.152 秒。
答案是與 word-wrapping 有關：
Pure speculation is that you're using a terminal that attempts to do word-wrapping rather than character-wrapping, and treats B as a word character but # as a non-word character. So when it reaches the end of a line and searches for a place to break the line, it sees a # almost immediately and happily breaks there; whereas with the B, it has to keep searching for longer, and may have more text to wrap (which may be expensive on some terminals, e.g., outputting backspaces, then outputting spaces to overwrite the letters being wrapped).
But that's pure speculation.
這真是細節 XDDD
在翻「Stuff The Internet Says On Scalability For February 19th, 2016」這邊的資料時看到這篇文章講到 Zing JVM 大幅降低了他們在 C10M 時遇到的 latency 問題：「Fast C10M: MigratoryData running on Zing JVM achieves near 1 Gbps messaging to 10 million concurrent users with 15 millisecond consistent latency」。
包括了平均值、99% 值、最大值都大幅下降：
In this post, we show that by simply replacing the JVM with Zing JVM out-of-the-box (without any tuning), and preserving the same C10M benchmark scenario and setup, we can reduce the average latency from 61 milliseconds to under 15 milliseconds. Moreover, and more importantly, the latency spikes can be significantly reduced from 585 milliseconds to 25 milliseconds for the 99th percentile latency and from 1700 milliseconds to 126 milliseconds for the maximum latency. Therefore, every single message can be delivered, even in the worst case, with almost no delay.
而且他們發現最高的 126ms 也不是 GC 造成的，而是 benchmark 這邊造成的：
And so, the relatively high latency spikes we saw in the previous C10M benchmark were due to JVM’s Garbage Collection (GC). In the new benchmark, not only Zing JVM didn’t introduce high latency spikes, but based on analyzing the logs, it appears that GC effects no longer dominate latency behavior. The dramatically improved 126 ms max latency is not caused by GC but by other condition of the benchmark setup. Anyway, this max latency was so small for a web architecture that we did not spend time to determine at which level exactly it occurred.
Zing 的價錢是一台 USD$8000/year，另外也有虛擬機版本 (另外報價)，如果遇到 JVM GC 問題，看起來會是個可以花錢解決問題的方案：
Zing® is priced on a subscription basis per server. With per-server pricing, you don’t need to worry about core counts, memory size, or number of instances deployed per server. The annualized subscription price for Zing per physical server ranges from $8000 (for a single license) to under $2000 (for orders above 1000 servers). Higher volumes and longer subscription terms will reduce the per-server price for Zing. Pricing for virtual servers is also available upon request.