幹壞事是進步最大的原動力
這篇整理了 HTTP/3 (QUIC) 的反面看法，算是常見的疑慮都列出來了：「QUIC and HTTP/3 : Too big to fail?!」。
其實大多都是使用 UDP 而導致的問題：
整篇文章算是整理了一般對 HTTP/3 的疑慮，之後如果有進展的話，可以再拿出來當 checklist 再確認有哪些有改善...
AWS 開始陸陸續續在推出有 100Gbps 能力的 EC2 instance 了：「New – EC2 P3dn GPU Instances with 100 Gbps Networking & Local NVMe Storage for Faster Machine Learning + P3 Price Reduction」。
從「Amazon EC2 Instance Types」這邊可以看到先前只有 c5n.18xlarge 有支援 100Gbps 網路，現在推出的 p3dn.24xlarge 是第二個支援的...
另外是 P3 系列的降價消息，比較奇怪的是從 2018/12/06 開始生效，而不是從月初開始。另外區域與條件也有一些複雜，有常在用的人可以翻一下說明...
AWS 宣佈提昇了 Amazon EBS (gp2) 的效能：「Amazon EBS Increases Performance of General Purpose SSD (gp2) Volumes」。
本來上限是 10k IOPS，現在提升到 16k IOPS 了。另外最大傳輸速度也從 160 MB/sec 提升到 250 MB/sec：
Today we are announcing a 60% improvement in performance of General Purpose SSD (gp2) Volumes from 10,000 IOPS to 16,000 IOPS and from 160 MB/s to 250 MB/s of throughput per volume.
應該還是維持 3 IOPS per GB 的設計，但這對於想要用 gp2 堆效能的人來說算是好消息，可以用更大的空間堆出更多 IOPS 了... (像是「Percona 的人接受 AWS 的建議，重新測試了 Percona XtraDB Cluster 在 gp2 上的效能...」這篇)
看到「The Baseline Costs of JavaScript Frameworks」這篇文章在研究目前主流 JavaScript Framework 無法避免的成本到底有多高。
文章的結論是目前常見的 JavaScript Framework 其實都很肥重，在網路速度不快的地方得花不少時間下載，在非旗艦的手機上會需要花不少時間處理 (parse & compile)。
這是 gzip 後的大小：
這是 parse & compile 的時間：
這是下載時間 (扣除 latency 與 TLS connection 建立時間)：
並不是說不能用，但重點會在客群：
But it’s important to consider your audience. If you’re building for resource constrained devices — which you certainly are if your product targets a country like India — you could consider using a lighter framework such as Riot or Preact. Your users will thank you.
最後有建議如果只是要呈現資訊，不要用整套 JavaScript Framework，在有需要互動的地方另外寫就好了：
For websites that primarily display content, it’s more efficient and cost-effective to just send some server-rendered HTML down the wire. If there are areas of your website that require interactivity, you can always use JavaScript to build those specific parts.
看到「Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower」這篇測試了目前還在 RC 的 4.20.0，可以看到 AMD 的效能沒有太大影響，但 Intel i9 的效能掉了很嚴重：
從說明可以看到有測出 30%～50%：
This ranged from Rodinia scientific OpenMP tests taking 30% longer to Java-based DaCapo tests taking up to ~50% more time to complete to code compilation tests taking measurably longer to lower PostgreSQL database server performance to longer Blender3D rendering times.
另外在其他 Intel CPU 上測試也發現不是只有 i9 有影響，低階的機器也是：
Those affected systems weren't high-end HEDT boxes but included a low-end Core i3 7100 as well as a Xeon E5 v3 and Core i7 systems.
透過 bisect 有找到是哪個 commit 造成的：
That change is "STIBP" for cross-hyperthread Spectre mitigation on Intel processors. STIBP is the Single Thread Indirect Branch Predictors (STIBP) allows for preventing cross-hyperthread control of decisions that are made by indirect branch predictors.
但這又是屬於 security patch，不太能關... 加上自從 Meltdown 與 Spectre 後，讓安全研究人員發現了全新的天地，之後應該只會愈來愈慘 :o
看到「sr.ht, the hacker's forge, now open for public alpha」這篇，講 sr.ht 這個 Git Hosting。
文章裡面有提到，目前大多數的 Git Hosting 都很像，不管是 Bitbucket、GitLab、其實大家都是抄 GitHub 的界面與功能抄得很開心...
sr.ht 則是從不同的角度來設計 Git Hosting，避免了大量 js 的界面，但還是提供了很豐富的功能 (支援 markdown 文件、CI、透過 mailing list 討論、有一個 ticket system 可以放各種事項、wiki、...)。
其實還是支援了現在 Git Hosting 常見的功能，只是功能與界面上不太相同而已 XD
最近換到 Firefox 後覺得開很多 tab 時很卡，但 CPU 也沒滿，大概是某種 lock/mutex/semaphore 機制導致硬體資源沒用完但是自己限制住...
找資料研究的時候發現 Firefox 對單一 server 的最大連線數是 6 個，而 Chrome 是 10 個：「Max parallel http connections in a browser?」。這對於網路速度夠的使用者就很卡，像是透過 RSS reader 同時對一個站台狂開分頁時就會卡住。
翻了一下 Firefox 的設定，找到相關的幾個設定，其中上面提到的是 network.http.max-persistent-connections-per-server，預設的確是 6 個，改成 10 個後測了一天好不少，決定改成跟 IE11 一樣的 13 個... (奇怪的數字)
另外一個是 network.http.max-connections，預設是 900 了，應該夠用...
Cloudflare 決定支援 QUIC 了：「Get a head start with QUIC」、「The QUICening」。
QUIC 目前被使用的範圍比較小 (相較於 HTTP/2)：
而 Google Chrome 上面可以安裝「HTTP/2 and SPDY indicator」看到連線的狀態。雖然套件名稱沒有 QUIC，但實際上是可以看出 QUIC 的，基本上 Google 的服務應該都是走 QUIC。
Amazon Aurora 推出了 Parallel Query，可以加速計算速度：「New – Parallel Query for Amazon Aurora」。原理是利用 Aurora 把 storage 層打散的前提，所以有機會透過螞蟻雄兵處理：
官方給的範例可以連到原文去看，可以看到有打開 aurora_pq 與沒打開的效能差異：
15 rows in set (1 min 53.36 sec)
15 rows in set (1 hour 25 min 51.89 sec)
打開後大約是原來的 1/45 時間，提昇超多...
不過還是有些限制，我最在意的就是目前只支援相容於 MySQL 5.6 的版本 (居然不是先支援 5.7)：
Engine Support – We are launching with support for MySQL 5.6, and are working on support for MySQL 5.7 and PostgreSQL.
然後沒有多餘費用，只是 i/o cost 可能會增加：
Cost – You can make use of Parallel Query at no extra charge. However, because it makes direct access to storage, there is a possibility that your IO cost will increase.
看到「Serverless: Cold Start War」這篇分析了 AWS Lambda、Azure Functions 與 Google Cloud Functions 的冷啟動特性。
裡面分析了多久沒有 request 會需要冷啟動、記憶體的大小對於冷啟動速度的影響、程式語言的影響，以及程式大小的影響。
對於量很少，但是又很在意速度的人來說也許可以研究一下。不過只要有點量 (就算一分鐘只有一次) 應該都不會遇到這塊問題...