Home » Posts tagged "cpu"

JavaScript Framework 不可避免的成本

看到「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.

EC2 推出 ARM 架構的機器...

看到 AWS 推出使用 ARM 架構的 EC2 instance 了:「New – EC2 Instances (A1) Powered by Arm-Based AWS Graviton Processors」。

在 Quick Start 頁面有 Ubuntu 18.04 (ARM) 可以選,開起來後操作跟標準的 Ubuntu 差不多... 連進去後 uname -a 可以看到是 aarch64:

ubuntu@ip-172-30-2-207:~$ uname -a
Linux ip-172-30-2-207 4.15.0-1028-aws #29+nutmeg8-Ubuntu SMP Tue Nov 20 02:59:41 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

然後來看硬體規格,從最大台的 a1.4xlarge 來看是 16 vCPU + 32 GB RAM,定價是 $0.408/hr (這邊都拿 us-east-1 比較)。

對照 General Purpose 的 m5.4xlarge 是 16 vCPU + 60 GB RAM,定價是 $0.768/hr。如果看記憶體比較接近的 m5.2xlarge 則是 8 vCPU + 31 GB RAM,定價是 $0.384/hr。

對照 Compute Optimized 的 c5.4xlarge 是 16 vCPU + 68 GB RAM,定價是 $0.68/hr。

實際跑一些測試,包括 md5、sha256 與 aes (最後 aes 這個通常都有硬體加速),都用 -mutli 16 跑。

ARM 的 a1.4xlarge

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5            1064103.21k  2484789.44k  4436178.60k  5521370.45k  5943380.65k  5963896.15k
sha256         2059690.93k  5652827.82k 11792656.30k 16108863.15k 18086602.36k 18250851.29k
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128 cbc    1593981.48k  1723960.38k  1752940.20k  1767321.94k  1770212.01k  1768281.43k
aes-192 cbc    1400010.40k  1496414.83k  1516962.99k  1527643.82k  1529834.15k  1527563.26k
aes-256 cbc    1222067.79k  1296972.50k  1313348.18k  1321350.83k  1322947.93k  1321850.20k
blowfish cbc   1384982.01k  1500548.63k  1529793.02k  1540091.22k  1540937.05k  1540767.74k

Intelm5.4xlarge

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5            1370869.17k  3276978.66k  5929591.13k  7441276.93k  8026330.45k  8071796.05k
sha256          592719.47k  1325135.04k  2506009.09k  3184234.50k  3455729.66k  3480365.74k
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128 cbc    1060996.96k  1121951.87k  1135376.21k  1141487.96k  1143270.06k  1143499.43k
aes-192 cbc     890438.97k   934047.98k   943446.44k   947576.49k   948857.51k   949026.82k
aes-256 cbc     768686.53k   800152.85k   806883.93k   809804.12k   810784.09k   810937.00k
blowfish cbc   1735490.97k  1884059.78k  1923876.10k  1932711.94k  1934477.99k  1928680.79k

Intel 的 c5.4xlarge

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5            1501870.92k  3593434.20k  6503591.25k  8162811.90k  8804605.95k  8855147.86k
sha256          650179.22k  1453635.18k  2749318.83k  3492912.13k  3791164.76k  3818105.51k
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128 cbc    1163898.98k  1230539.07k  1244414.63k  1252080.98k  1254110.55k  1254206.12k
aes-192 cbc     976610.23k  1024570.03k  1034886.66k  1039442.26k  1040872.79k  1041143.13k
aes-256 cbc     843184.42k   877695.30k   885125.46k   888408.06k   889503.74k   889766.83k
blowfish cbc   1877162.34k  2056925.74k  2107008.26k  2119893.67k  2121979.22k  2115720.53k

這些數字頗有趣的... 看起來 ARM 上面應該有對某些演算法加速,使得常見的情境會快很多。不過如果是其他應用的話看起來就會比較辛苦了... 目前就價錢來看未必有絕對的優勢,還是得看應用來決定。

Linux Kernel 4.20 修正了一卡車 Intel CPU bug,然後效能掉光了...

看到「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,不太能關... 加上自從 MeltdownSpectre 後,讓安全研究人員發現了全新的天地,之後應該只會愈來愈慘 :o

用 ESP8266 模擬 PC-XT...

看到拿 ESP8266 模擬 PC-XT,是個懷古時間:「IBM PC-XT Emulator on an ESP8266」。

現在小板子的 CPU 跟記憶體都比三十年前的桌機還要大了,直接在上面跑模擬器就算慢一點也已經不是問題了... 直接上麵包板接起來跑:

然後也可以跑 Windows 3.0:

純粹 hacking 的專案 XD

AWS 推出使用 AMD CPU 的 m5a 與 r5a

Amazon EC2 推出使用了 AMD Epyc 的機種,分別為 m5a.*r5a.*:「New Lower-Cost, AMD-Powered M5a and R5a EC2 Instances」。

這個系列的重點在於價位相較於 m5.*r5.* 大約低了 10% 的費用:

The newest EC2 instances are powered by custom AMD EPYC processors running at 2.5 GHz and are priced 10% lower than comparable instances.

目前開放的區域只有五區:

These instances are available now and you can start using them today in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Singapore) Regions in On-Demand, Spot, and Reserved Instance form.

然後在「Amazon EC2 Pricing」這頁已經可以看到價錢,但大概是某些非技術性的因素,可以發現沒有列出 ECU... 不過從沒有推出 c5a.* 系列大概可以猜測效能應該打不贏 c5.* 所以沒有打算推出對應的產品線?(不過也難說,等看看有沒有人測試出來吧...)

另外文章最後提到會有 t3a.* 的計畫,如果價錢會再比現在的 t3.* 低一些的話,看起來頗值得期待的:

PS – We are also working on T3a instances; stay tuned for more info!

Amazon Lightsail 試用兩天的心得...

前幾天在「Amazon Lightsail 降價...」這篇文章提到了 Lightsail 這波降價還蠻有競爭力的,但之前看過「Is the fact that Lightsail instances are just renamed T2 instances that run on CPU credits actually documented anywhere?」這篇,大概知道 Lightsail 後面其實就是 t2 系列的機器,只是在這次 t3 出來後的改版不知道有沒有順便一起改...

前幾天直接把 blog + wiki 整個搬過去看看。本來在 Vultr 的主機是 1GB RAM,就挑了對應的方案搬過去... 如果還是 t2 的話,應該就會是 t2.micro 的機器。

由於搬家前面一天都在弄各種環境,所以應該累積了不少 CPU credit,實際的情況還是要等 DNS 指過來超過一天後才會知道。在剛剛跑了一整天,把 CPU credit 吃差不多後確認了,應該還是 t2.micro,baseline 在 10% (被降速了):

這樣的話就維持在 Vultr 好了... CPU 資源看起來還是用超過了。

Amazon EC2 推出 T3 系列機器了...

Amazon EC2 推出新的 family type,T3 系列了:「Introducing Amazon EC2 T3 Instances」。

官方宣稱比 T2 系列的機器快 30%:

T3 instances also feature the latest 2.5 GHz Intel Xeon Scalable processors which combined with the AWS Nitro System result in up to a 30% better price to performance improvement over T2 instances.

另外 T3 低階系列的機器 (t3.nanot3.microt3.small) 都是 2 vCPU 了,而且「CPU credits earned per hour」是原來的兩倍,但 t3.mediumt3.large 就跟原來一樣了,而再更大台的 t3.xlarget3.2xlarge 又比較大了... (參考「CPU Credits and Baseline Performance」)

另外是價錢上的差異,T3 的單價反而比 T2 低了一些:以 us-east-1 來看,t3.nano 是 USD$0.0052/hr,而 t2.nano 則是 USD$0.0058/hr,大約是 10% 的差距。

Reserved Instance 也是類似的情況,t3.nano 是 USD$27/y 與 USD$51/3y,t2.nano 則是 USD$29/y 與 USD$57/3y。

這次發佈把台灣團隊常用的區域都納入了,包括了北美的 us-east-1 (北維吉尼亞)、us-west-2 (奧勒崗) 與亞洲的 ap-northeast-1 (東京)、ap-southeast-1 (新加坡):

Amazon EC2 T3 Instances are available immediately in the US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Canada (Central), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), Europe (London), and South America (Sao Paulo) AWS Regions.

現有的機器都可以考慮換過去了... 這也是買三年 RI 最好的時機了 XD

GCP 的 f1-micro 的使用心得...

這幾天在弄備援跳板機,不想弄在日本 (latency),所以就想到 Google Cloud Platform (GCP) 在台灣有機房,而 Compute Enginef1-micro,類似 AWSEC2 提供的 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 比 EBSgp2 便宜不少,而且還包括了 i/o 費用 (AWS 會另外收費)
  • 連續使用就會有 discount 了,也可以 commit 買一年或是三年取得更深的 discount。而 AWS 則是得買 Reserved Instance 拿到 discount。

來看看一個月會有多少帳單產生吧...

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

用 mrtgutils-sensors 直接產生出 MRTG 用的溫度數字...

因為想要做另外一台機器的溫度資料,所以去查了一下有沒有現成的工具可以直接組完...

首先是在「How do I get the CPU temperature?」這邊查到 lm-sensors 這個套件,可以拉出一堆溫度資料 (不只 CPU 的),然後另外在「MRTG using script to grab data of sensors」這邊有人提到 mrtgutils-sensors 這個套件,可以直接將 sensors 的輸出結果轉成 MRTG 要的值,不需要自己寫 script...

把做好的東西丟在 https://home.gslin.org/mrtg/ 這邊,這樣可以觀察機器情況...

Archives