在 Google Chrome 上關閉 AMP (Accelerated Mobile Pages)

裝了 Amplifier AMP/Canonical switcher,在 Google Chrome 上可以關閉 AMP 頁面 (Accelerated Mobile Pages)。專案的 GitHub 頁面在 jpettitt/amplifier

This extension is designed for developers working with the AMP (Accelerated Mobile Pages) standard. It detects AMP links in the page header and allows quick switching between the AMP and Canonical version of a page. Optionally AMP pages can be loaded with the AMP validation enabled (#development=1).

每一家的 AMP 連結結構都不一樣,所以就只好裝個套件快速切了...

Netflix 對 Landing Page 的效能改善計畫...

幹掉 React (噗):

官方帳號丟戰文出來... 後面就有人開始亂 XDDD

不過先拉回來看... 依照說明,其他頁面都還是跑 React,只有 Landing Page 被改寫,看起來 Landing Page 的 TTI (Time to Interactive) 是他們的 KPI,所以就被拿出來另外處理了...

當然也有可能有其他的陰謀論 (而且我覺得可能性是在的):因為之前 React 的專利問題,變成之後 Facebook 如果真的出手提出告訴,會以惡意侵權來告 (因為鬧這麼大以後,沒有理由裝作不知道了)。這次只換 Landing Page 可以當作是試水溫練功 (累積 migration 的經驗),後續再換內頁...

在網頁上看 arXiv 的論文

Hacker News Daily 上看到的服務「Arxiv Vanity – Read academic papers from Arxiv as web pages」:

Arxiv Vanity renders academic papers from Arxiv as responsive web pages so you don’t have to squint at a PDF.

不過實際測試發現只有有提供 TeX 格式原始檔才有辦法轉,沒提供的就不行了...

Reddit 在處理 Page View 的方式

Reddit 說明了他們如何處理 pageview:「View Counting at Reddit」。

以 Reddit 的規模有提到兩個重點,第一個在善用 RedisHyperLogLog 這個資料結構,當量大的時候其實可以允許有微小的誤差:

The amount of memory varies per implementation, but in the case of this implementation, we could count over 1 million IDs using just 12 kilobytes of space, which would be 0.15% of the original space usage!

維基百科上有說明當資料量在 109 這個等級時,用 1.5KB 的記憶體只有 2% 的誤差值:

The HyperLogLog algorithm is able to estimate cardinalities of > 109 with a typical error rate of 2%, using 1.5 kB of memory.

第二個則是寫入允許短時間的誤差 (pageview 不會即時反應),透過批次處理降低對 Cassandra cluster 的負荷:

Writes to Cassandra are batched in 10-second groups per post in order to avoid overloading the cluster.

可以注意到把 Redis 當作 cache 層而非 storage 層。

主要原因應該跟 Redis 定位是 data structure server 而非 data structure storage 有關 (可以從對 Durability 的作法看出來),而使用 Cassandra 存 key-value 非常容易 scale,但讀取很慢。剛好兩個相輔相成。

Jenkins 的 Blue Ocean 計畫,改善使用者操作的友善度...

JenkinsBlue Ocean 計畫打算改善讓人頭痛很久的操作體驗了:

Blue Ocean is a new project that rethinks the user experience of Jenkins.

Jenkins 讓人頭痛有兩個面向,一個是界面很難讀,另外一個是操作流程很沒有規則,所謂「熟悉 Jenkins」其中一個很艱難的任務就是要背下一堆功能「蔵在哪邊」。而這次 Blue Ocean 想改善的事情看起來主力放在界面,對於流程修的比較少... 即使如此,這還是可以讓使用的人減少一些痛苦就是了...

成功與爆炸的表現:

在專案頁面的後面有提到 Blue Ocean 用的技術:

Blue Ocean is built as a collection of Jenkins plugins itself. There is one key difference, however. It provides both its own endpoint for http requests and delivers up html/javascript via a different path, without the existing Jenkins UI markup/scripts. React.js and ES6 are used to deliver the javascript components of Blue Ocean. Inspired by this excellent open source project (react-plugins) an <ExtensionPoint>pattern was established, that allows extensions to come from any Jenkins plugin (only with Javascript) and should they fail to load, have failures isolated.

又是個不需要用 SPA 呈現的東西跑去用 React 了...

MySQL 5.7 中 InnoDB 的 innodb_page_size 在 SSD 硬碟上對效能的巨大影響

Percona 的「Small innodb_page_size as a performance boost for SSD」這篇文章裡提到了 MySQL 5.7 的 innodb_page_size 在 SSD 上對效能的差異,主要是這張圖的解釋:

先講一下標示的部份,有三個產品線 (都是 Samsung 的 SSD),中間的 sam850 是消費級的 SSD 硬碟 (所以不是本次重點),而 sam863 是企業級 SATA SSD,pm1725 則是企業級 PCI-e SSD。下方的 BP 指的是 Buffer Pool 大小,單位是 GB。左邊是速度,數字愈大愈好。

InnoDB 預設 16KB 的 page size,配合 SSD 大多都是 4KB 的 block size 後,效能的提昇非常巨大 (70% 的提昇),雖然既有的 InnoDB 要換過去會花不少功夫,但作者還是很建議評估:

I think a 70% performance gain is too significant to ignore, even if manipulating innodb_page_size requires extra work. I think it is worthwhile to evaluate if using different innodb_page_size settings help a fast SSD under your workload.

不過 comment 有不少額外重要的資訊。

有提到 Galera Cluster 目前有 bug,無法使用 4KB page size,可以在「Restarting a cluster with innodb_page_size=4096 segfaults」這邊看到 bug report。

另外有提到,使用 InnoDB Compression 的前提下,4KB 也許不是個好主意,用 8KB 也許是個方向:

You’re right – if you’re using Innodb Compression 4K base page is unlikely to be the good choice. Though we do not see Innodb compression (any of them) being used too frequently.

If using compression 8K base page size with 4K compressed page size might be good idea if 2x compression is routinely reached

不過我覺得應該還是有幫助才對 (可能提昇不高,但想了一下應該不會有負面的影響),之後有機會再測試看看吧 :o

Google Chrome 停用平滑捲動

因為把 JavaScript 開回來了,所以有這個困擾... :(

Google Chrome 的平滑捲動可以透過 chrome://flags 裡面的設定關閉 (OS X 上則是透過系統設定關閉),但就是有不少網站會很雞婆,用 JavaScript 模擬平滑捲動,所以就花了時間把 extension 寫出來:「Stop Smooth Scrolling」。

由於大多數平滑捲動的作法都是透過對 document 或是 window 上掛上與平滑捲動相關事件做到的,所以我是透過 addEventListener()useCapture flags,然後再用 preventDefault() 擋下後續的處理。

這樣做會有一些問題,其中比較明顯的是地圖類功能的滾輪會失效,這個部分我先放進預設的白名單了,如果有其他的問題,除了可以自己加以外,也可以開 ticket 讓我加進預設清單 :o

實際運作起來大概是這樣:

Anyway,寫這個還蠻有趣的,玩了不少新東西:

PostgreSQL 對 Vacuum 效能的改善

在「No More Full-Table Vacuums」這邊提到了 PostgreSQL 在 vacuum 時效能的大幅改善,尤其是大型資料庫在 vacuum 時需要對整個表格從頭到尾掃一次以確保 transaction id 的正確性:

Current releases of PostgreSQL need to read every page in the database at least once every 2 billion write transactions (less, with default settings) to verify that there are no old transaction IDs on that page which require "freezing".

這動作在資料量大的機器上就會吃大量資源導致各種討厭的現象:

All of a sudden, when the number of transaction IDs that have been consumed crosses some threshold, autovacuum begins processing one or more tables, reading every page. This consumes much more I/O bandwidth, and exerts much more cache pressure on the system, than a standard vacuum, which reads only recently-modified page.

而作者送了 patch 改成只會讀還沒搞定的部份:

Instead of whole-table vacuums, we now have aggressive vacuums, which will read every page in the table that isn't already known to be entirely frozen.

要注意的是,agreesive vacuum 相較於 vacuum 會多吃很多資源,但可以打散掉 (有點像一次大 GC 導致 lag 與多次 minor GC 讓程式反應時間變得比較順暢的比較):

An aggressive vacuum still figures to read more data than a regular vacuum, possibly a lot more. But at least it won't read the data that hasn't been touched since the last aggressive vacuum, and that's a big improvement.

這個功能預定在 PostgreSQL 9.6 出現,不知道會不會變 default...

Google PageRank 資料將不再公開

Google 將不再對外公開 PageRank 資訊:「Google has confirmed it is removing Toolbar PageRank」與「RIP Google PageRank score: A retrospective on how it ruined the web」。

PageRank 資訊是透過 Google Toolbar 再反向被挖出來的,而 Toolbar 上的資訊將會拿掉,也預期對應的 API 應該也會關閉:

Google has confirmed with Search Engine Land that it is removing Toolbar PageRank. That means that if you are using a tool or a browser that shows you PageRank data from Google, within the next couple weeks it will begin not to show any data at all.

Google 內部還是會用,只是不會公開了...

新版 Instagram 將可以看到影片播放次數了

Mashable 的報導說下個版本的 Instagram 將會提供影片播放次數資訊了:「Instagram videos will get cool new updates to let you see how popular you are」。

The number of times a video is viewed on Instagram will soon no longer be a mystery.

Instagram is adding a new feature that will tally view counts much like parent company Facebook already does, eliminating a major blindspot for marketers attempting to tap into the app's 400-million strong audience organically.

愈來愈多 social network 往 video 這塊著力...