日本警察廳希望 ISP 阻擋 Tor...

昨天看到日本警察廳希望 ISP 阻擋 Tor 的新聞:「Japanese police ask ISPs to start blocking Tor」、「Japanese police target users of Tor anonymous network」。

原始的報導是「警察庁有識者会議:サイト管理者が通信遮断を 匿名悪用で」,英文版是「NPA to urge ISP industry to help site administrators block users of hijacking software」。

是日本... 這有點讓人出乎意料 XDDD

SkySQL 與 Monty Program Ab 合併...

TechCrunch 上看到這兩家合併的消息:「SkySQL Merges With MariaDB Creator Monty Program To Solidify Its Open Source Database Position」。

SkySQL 頭接任 CEO,原 Monty Program Ab 頭接任 CTO。對 SkySQL 沒什麼好印象,這合併是要幹什麼...

MySQL 5.7...

Oracle 的「MySQL :: MySQL 5.7 Reference Manual :: 1.4 What Is New in MySQL 5.7」列出 MySQL 5.7 預定會有的功能。由於還在發展階段,這頁還會繼續變動。

針對 ALTER TABLE 有不少改善,以下的條件下 ALTER TABLE 將不會產生 temporily table (不會卡住):

  • table 改名。
  • column 改名。
  • column 改 default value。
  • enum 或 set 在不修改原來值的情況下增加值。
  • partition 相關操作。
  • index 改名。
  • index 新增與刪除。(僅限 InnoDB)

幾個常見的操作變得更簡單了,pt-online-schema-change 的功能會慢慢被整合回 MySQL。

然後 InnoDB 要支援 spatial data types 了,不過 index 還沒支援... 不知道有沒有機會看到 :o

Netcraft 放出 OCSP 伺服器效能資訊...

Netcraft 開始放 OCSP 的效能資訊了。由於有個排名在上面跑,這對於 SSL 供應商應該會有一定的壓力去改善服務品質:「OCSP Server Performance in March 2013」。

前面十名幾乎都是 VerisignAkamai,而 Verisign 都是用 Citrix Netscaler。繼續觀察看看好了...

維基百科英文版與德文版的資料庫 (條目最多的兩個語言) 從 MySQL 轉移到 MariaDB 了...

維基百科官方宣佈兩個條目最多的資料庫 (英文與德文) 已經從 MySQL (有 FB patch 的版本) 轉移到 MariaDB 5.5 了:「Wikipedia Adopts MariaDB」。

維基百科的資料庫從 MySQL 4.0 升級到 MySQL 5.1 時花了不少功夫轉換 (可以想像出來,這兩個版本的差距...),然後這次再到這次的 MariaDB 5.5 就輕鬆不少。

在文章內有提到因為維基百科是 read-heavy site,大多數前端的負荷都在 squid 層擋下來,實際到後端的量則是再透過 Redismemcached 打散負荷。不過即使做了這麼多層 cache,英文版資料庫在尖峰時間還是有 50k qps 的量在跑。

尖峰時間這 50k qps 的量有 80% (也就是 40k qps) 是打散到兩台不同地點的 slave 上,平均的 query response time 是 0.2ms,95% 則是 50ms (好高),其他的 20% 是寫入 master 需求,或是因寫入 master 時需要一致性 (也就是要避免 replication lag 造成的問題)。

這次升級到 MariaDB 5.5.30 是先準備一台新機器,然後在 load balancer 上換掉其中一台 slave (先建後拆),如果 MariaDB 真的有問題也可以馬上 rollback 回來。另外用 pt-query-digest 取樣分析 query 的狀況。

這是成果:

For our most common query type, 95th percentile times over an 8-hour period dropped from 56ms to 43ms and the average from 15.4ms to 12.7ms. 50th percentile times remained a bit better with the 5.1-facebook build over the sample period, 0.185ms vs. 0.194ms. Many query types were 4-15% faster with MariaDB 5.5.30 under production load, a few were 5% slower, and nothing appeared aberrant beyond those bounds.

第一台觀察一陣子沒問題後,接下來一台一台換掉。然後發公告慶祝 :p

不支援 IE{6,7,8} 的 jQuery 2.0...

jQuery 2.0 的消息:「jQuery 2.0 Released」。2.0 版與 1.9 的功能相同,只差在支援度:停止對 IE{6,7,8} 的維護及 workaround。

如同半年前在「jQuery 2.0 將放棄 IE{6,7,8} 的事情...」講的,如果在 John Resig 還在的時候應該不會放棄 IE8...

這是 2012 年七月的數字:

這是 2013 年三月現在的數字:

仍然是超過 10% 而且不太往下掉的數字...

Debian 7.0 預定在五月初出版...

Slashdot 上看到 Debian 7.0 預定在五月第一個週末出版:「Debian 7.0 ('Wheezy') Release Planned For 1st Weekend in May」,在「NewInWheezy」可以看到有哪些變動。

ext4 變成 default filesystem,然後透過 FUSE 支援 exFAT

上次的 Debian 6.0 是 2011 年 2 月 6 日,兩年多了... 還是維持一貫的更新速度... XD

Facebook 的 Memcache 架構...

NSDI '13Facebook 的工程師有講到 Facebook 內的 Memcache 的架構:「Scaling Memcache at Facebook」,有影片可以看,也有 PDF 投影片可以下載。

其實 2013 年這次的 conference 提到的架構以前就有提過了... 雖然一時間找不到之前提到架構的投影片,但還是可以配合著以前提到各種架構的文章與投影片看出 Facebook 怎麼利用 Memcache 架構 cache layer:

Facebook 會這樣設計 Memcache 架構,跟 Facebook 用 PHP 的方式有關,是在 PHP 的限制下想辦法爭取效率的作法。

不過這些投影片裡的資料畢竟是有年代了,現在的 memcached 改善了很多,跟當年的情況不太一樣,看之前的投影片最好知道當時 memcached 有哪些問題會比較能理解 Facebook 的工程師們想要解決什麼問題。

OCSP 是如何影響 HTTPS 的效率...

Netcraft 從 2012 年 11 月開始偵測 OCSP 的 availability,然後發現各家 OCSP 的穩定性都不太好:「Certificate revocation and the performance of OCSP」。

OCSP 是 Online Certificate Status Protocol 的縮寫,當 HTTPS 連線建立中,client 可以透過 OCSP 詢問這份 certificate 是否有效。這是 PKI 架構下的事後補救機制,因為已經發出去的簽名是無法被收回的,只好靠連線時再查詢。

另外一個機制比較舊,叫 CRL (Certificate Revocation List),則是屬於清單類的機制,更新速度比 OCSP 慢。

目前是以 OCSP 為主,而舊的平台 (就是 XP 上的 IE) 則只支援 CRL。

可以看到 OCSP 檢查打開後對於速度的影響,有的影響很明顯,有的還好。而原文下面很多張 uptime 圖表也可以看出來各家 OCSP 的穩定性其實不怎樣,有些是直接上 Akamai 解決,有些是上 CloudFlare 解決 (然後遇到幾次 CloudFlare 爆炸就跟著炸 XD)

目前瀏覽器大多都是 soft-fail,也就是查不到就當作 pass。照目前的穩定性要推動 hard-fail (查不到就 break) 應該是頗有難度...

對於 HTTPS 速度很在意的人可以看一下內文的說明,可以挑 OCSP 速度比較快的幾家簽,對速度會有幫助...