Home » Posts tagged "latency"

AWS Media Services 推出一卡車與影音相關的服務...

AWS 推出了一連串 AWS Elemental MediaOOXX 一連串影音相關的服務:「AWS Media Services – Process, Store, and Monetize Cloud-Based Video」。

但不是所有的服務都是相同的區域... 公告分別在:

不過這邊還是引用 Jeff Barr 文章裡的說明,可以看到從很源頭的 transencoding 到 DRM,以及 Live 格式,到後續的檔案儲存及後製 (像是上廣告) 都有:

AWS Elemental MediaConvert – File-based transcoding for OTT, broadcast, or archiving, with support for a long list of formats and codecs. Features include multi-channel audio, graphic overlays, closed captioning, and several DRM options.

AWS Elemental MediaLive – Live encoding to deliver video streams in real time to both televisions and multiscreen devices. Allows you to deploy highly reliable live channels in minutes, with full control over encoding parameters. It supports ad insertion, multi-channel audio, graphic overlays, and closed captioning.

AWS Elemental MediaPackage – Video origination and just-in-time packaging. Starting from a single input, produces output for multiple devices representing a long list of current and legacy formats. Supports multiple monetization models, time-shifted live streaming, ad insertion, DRM, and blackout management.

AWS Elemental MediaStore – Media-optimized storage that enables high performance and low latency applications such as live streaming, while taking advantage of the scale and durability of Amazon Simple Storage Service (S3).

AWS Elemental MediaTailor – Monetization service that supports ad serving and server-side ad insertion, a broad range of devices, transcoding, and accurate reporting of server-side and client-side ad insertion.

引個前同事的 tweet,先不說 Amazon SWF 的情況 (畢竟 Amazon SWF 還可以找到其他用途),倒是 Amazon Elastic Transcoder 很明顯要被淘汰掉了:

這種整個大包的東西是 AWS re:Invent 才有的能量,平常比較少看到...

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 的部份就沒什麼差...

用 Machine Learning 調校資料庫

AWS AI Blog 在月初上放出來的消息:「Tuning Your DBMS Automatically with Machine Learning」。

Carnegie Mellon Database Group 做的研究,除了預設值以外,另外跟四種不同的參數做比較,分別是 OtterTune (也就是這次的研究)、Tuning script (對於不熟資料庫的人,常用的 open source 工具)、DBA 手動調整,以及 RDS

MySQL

PostgreSQL

比較明顯的結論是:

  • Default 值在所有的 case 下都是最差的 (無論是 MySQL 與 PostgreSQL 平台,以及包括 99% 的 Latency 與 QPS,這樣二乘二的四個結果)。而且 Default 跑出來的數字與其他的差距都很明顯。
  • OtterTune 在所有 case 下跑出來都比 Tuning script 的好。這也是合理的結果,本來就是想要取代其他機器跑出來的結果。

至於有些討論 DBA 會失業的事情,我是樂見其成啦... 這些繁瑣的事情可以自動化就想交給自動化吧 XD

Google 研發出的 BBR: Congestion-Based Congestion Control

Google 針對 TCP 的 congestion control 研究出了新的方法,是個純 sender-side 的演匴法,可以讓現有的 internet 直接換上去使用:「[net-next,14/14] tcp_bbr: add BBR congestion control」。

在 long-lived TCP connection 愈來愈普及後 (像是 HTTP/2),TCP 連線的最佳化可以用統計模型來計算,這也就是 BBR 的想法:

In a nutshell, BBR creates an explicit model of the network pipe by sequentially probing the bottleneck bandwidth and RTT. On the arrival of each ACK, BBR derives the current delivery rate of the last round trip, and feeds it through a windowed max-filter to estimate the bottleneck bandwidth. Conversely it uses a windowed min-filter to estimate the round trip propagation delay. The max-filtered bandwidth and min-filtered RTT estimates form BBR's model of the network pipe.

不過 QUIC 不是也開始有進展了嗎?(參考「Google Chrome 52 預設開啟了更快的 QUIC (被戲稱為 TCP/2)」這篇)

感覺 QUIC 解決的比較徹底,不過 443/udp 的 firewall 問題的確也是個需要時間解決的課題...

CloudFlare 總算記得要加美國的點了...

CloudFlare 一直加海外的點,在東南亞加到平均 latency 比美國低... 這有點不太像話 XD 總算是記得要加強美國的 latency 了:「Hello, Colorado! CloudFlare's 82nd Data Center is Live in Denver」。

這次加在丹佛剛好是目前美國的點裡面最弱的一環:先前離 CloudFlare 最近的機房應該是 Phoenix 或是 Dallas,都大約在 600km 左右,latency,而網路也不會直線連接,所以這次加上去後的改善很明顯:

而也宣佈了美國的大幅擴建計畫:

Denver joins CloudFlare's existing United States data centers in Ashburn, Chicago, Dallas, Los Angeles, Miami, Minneapolis, Phoenix, San Jose, and Seattle. In the continued pursuit of faster performance, we have data centers at another ten North American cities in the works.

另外這個禮拜還預定要再宣佈一個新的點:

Our week of expansion isn't done. Tomorrow, we head to one of the world's largest cities.

Google DNS 在台灣的 Latency 大幅降低

對 8.8.8.8 的 ICMP 數據可以發現今天早上 Google 台灣機房的 DNS Service 做了改變,整個 latency 大幅降低。(因為 mtr 發現後面 traceroute 不到以為爆炸了,跑去看 Smokeping 發現其實是 Google 改善了架構)

中華電信北區的機房:

中華電信南區的機房:

台固機房:(內湖)

遠傳機房:(忘記是內湖的哪個機房了...)

遊戲橘子機房:(台北區)

Dropbox 從 SPDY 切換到 HTTP/2 發現的現象

Dropbox 將本來的 SPDY 切換到 HTTP/2 後整理了不少資料:「Enabling HTTP/2 for Dropbox web services: experiences and observations」。

大多數都是效能的改善,但「Increased latency for POST requests.」這段頗有趣的,找出了 nginx 的 bug:

POST 的 latency 大約增加了 50%,而實際追蹤問題發現是 nginx 中 SETTINGS_INITIAL_WINDOW_SIZE 預設值的問題,然後提出 patch 改善:「[nginx] HTTP/2: rewritten handling of request body.」:

There is a small issue with setting `SETTINGS_INITIAL_WINDOW_SIZE` to 0: now when client tries to POST data it needs to wait for an additional RTT(between `send HEADERS` and `recv WINDOW_UPDATE`) to start sending data.

Amazon S3 推出加速功能

Amazon S3 推出了新的加速功能,並且向更多地區提供 AWS Import/Export Snowball 服務:「AWS Storage Update – Amazon S3 Transfer Acceleration + Larger Snowballs in More Regions」。

其中的 Amazon S3 Transfer Acceleration 只要把本來的 BUCKET_NAME.s3.amazonaws.com 或是帶有地區的 BUCKET_NAME.s3-region.amazonaws.com 變成 BUCKET_NAME.s3-accelerate.amazonaws.com 就可以了,他會透過 CloudFront 的節點做 proxy,並且透過 AWS 內部最佳化過的網路傳輸。

由於這是定位為 Amazon S3 的服務,而實際測試後也確認不會有 cache:他的目的在於降低 latency 而加速,而不是 cache 加速,所以大量 GET 相同內容的部份應該還是用 CloudFront 會比較好。

再來是費用的部份增加相當多,第一筆要收的是 CloudFront 的費用,再來才是計算 Transfer Acceleration 的費用:

Transfer Acceleration pricing is in addition to Data Transfer pricing.

從 Internet 進 CloudFront 再進 Amazon S3 的要收 USD$0.04/GB (透過在美國、歐洲或是日本的 CloudFront 節點) 或 USD$0.08/GB (透過其他 CloudFront 節點)。

另外要收的是從 Amazon S3 一路傳到 Internet 的部份,USD$0.04/GB。如果是傳到其他 AWS region 的話,也是 USD$0.04/GB。

不過他有效能保證條款 (雖然掌控全不在自己),AWS 會持續監控有沒有比較快,如果沒有的話系統會 bypass 回原來的 Amazon S3:

Each time you use Transfer Acceleration to upload an object, we will check whether Transfer Acceleration is likely to be faster than a regular Amazon S3 transfer. If we determine that Transfer Acceleration is not likely to be faster than a regular Amazon S3 transfer of the same object to the same destination AWS region, we will not charge for that use of Transfer Acceleration for that transfer, and may bypass the Transfer Acceleration system for that upload.

我本來以為會是在 DNS 層 bypass 回本來的 region,結果發現是 307 redirect 重導回 Amazon S3 上,效能上應該還是會差一些...

可以看出這個架構的特性主要還是用在上傳的部份,而且用在網路不穩定的環境下很重要 (像是電信網路上的行動裝置),因為 latency 的減少會對於 packet loss 造成的 retry 有很大的幫助。

下載的部份應該會比本來 Amazon S3 快 (因為 Amazon 本身會加速),但由於沒有 cache,除非有特殊需求,不然建議不要這樣規劃。

另外一個是 AWS Import/Export Snowball 推出的新硬體,以及新區域。

新硬體是 80TB 的版本,本來只有 50TB 的版本:

The original Snowball appliances had a capacity of 50 terabytes. Today we are launching a newer appliance with 80 terabytes of capacity.

而新區域包括了 AWS GovCloud (US)、US West (Northern California)、Europe (Ireland) 以及 Asia Pacific (Sydney) 這三區:

Today we are making Snowball available in four new Regions: AWS GovCloud (US), US West (Northern California), Europe (Ireland), and Asia Pacific (Sydney). We expect to make Snowball available in the remaining AWS Regions in the coming year.

其中 80TB 版本只在這三區生效,其他區可以選擇 50TB 或是 80TB 版本:

If you are transferring data in or out of the US East (Northern Virginia), US West (Oregon), US West (Northern California), or AWS GovCloud (US) Regions using Snowball you can choose the desired capacity. If you are transferring data in or out of the Europe (Ireland) or Asia Pacific (Sydney) Regions, you will use the 80 terabyte appliance.

日本還是沒進場...

Archives