最佳化 nginx 的 TLS Time to First Byte (TTTFB)

在「Optimizing NGINX TLS Time To First Byte (TTTFB)」這篇文章裡在討論要如何讓 nginx 的 TLS Time to First Byte (TTTFB) 盡可能短。

可以看到文章裡面用到兩個方法,一個是修改 nginx 的程式碼縮小 TLS record size。我對是覺得頗危險,尤其是作者的改法不知道有什麼 side-effect... (要注意 nginx 裡面直接拿 NGX_SSL_BUFSIZEBIO_set_write_buffer_size 使用,這代表有可能還有其他的地方也是這樣搞?)

第二個方法是開啟 TLS False Start,目前主流的瀏覽器都陸陸續續支援了。

這是文章作者的測試:

可以看到時間減少的相當多。

現在是期望作者這篇文章的測試可以讓 patch 合併回 mainstream 後再用,這樣有比較多人 audit...

Instagram 從 AWS 搬到 Facebook 機房

InstagramInstagram Engineering Blog 上宣佈的消息:「Migrating From AWS to FB」。

整個 migration 的過程是採取不停機轉移,所以 effort 比直接停機轉移高很多:

The main blocker to this easy migration was that Facebook’s private IP space conflicts with that of EC2. We had but one route: migrate to Amazon’s Virtual Private Cloud (VPC) first, followed by a subsequent migration to Facebook using Amazon Direct Connect. Amazon’s VPC offered the addressing flexibility necessary to avoid conflicts with Facebook’s private network.

先把整個系統轉移到 Amazon VPC 裡,然後再拉 AWS Direct Connect 串起來,接下來才是慢慢把 instance 轉移到 Facebook 的機房內。

中間也有一些工作:

To provide portability for our provisioning tools, all of the Instagram-specific software now runs inside of a Linux Container (LXC) on the servers in Facebook’s data centers.

所以已經導入 LXC 了...

行動平台上的 Tor browser

在「The problem behind mobile TOR browsers' ip disclosure」測了四個行動平台的 Tor 瀏覽器,其中三個是 Android 上的,一個是 iOS 的。

四個瀏覽器測試的結果中,只有 iOS 上的 Onion Browser (要 USD$0.99) 可以在修改設定後達到最低限度「隱藏 real ip」的標準:

作者的建議是不要在行動平台上有太多期望,隱藏 real ip 只是其中一個環節...

Mike Bostock 的 Visualizing Algorithms

Mike Bostock (D3.js 的創始人之一) 在 Eyeo 2014 上展現了要如何將演算法視覺化表現出來:「Visualizing Algorithms」。

既然是對演算法的展示,當然也都伴隨著對資料的處理。每一個圖形表示都有 D3.js 的 sample code 告訴你怎麼產生的。

與其他看到的 D3.js 範例不同,他給出來的範例可以感覺到「樸實無華」的壓迫感。文章開頭用梵谷「隆河上的星夜」也很配合整篇文章的風格。

有玩 D3.js 或是對資料視覺化的人有興趣或是有研究的人都應該去看他怎麼表現「動作」(演算法) 的部份。

Amazon Elastic Transcoder 與 Zencoder 的比較

在「Amazon Elastic Transcoder: Review」這邊比較了 Amazon Elastic TranscoderZencoder 兩個服務。

結論在一開頭就先提出來了:

For broadcasters and high-volume producers, Amazon's Elastic Transcoder has too many limitations. For everyone else, it's an appealing, if flawed, solution.

就轉出來的品質來說,作者認為沒什麼差異:

但就速度來說,Amazon Elastic Transcoder 的速度偏慢:

另外作者在文末也給了不少負面評價... 記錄起來以後應該用的到 :o

128bytes 組合語言的 3D 綜合展示...

原始程式碼在「Wolf128.asm」這邊,依照說明,是跑在 Windows XP SP3 + DOSBox。在「Dissecting the 128-byte raycaster」這邊的「Assembly code analysis」這段有程式碼的解說。

如同引用的文章一開始說的,這結合了滑鼠控制、材質貼圖、Ray casting 以及動畫效果的程式,而只有 128bytes!

我上面這一段文字用 UTF-8 表示都已經超過 128bytes 了... ~_~

Netflix 不僅使用 AWS,還使用了 GCE...

在「Cloud guru Adrian Cockcroft on Netflix, Amazon, Google, and DigitalOcean」這篇裡面提到 Netflix 現在不僅使用 AWS,還使用了 GCE

The company’s services are now all hosted in the public cloud, but not just in AWS. Netflix is also using Google Compute Engine.

不算是很意外... 畢竟有那個 scale 與實力。

Amazon CloudFront 的新增功能

Amazon CloudFront 新增了 Whitelist Header 的功能:「Deliver Custom Content With CloudFront」。

如同在 post 裡說明的:

If you choose the Whitelist option, each header that you add to the list becomes part of the cache key for the URLs associated with the distribution.

有點像是 HTTP 協定裡 Vary 想要解決的問題,只是做在 CDN 這端。這個功能蠻多 CDN 都有,AWS 總算補上了...

這次除了可以針對 custom HTTP header 處理外,CloudFront 還做了不少事情:

  • Mobile Device Detection
  • Geo-Targeting
  • Multi-Site Hosting
  • Protocol Detection
  • CORS (Cross Origin Resource Sharing)

前兩項還蠻有意義的,這代表會有人幫你更新資料。而 CloudFront 總算是支援 CORS 了...

把舊站的 comment 關掉...

這幾天 blog 常常出現 504,連到機器上發現 MySQL 很忙,才發現是舊站 spam 的量太大的問題造成的,把舊站的 comment 關掉後就好不少,現在看機器的 CPU loading 應該是正常多了。

新站已經是用 DISQUS 所以比較沒有 comment spam 的問題。舊站那邊除了關掉 comment 外,另外直接進 MySQL 把 2006 年之後的 comment 都丟到 pending 裡面去。(因為 2005 年 8 月後就沒更新舊站了)

來研究看看要怎麼把舊的 comment 丟進 Akismet...

Update:發現只要按下 Check for Spam 的按鈕就會把目前 Pending comments 都丟去 Akismet 掃,先丟著 :p