幹壞事是進步最大的原動力
AWS 推出了 Amazon DynamoDB 的相容 Docker Image，讓開發者可以在本地端測試 DynamoDB 的 API：「Use Amazon DynamoDB Local More Easily with the New Docker Image」，在 amazon/dynamodb-local 這邊可以拉到，裡面其實是包 Java：
DynamoDB local is now available to download as a self-contained Docker image or a .jar file that can run on Microsoft Windows, Linux, macOS, and other platforms that support Java.
這樣在 Continuous Integration (CI) 的過程裡面也可以拉起 service 測試...
在 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