Home » Posts tagged "resource"

nginx 的 HTTP/2 要支援 Server Push 了

Twitter 上看到 nginx 的 HTTP/2 也要支援 server push 的消息了:

看起來是只要送出對應的 HTTP Header,後續 nginx 就會幫你處理...

這功能總算是要進 nginx 了... 像是透過 cookie 判斷使用者是第一次瀏覽,就透過 server push 預先把 css/js 丟出去,加速頁面呈現。

CPU 成為現代網站的速度瓶頸

在「Tracking CPU with Long Tasks API」這邊提到的現象,雖然是在提新的 API,不過裡面提到了很重要的問題。

以前的網站因為 js 都沒有用的那麼多,所以主要的瓶頸在於網路速度。所以大家最佳化的方向都是往「如何讓傳輸量變小」的方式進行,像是各類 js 的 minify,甚至是對 Gzip 演算法的暴力改善 (維持相容的 Zopfli,以及新的 Brotli):

In the old days, delivering a fast user experience depended primarily on download speed. One reason why the network was the main bottleneck back then is that JavaScript and CSS weren’t used as much as they are now, so CPU wasn’t a critical factor.

而現代網站使用 js 的情況已經是來到了新的境界 (甚至很多網站是沒有 js 就不會動),於是對於 CPU 的能力就愈來愈要求:

According to the HTTP Archive, the top 1000 websites download five times more JavaScript today compared to seven years ago.

而手機也愈來愈普及,CPU 的能力相較起來就更嚴峻了...

Amazon EC2 推出 T2 Unlimited,可以付費超量使用 CPU

Amazon EC2t2 系列的機器上推出 T2 Unlimited:「T2 Unlimited – Going Beyond the Burst with High Performance」。

這不是新的機種,而是現有的機器上可以超量使用 CPU credit,AWS 會另外收費。

新開的機器與已經開的機器都可以打開:

us-east-1 來算,其實相當便宜,看不出什麼 penalty fee:t2.micro 的 CPU credit 是 10% baseline,每小時單價是 $0.0116,所以先有個 100% 數字是 $0.116 的概念 (如果所有東西都是十倍)。

us-east-1 的 T2 Unlimited 是 $0.05 vCPU-hour,這樣看起來其實不賴?風險應該是在於不保證可以拿到多的 CPU resource...

可能要重新算一下 c4c5 的使用方式了...

另外雖然文章後面寫了一大串,但對照 region 表後,看起來是所有的區域都支援了:(美國政府的 region 除外)

You can launch T2 Unlimited instances today in the US East (Northern Virginia), US East (Ohio), US West (Northern California), US West (Oregon), Canada (Central), South America (São Paulo), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Mumbai), Asia Pacific (Seoul), EU (Frankfurt), EU (Ireland), and EU (London) Regions today.

Facebook 與 Google Chrome 以及 Firefox 的人合作降低 Reload 使用的資源

Facebook 花了不少時間對付 reload 這件事情:「This browser tweak saved 60% of requests to Facebook」。

Facebook 的人發現有大量對靜態資源的 request 都是 304 (not modified) 回應:

In 2014 we found that 60% of requests for static resources resulted in a 304. Since content addressed URLs never change, this means there was an opportunity to optimize away 60% of static resource requests.

Google Chrome 很明顯偏高:

於是他們找出原因後,發現 Google Chrome 只要 POST 後的頁面都會 revalidate:

A piece of code in Chrome hinted at the answer to our question. This line of code listed a few reasons, including reload, for why Chrome might ask to revalidate resources on a page. For example, we found that Chrome would revalidate all resources on pages that were loaded from making a POST request.

然後在討論後認為這個行為不必要,就修掉了,可以看到降了非常多:

We worked with Chrome product managers and engineers and determined that this behavior was unique to Chrome and unnecessary. After fixing this, Chrome went from having 63% of its requests being conditional to 24% of them being conditional.

但還是很明顯比起其他瀏覽器偏高不少,在追問題後發現當輸入同樣的 url 時 (像是 Ctrl-L 或是 Cmd-L 然後直接按 enter),Google Chrome 會當作 reload:

The fact that the percentage of conditional requests from Chrome was still higher than other browsers seemed to indicate that we still had some opportunity here. We started looking into reloads and discovered that Chrome was treating same URL navigations as reloads while other browsers weren't.

不過這次推出修正後發現沒有大改變:(拿 production 測試 XDDD)

Chrome fixed the same URL behavior, but we didn't see a huge metric change. We began to discuss changing the behavior of the reload button with the Chrome team.

後來是針對 reload button 的行為修改,max-age 很長的就不 reload,比較短的就 reload。算是一種 workaround:

There was some debate about what to do, and we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones.

Google 也發了一篇說明這個新功能:「Reload, reloaded: faster and leaner page reloads」。

當 Facebook 的人找 Firefox 的人時,Firefox 決定另外定義哪些東西在 reload 時不需要 revalidate,而不像 Google Chrome 的 workaround:

Firefox chose to implement this directive in the form of a cache-control: immutable header.

Firefox 的人也寫了一篇「Using Immutable Caching To Speed Up The Web」解釋這個新功能。

所以之後規劃前後端的架構時又有東西要考慮進去...

CloudFlare 把 HTTPS Everywhere 的清單拿到 CDN 上用所推出的產品...

這個產品就如同標題所說的方式而已,做起來不難,只是一直沒人做就是了:「How we brought HTTPS Everywhere to the cloud (part 1)」。

傳統的作法是直接硬幹下去換掉,或是用 header 讓瀏覽器主動轉過去:

A naive way to do this would be to just rewrite http:// links to https:// or let browsers do that with Upgrade-Insecure-Requests directive.

但這有必須有兩個假設成立才可以:

  • Each single HTTP sub-resource is also available via HTTPS.
  • It's available at the exact same domain and path after protocol upgrade (more often than you might think that's not the case).

而 HTTPS Everywhere 則是用人力確認了哪些網站可以這樣玩。CloudFlare 利用這份清單改寫程式碼裡面的 HTTP 連結,僅可能將 HTTP 資源換成 HTTPS。算是還不錯的方式...

之後有可能再推出對 HTTP images 與 HTTP assets 的 proxy cache?

新的 AWS 帳號將會自動啟用 Long EC2 Resource ID

新的 AWS 帳號將會自動啟用長版的 Resource ID:「New accounts default to long EC2 resource IDs on March 7」。

還是可以 opt-out 改回來,不過官方還是建議儘量用長的 ID 測試,因為今年年底將全面強迫使用:

We recommend testing longer IDs before transitioning; however, if you have not yet tested your systems for compatibility with the longer format, you still have the option to opt out and receive shorter IDs until early December 2016.

EC2 與 ELB 將會有更長的 Resource ID

EC2ELB 將會有更長的 Resource ID:「Heads-Up – Longer EC2 & EBS Resource IDs Coming in 2016」。

重點在這段:

The new IDs will be the same format as existing IDs, but longer. The current ID format is a resource identifier followed by an 8-character string, and the new format will be the same resource identifier followed by a 17-character string.

本來是 8 chars,之後會變成 17 chars。而用 SDK 的人只要更新到新版就可以了:

The SDKs are already compatible with longer IDs and don’t require any updates.

預定在 2016 年發生:

My colleague Angela Chapman wrote the guest post below to make you aware of longer instance, reservation, volume, and snapshot IDs that we will be rolling out in 2016.

EC2 Spot Instance 可以用 Capacity 競標了

前幾天 AWS 的「New – Resource-Oriented Bidding for EC2 Spot Instances」這篇文章提到 EC2 Spot Instance 可以用 capaciy 競標了,也就是以「資源的總量」來飆,而非指定某種型態的 instance。

以文章裡的例子來說,假設要標 488 個單位的 capacity,那麼有可能出現:

  • 2 x r3.8xlarge
  • 4 x r3.4xlarge
  • 8 x r3.2xlarge
  • 16 x r3.xlarge
  • 32 x r3.large

也有可能出現混搭的版本:

  • 1 x r3.8xlarge and 2 x r3.4xlarge
  • 2 x r3.4xlarge and 8 x r3.xlarge
  • 8 x r3.xlarge and 16 x r3.large

對於某種 spot instance 價錢突然提高時,可以改用其他 instance 繼續執行,變得更有彈性...

Archives