AWS 宣佈 CloudFront 在非洲的第一個節點開在南非的約翰尼斯堡 (Johannesburg)：「Amazon CloudFront Expands into Africa with new Edge Location in Johannesburg and first Edge Location in Bangalore」。
這樣各大洲都有點了...
GCP 的 f1-micro 的使用心得...
這幾天在弄備援跳板機，不想弄在日本 (latency)，所以就想到 Google Cloud Platform (GCP) 在台灣有機房，而 Compute Engine 有 f1-micro，類似 AWS 裡 EC2 提供的 t2.nano 的機器。而這兩天玩了玩，大概有些事情值得記錄起來。
CPU 相關的部份：
- EC2 的
t2系列可以透過 API 或是在 web console 看到 CPU credit 剩下多少，GCE 沒找到在哪邊可以看。 - EC2 的
t2系列在 CPU credit 用完後是變慢運行，除非你打開 T2 Unlimited 同意 AWS 多收錢。而 GCE 的則是沒得選，相當於一定要開 T2 Unlimited。 - GCE 的
f1-micro是 0.2 vCPU，但我在上面跑 Ubuntu 18.04，平常沒事就已經是 15% 左右。這數字比預期的高不少，還在找是什麼原因...
網路相關的部份：
- 因為要用台灣的機房，網路的部份只有 Premium 等級可以選 (Standard 等級目前只在美國有)，也就是會先走 Google 佈建的網路再出去，所以流出的費用會隨著 destination 地區而有差異 (i.e. 封包送到美國與送到中國是不同計價)。
- 但 Premium 等級實測品質真的很不一樣，到香港居然在 15ms 以下，以前在固網機房內沒看過這個數字...
其他的部份：
- 硬碟空間方面，Standard provisioned space 比 EBS 的
gp2便宜不少，而且還包括了 i/o 費用 (AWS 會另外收費)。 - 連續使用就會有 discount 了，也可以 commit 買一年或是三年取得更深的 discount。而 AWS 則是得買 Reserved Instance 拿到 discount。
來看看一個月會有多少帳單產生吧...
AWS 大阪區需要另外申請...
先前提到 AWS 大阪區的消息 (「AWS 大阪區」)，剛剛想看看進度，翻資料的時候才發現要另外申請：「【 AWS 新リージョン】 AWS 大阪ローカルリージョンが本日より利用可能になりました」。
なお、 AWS 大阪ローカルリージョンをご利用いただくためには、申し込みおよび審査が必要です。
好吧 XDDD
MySQL 裡 performance_schema 對效能的影響
最近在弄 MySQL 的 perforemance_schema，開起來後發現效能影響沒有很大，跟印象中不太一樣... 找了一下文章發現 Percona 在 2017 年年初時有針對效能測試過：「Performance Schema Benchmarks: OLTP RW」。重點在這張圖：
圖上可以看到 Default 其實對效能的影響有限，另外文章也整理出來，有哪些設定對效能影響不會太大，可以考慮平常就開著：
Using Performance Schema with the default options, Memory, Metadata Locks and Statements instrumentation doesn’t have a great impact on read-write workload performance. You might notice slowdowns with Stages instrumentation after reaching 32 actively running parallel connections. The real performance killer is Waits instrumentation. And even with it on, you will start to notice a performance drop only after 10,000 transactions per second.
HiNet 與 DigitalOcean、Linode、Vultr 的封包情況
先說結論，綜合網路與 CPU 的情況，我剛好跟下面提到的文章給出相反的選擇 (i.e. 完全不會選 DigitalOcean)。如果是需要 latency 低的品質我會選 Linode 的東京新機房 Tokyo 2，如果不需要 latency 的我會選 Vultr 的 USD$2.5/month 方案 (目前只在邁阿密與紐約有)。
看到「2018/06 台灣 5USD 虛擬主機網路延遲測試」這篇就來推廣一下 SmokePing 這個工具。這個工具可以做很多事情，但最常看到的用途還是做網路品質監控，先前在 K 社的時候就有個做個公開的站台可以看，後來接手的人也繼續維護著 (畢竟看這些圖有種治癒感？)：「smokeping.kkbox.com.tw」。
不過 K 社的 SmokePing 裡面大多數是從固網機房端監控，而固網機房端的 Internet 品質一般來說都會比家用型的好很多，尤其是國際頻寬的部份。所以我也在我家裡用 PPPoE 版本的固定 IP 做了一份：「https://home.gslin.org/smokeping/」，這邊的設定檔放在 GitHub 上的 gslin/smokeping-config.d 上。
而我剛好有把這三家 VPS 的 SmokePing 都做起來：「SmokePing Latency Page for DigitalOcean」、「SmokePing Latency Page for Linode」、「SmokePing Latency Page for Vultr」。
我這邊看到的情況是這樣。以各家離台灣最近的點來看：
- 第一張圖的 DigitalOcean 沒有東京的點，而新加坡的 latency 在這幾個月其實變差不少，現在大約要 90ms (扣掉光世代的 10ms)。
- 第二跟第三張圖的 Linode (分別是 Tokyo 1 與 Tokyo 2) 其實可以看到新機房 Tokyo 2 的 latency 比舊機房 Tokyo 1 還好。
- 第四張圖的 Vultr 則是狀況變化很多，但不管怎麼走，latency 大致上都還是比新加坡好。
另外第五張的 Vultr 則是紐約的點，latency 超高 (畢竟繞了半個地球)，但 packet loss 不高，品質還算穩定。
speedtest-sgp1.digitalocean.com (DigitalOcean Singapore 1)
speedtest.tokyo.linode.com (Linode Tokyo)
speedtest.tokyo2.linode.com (Linode Tokyo 2)
hnd-jp-ping.vultr.com
nj-us-ping.vultr.com
另外是之前有痛到的部份，先前因為需求而需要在 PHP 5.6 上跑 WordPress，真的實際跑起來後發現超慢 (畢竟這兩個要快得想不少辦法)，去找問題後發現 DigitalOcean 機器的 CPU 真的太慢，後來把這組需求搬去 Linode (在 CPU 與網路之間取個合理的平衡點)。
在各家 VPS 上用 Ubuntu 16.04 跑 openssl speed md5 可以看出一些資料：
DigitalOcean：
Doing md5 for 3s on 16 size blocks: 5465798 md5's in 3.00s Doing md5 for 3s on 64 size blocks: 3761125 md5's in 3.00s Doing md5 for 3s on 256 size blocks: 1835218 md5's in 2.99s Doing md5 for 3s on 1024 size blocks: 582162 md5's in 2.96s Doing md5 for 3s on 8192 size blocks: 102995 md5's in 2.97s Doing md5 for 3s on 16384 size blocks: 47177 md5's in 2.99s
Linode：
Doing md5 for 3s on 16 size blocks: 11510700 md5's in 3.00s Doing md5 for 3s on 64 size blocks: 8361353 md5's in 2.99s Doing md5 for 3s on 256 size blocks: 3751929 md5's in 3.00s Doing md5 for 3s on 1024 size blocks: 1169457 md5's in 3.00s Doing md5 for 3s on 8192 size blocks: 157678 md5's in 2.99s Doing md5 for 3s on 16384 size blocks: 78874 md5's in 3.00s
Vultr (這是 USD$2.5/month 的方案)：
Doing md5 for 3s on 16 size blocks: 14929209 md5's in 2.97s Doing md5 for 3s on 64 size blocks: 9479563 md5's in 2.97s Doing md5 for 3s on 256 size blocks: 4237907 md5's in 2.98s Doing md5 for 3s on 1024 size blocks: 1320548 md5's in 2.98s Doing md5 for 3s on 8192 size blocks: 161940 md5's in 2.96s Doing md5 for 3s on 16384 size blocks: 86592 md5's in 2.98s
然後補一個 AWS 的 t2.nano (在還有 CPU credit 可以全速跑的情況下)，不過這不公平，參考用而已：
Doing md5 for 3s on 16 size blocks: 19257426 md5's in 3.00s Doing md5 for 3s on 64 size blocks: 11168752 md5's in 2.99s Doing md5 for 3s on 256 size blocks: 4959879 md5's in 3.00s Doing md5 for 3s on 1024 size blocks: 1518690 md5's in 3.00s Doing md5 for 3s on 8192 size blocks: 203910 md5's in 3.00s Doing md5 for 3s on 16384 size blocks: 102321 md5's in 2.99s
Trac 關票時的資訊...
Trac 關票時一般都是由開票的人關 (i.e. Reporter)，今天遇到的情況是這樣，在關票時的畫面上你會不知道是誰開的：
只要往上一點拉就會看到 Reporter 資訊 XD 這通常會發生在螢幕沒打直的人，直接拉到最下方的情況 XD
試著用 CSS 的 position: sticky 但抓不太到要的效果，決定還是開 jQuery 下去解決 XD
// Copy reporter information to action section
if ($('#action_resolve_resolve_resolution').length > 0) {
var reporter = $('#h_reporter').parent().find('.trac-author, .trac-author-user')[0].outerHTML;
$('#action_resolve_resolve_resolution').each(function(){
$(this).parent().append('<span class="hint">(This ticket is created by ' + reporter + ')');
});
}當下寫得很隨性，之後也許會再改... (會更新到「Trac - Gea-Suan Lin's Wiki」這邊)
Facebook 觀察 IPv6 的使用情況
Facebook 是在六年前啟用了 IPv6 服務，然後分析了現在各地區 IPv6 使用的情況：「How IPv6 deployment is growing in U.S. and other countries」，另外提供了統計系統的資料給大家查 (不過看起來只有二月以後的？)：「Facebook IPv6」。
然後被提到台灣區的成長在這幾個月很快速，主要原因是中華電信的導入：
We are also seeing countries and regions with less mature internet infrastructure start to transition to IPv6. Although overall deployment is still low, recent growth in some places has been exponential. Taiwan, for example, has gone from less than 1 percent in February 2018 to more than 10 percent as of May 28, 2018. Taiwan's rapid growth directly corresponds to recent IPv6 initiatives by Chunghwa, Taiwan's largest ISP.
先前在 Twitter 上有提到中華在 www.ipv6.hinet.net 網站上的跑馬燈有公告關於 IPv6 的導入，所以到這個月月底，使用比率應該都還會有明顯的提昇：
在 https://t.co/bK8ZATMeYm 看到：「HiNet光世代非固定制全面啟動雙IP(IPv4/IPv6)服務，新客戶申請時即提供雙IP，老客戶將陸續改設雙IP，預定6月系統全部設定完成。」
— Gea-Suan Lin (@gslin) May 13, 2018
因為 Windows 7 以上的系統直接 PPPoE 的應該都會拿到 IPv6 address，但如果是 IP 分享器的就不一定支援了，不然應該會更高...
另外行動網路的部份也陸陸續續在轉移了，像我的 blog 上可以看到有 emome-ip6.hinet.net 的訪客，而且 Google 搜尋也可以看到一些資訊了：「"emome-ip6.hinet.net" - Google 搜尋」。
Cloudflare 提供的 DNS Resolver 服務拓展到 Tor 上
Cloudflare 宣佈 DNS Resolver 提供 Tor 的版本，讓使用者可以在不暴露自己的 IP address 的情況下，使用 Cloudflare 提供的 DNS Resolver 服務：「Introducing DNS Resolver for Tor」。
不過沒看懂，如果使用者想要透過 Tor 保護自己的話，本來就可以透過 Tor 存取 1.1.1.1 與 1.0.0.1 甚至是其他家有提供 DNS-over-TLS 或是 DNS-over-HTTPS 的服務了？(像是 Google 的 8.8.8.8)
好像找不到什麼使用的理由...
Amazon EC2 補產品線：M5 也有 NVMe 的 SSD local disk 可以用了
Amazon EC2 對 M5 instance 推出了帶 NVMe SSD 的版本：「EC2 Instance Update – M5 Instances with Local NVMe Storage (M5d)」。先推出歐美的區域：
M5d instances are available in On-Demand, Reserved Instance, and Spot form in the US East (N. Virginia), US West (Oregon), EU (Ireland), US East (Ohio), and Canada (Central) Regions. Prices vary by Region, and are just a bit higher than for the equivalent M5 instances.
算是 M3 系列的後繼產品？對應到四年前推出的 m3.medium 是 1 vCPU、3.75GB RAM 以及 8GB SSD (不過 m3.large 就變成 2 vCPU、7.5GB RAM 與 32GB SSD，硬碟的部份多了不少)。
這樣 M5 就更全面了...
在 Ubuntu 18.04 (Bionic) 上跑 Percona Server 5.7
在 Percona 的文件「Installing Percona Server on Debian and Ubuntu」這邊雖然還沒列 Ubuntu 18.04 上去，但已經有東西在裡面可以安裝了。不過還是屬於官方未正式支援的情況，用的時候自己要注意。
另外查資料的時候有看到「Ubuntu 18.04 (bionic) - percona-xtradb-cluster-server installation break」這篇提到 Percona XtraDB Cluster 裝不起來，但有 workaround 可以硬裝進去，要玩的人也可以參考一下 XD
這樣可以把 14.04 機器換一換了。(先前清點時本來以為已經是 16.04，做一些操作時才發現是 14.04...)