Tag: performance

Heimdall Data：自動 Cache RDBMS 資料增加效能

看到 AWS 的「Automating SQL Caching for Amazon ElastiCache and Amazon RDS」這篇裡面介紹了 Heimdall Data – SQL caching and performance optimization 這個產品。

從官網的介紹也可以看出來是另外疊一層 proxy，但自動幫你處理 cache invalidation 的問題：

But what makes Heimdall Data unique in industry is its auto-cache AND auto-invalidation capability. Our machine learning algorithms determine what queries to cache while invalidating to ensure maximum performance and data integrity.

看起來支援了四個蠻常見的 RDBMS：

Heimdall Data supports most all relational database (e.g. MySQL, Postgres, Amazon RDS, Oracle, SQL Server, MariaDB).

看起來是一個花錢直接買效能的方案... 不過 cache invalidation 的部分不知道要怎麼跨機器做，在 FAQ 沒看到 cluster 情況下會怎麼解決。

MySQL 8.0 的功能

之前陸陸續續寫了一些關於 MySQL 8.0 的新改善 (參考「MySQL 8.0 的 performance_schema 加上 index 了...」、「MySQL 8.0 將會實作「真正的」Descending Indexes」、「MySQL 8.0 對 4 bytes UTF-8 的效能改善」)，官方在 RC1 的時候整理了一篇出來：「MySQL 8.0 RC1 – Highlights」。

我覺得比較值得看的是「Better Handling of Hot Rows」、「Invisible Indexes」這兩個吧，前面這點對於效能可以有些幫助 (針對某些情境不要 waiting，直接 skip lock)，後面這點對於維運應該也有不錯的幫助 (像是拔掉 index 的過渡驗證階段)。

當 MySQL 8.0 真的出了之後，Percona 應該也會出文章，到時候可以看出從不同面向的觀察與想法...

Cloudflare 新推出的 Geo Key Manager

Cloudflare 對新推出的 Geo Key Manager 寫了兩篇文章說明：「Introducing the Cloudflare Geo Key Manager」、「Geo Key Manager: How It Works」。

這個服務是之前推出的 Keyless SSL 的延伸應用。

Keyless SSL 是將 Private Key 放在自己家，透過加密協定讓 Cloudflare 使用 (有點像是 HSM 的概念，也就是 Hardware security module，不讓應用的人存取到 Private Key)。這次推出的 Geo Key Manager 則是取中間值，希望針對效率與 High Availability 做出改善。

改善的方法還是將 Private Key 上傳到 Cloudflare 裡，但不是 Cloudflare 所有的機房，而是讓使用者挑選某些風險比較低的地區。

像是只放在美國，或是只放在歐盟，或是以安全度來選擇：

這其實是不信任政府單位而設計出來的系統，雖然效果如何還不知道...

Cloudflare 的 F-Root

Cloudflare 從三月底開始跟 ISC 簽約合作，服務 F-Root 這個 DNS Service (f.root-servers.net)：「Delivering Dot」。

Since March 30, 2017, Cloudflare has been providing DNS Anycast service as additional F-Root instances under contract with ISC (the F-Root operator).

在 Linode 東京的機器上面可以看出來 www.cloudflare.com 走的路徑跟 f.root-server.net 相同：

gslin@one [~] [22:49] mtr -4 --report www.cloudflare.com
Start: Tue Sep 12 22:49:29 2017
HOST: one.abpe.org                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 139.162.65.2               0.0%    10    0.6   0.6   0.5   0.6   0.0
  2.|-- 139.162.64.5               0.0%    10    2.0   1.1   0.6   2.5   0.5
  3.|-- 139.162.64.8               0.0%    10    0.7   1.0   0.7   2.1   0.3
  4.|-- 218.100.6.62               0.0%    10    0.8   0.8   0.8   1.0   0.0
  5.|-- 198.41.215.162             0.0%    10    0.7   0.7   0.7   0.8   0.0
gslin@one [~] [22:49] mtr -4 --report f.root-servers.net
Start: Tue Sep 12 22:49:46 2017
HOST: one.abpe.org                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 139.162.65.3               0.0%    10    0.5   0.6   0.5   0.6   0.0
  2.|-- 139.162.64.7               0.0%    10    0.7   0.7   0.6   0.8   0.0
  3.|-- 139.162.64.8               0.0%    10    0.7   0.7   0.6   0.8   0.0
  4.|-- 218.100.6.62               0.0%    10    0.8   0.8   0.8   0.8   0.0
  5.|-- f.root-servers.net         0.0%    10    0.8   0.8   0.7   0.8   0.0

而且也可以從監控發現，f.root-servers.net 的效能變好：

Using RIPE atlas probe measurements, we can see an immediate performance benefit to the F-Root server, from 8.24 median RTT to 4.24 median RTT.

DNS query 的量也大幅增加：

而且之後也會隨著 Cloudflare 的 PoP 增加而愈來愈快... 在原文的 comment 也提到了 Cloudflare 也有打算跟其他的 Root Server 合作，所以看起來會讓整個 infrastructure 愈來愈快而且穩定。

另外這也代表台灣在本島也會直接連到 F-Root 了，不過 HiNet 自己也有 F-Root，所以 HiNet 的部份就沒什麼差...

在 EC2 上使用 25Gbps 的網路

Amazon EC2 上許多系列最大台的機器現在都可以透過特殊界面跑到 25Gbps 了：「Announcing improved networking performance for Amazon EC2 instances」。

Amazon EC2 instances now provide a maximum bandwidth of 25 Gbps. This feature is available on the largest instance sizes of the M4, X1, P2, R4, I3, F1, and G3 instance types. Using Elastic Network Adapter (ENA) based Enhanced Networking, customers can utilize up to 25 Gbps of bandwidth.

除了 AWS 提供的的 AMI 外，另外在一些官方作業系統也都有支援：

ENA driver is installed in the latest Amazon Machine Images (AMIs) for the following operating systems: Amazon Linux, Ubuntu 14.04 and 16.04, RHEL 7.4, SLES 12, Windows Server 2008R2, 2012, 2012R2 and 2016. ENA Linux driver source code is also available on Github.com for developers to integrate in their AMIs.

如果不在上面的，也可以透過 GitHub 上的 amzn/amzn-drivers (Official repository of the Elastic Network Adapter (ENA) network adapter for Linux and FreeBSD operating systems) 自己 porting... (如果你一定要想辦法用的話)

InnoDB 與 MyRocks 之間的取捨

MyRocks 的主要作者 Mark Callaghan 整理了一篇關於大台機器下，資料可以放到記憶體內的效能比較：「In-memory sysbench, a larger server and contention - part 1」。

這其實才是一般會遇到的情況：當事業夠大時，直接花錢買 1TB RAM + 數片 PCI-E SSD 的機器用錢換效能... (主要應該會在記憶體花不少錢，剛剛查了一下，現在白牌的 server 一台大約七十萬就可以擺平？兩台做 HA 也才一百四十萬，對有這個規模的單位來說通常不是大問題...)

而三種不同的 case 裡面，最後這個應該是最接近真實情況的：

可以看到 InnoDB 在幾乎所有項目都還是超越 MyRocks (只有 random-points 與 insert-only 輸)。

不知道後續的開發能量還會有多少... (因為 Facebook 的用法跟一般情況不一樣)

Google Cloud Platform 的網路推出 Standard Tier 了

Google Cloud Platform (GCP) 的網路總算是推出 Standard Tier 了：「Introducing Network Service Tiers: Your cloud network, your way」。

之前 GCP 上的網路只有 Premium Tier，也就是封包從 GCP 的平台出來後一定要透過 Google 自己的網路，到離使用者最近的點後再送到使用者的電腦上... 這樣的好處是 Google 保證他們有很多備援線路，而且也確保 latency 夠低，但缺點就是服務提供者得付這些費用...

這次推出的 Standard Tier 就像其他雲端平台的作法，在 GCP 機房當地就跟網路業者交換，之後透過 Internet 傳到使用者的電腦上，這樣就會比較便宜：

With the new Network Tiers pricing (effective at GA), outbound traffic (GCP to internet) is priced 24-33% lower in Standard Tier than in Premium Tier for North America and Europe.

像是「其實我根本不在意美國以外的使用者」時，機房建在美國，但不會想要付 Premium Tier 的網路費用...

C++ 與組語的速度...

在 Hacker News Daily 上看到「Why is this C++ code faster than my hand-written assembly for testing the Collatz conjecture?」覺得很有趣...

作者寫了一段 assembly，但跑起來比用 C++ 同義的版本慢多了。目前最高分的答案給了很清楚的解釋...

even:
    mov rbx, 2
    xor rdx, rdx
    div rbx

上面這段 code 是作者寫的組語版本，用到 div 指令，這是非常慢的指令：

On Intel Haswell, div r64 is 36 uops, with a latency of 32-96 cycles, and a throughput of one per 21-74 cycles.

相較於 C++ 的版本，用到的是 shr (logical shift right，以位元方式往右平移，最高位補零)，速度快太多：

shr rax, 1 does the same unsigned division: It's 1 uop, with 1c latency, and can run 2 per clock cycle.

這是用到無號整數透過 shr 平移一格剛好是除以二的特性，因為速度的關係，這個用法到現在還是很常被拿來用，但對於平常沒在寫 assembly 的人就會有上面的誤解 XDDD

PS4 下載速度很慢的原因

在「Why PS4 downloads are so slow」這篇作者花了不少力氣找出原因，發現 PS4 下載速度很慢是故意的... 另外討論了在什麼情況下會變慢，以及要怎麼避免的方式。

懶得看的人可以直接看 Conculsions 那段，主要的原因是 PS4 會因為背景程式而調整 TCP window size (就算背景程式在 idle 也會影響到下載的 TCP window size)，進而影響速度：

If any applications are running, the PS4 appears to change the settings for PSN store downloads, artificially restricting their speed. Closing the other applications will remove the limit.

用 TCP window size 來調整速度也算是頗有「創意」的方法...

Anyway，遇到時的解決方法就是把所有在跑的程式都完整關掉，再下載就會正常多了...

Quotient filter

之前有提過「Cuckoo Filter：比 Bloom Filter 多了 Delete」，最近在「A general purpose counting filter: making every bit count」這邊看到 Quotient filter，也是類似 Bloom filter 的資料結構，但想要解決更多問題。

一般的 Bloom filter (BF) 會有這些問題：

  • The inability to delete items
  • Poor scaling out of RAM
  • The inability to resize dynamically
  • The inability to count the number of occurrences of each item, especially with skewed input distributions.

而文章裡提到的 Quotient filter (QF) 就是要解這些問題。另外還提到了 Rank-and-Select-based Quotient filter (RSQF) 以及 Counting Quotient filter (CQF)。雖然多了一些空間需求，但看起來解掉不少問題... (尤其是刪除的能力)

效能上也還不錯，尤其是讀取速度的部份... 不過不知道相對於 Cuckoo filter 差多少。