Tag: performance

測試 MySQL 效能的方法

在 DigitalOcean 上的教學文章看到另外一種 MySQL 效能測試的方法：「How To Measure MySQL Query Performance with mysqlslap」。

一般會拿 Percona 的 tpcc-mysql 測，用 mysqlslap 好像比較少看到，雖然也是蠻有名的工具...

不過還是可以拿來玩玩看，互相比較的時候是一個指標...

Oracle 在 COSCUP 2014 上對 MySQL 效能調整的投影片

Oracle 的梶山隆輔在 COSCUP 2014 的投影片：「MySQL Performance Tuning at COSCUP 2014」：

推薦的主力在 MySQL 5.6，這點 Percona 的人也已經宣傳過很多次了：

MySQL 5.6 的改善很大，尤其是針對 InnoDB 相關的改善。在 MySQL 5.5 上還會有 CPU 吃不滿的情況，在 MySQL 5.6 好很多。

GitHub 的 CSS 設計

在「GitHub's CSS」這篇裡面講了很多 GitHub 設計的工具，以及評估的方式。

原文有提到 IE9 以及之前的版本中，單檔有 4095 selector 的限制，這點讓人稍微怔了一下：

The split was added years ago to solve the problem of Internet Explorer’s 4,095 selectors per file limit.

超過的要切割讀入...

另外在文中有提到 2012 年的投影片「GitHub's CSS Performance」吸引我的目光：

針對 diff 頁面大量元素時的 CSS 效能分析，除了各種 browser 裡 index id & class & tag 的方式外，另外還有不少為了加速而直接修改 HTML 的建議 XDDD

Netflix 與 Comcast 的恩怨

其實就是商業公司之間的勾心鬥角，在包裝後搬到檯面上 :p

Netflix 在美國固網裡吃的流量比 YouTube 還多，可想而知當然就變成各 ISP 找麻煩的對象...


出自 Sandvine 的「Global Internet Phenomena Report 2H 2013」。

Netflix 有多種方式將影片傳遞給使用者。除了早期自建機房外，後來跟不少 CDN 有業務往來 (包括了 Akamai、Limelight、Level3)，另外也有 Netflix Open Connect Content Delivery Network 計畫，直接在 ISP 內部機房放設備提供服務。

使用 CDN 的作法成本太高，而 ISP 又不一定會接受 Open Connect 方案 (因為不一定收的到錢)，在這種情況下，如果走 transit 線路的速度通常都不會太好。而 Netflix 與 Comcast 之間的狀況就是如此：

在付給 Comcast 錢後速度都都解決了...

除了付錢解決外，上個禮拜 Netflix 就丟出一篇說明的文章發難了：「The Case Against ISP Tolls」，這篇文章除了提到上面的事情外，另外還極力反對 Comcast 與 Time Warner Cable 的併購案 XDDD

然後最近又炒熱的網路中立問題，看起來也這件案子應該會很熱鬧 XDDD

在 S3 上儲存大量資料時要注意的事情

印象中要在 Amazon S3 上面存大量資料時需要注意 key 的命名，用 Google 找了找發現官方的「Request Rate and Performance Considerations」這篇。

文章中有提到這是對有大量存取需求時才需要注意的事項：

The guidelines in this section apply if you are routinely processing 100 or more requests per second. If your typical workload involves only occasional bursts of 100 requests per second or more, you don't need to follow the guidelines in this section.

不過平常即使沒有需要大量存取，還是可以照著做，因為應該不會有負面影響。如果能照著上面的方式先做，之後也許會受益...

由於 Amazon S3 是使用 key-prefix 當作 partition 的依據，所以 prefix 的值對於效能很重要。官方推薦的幾種方法都是對 key-prefix 下手：

  • 對整個 path + filename 的字串 hash 後當作 prefix。舉例來說，examplebucket/2013-26-05-15-00-00/cust1234234/photo1.jpg hash 後加到前面，名稱變成 examplebucket/232a-2013-26-05-15-00-00/cust1234234/photo1.jpg。
  • 將最前面一段 reverse string。像是把 2134857/data/start.png 變成 7584312/data/start.png。

虛擬環境下檔案系統的讀寫速度...

有人對 VMware 以及 VirtualBox 測試效能：「Comparing Filesystem Performance in Virtual Machines」，有四張圖：

不過數字怪怪的，NFS 那邊是怎樣 XDDD

看看就好，如果有用到再自己測試看看吧？

Percona 提供 Linux 平台上 MySQL server 調整的參數...

Percona 的人針對 Linux 平台跑 MySQL 的建議：「Linux performance tuning tips for MySQL」。

檔案系統方面建議用 ext4 或是 xfs，記得要用 noatime。(我建議再加上 nodiratime)

然後 i/o schedular 建議用 deadline 或是 noop，這點可以參考之前寫的「關於 Linux 的 Disk I/O 調整...」。

記憶體的部份要處理 swap 與 NUMA 的控制，然後 CPU 的部份要把自動調整速度的功能關掉 (可以省電，不過對忙碌的資料庫應該用不到)。

看起來是比較一般性的方向，不過應該是蠻好用的建議 :p

innodb_stats_on_metadata 對效能的影響...

從美國回來後開始整理還蠻空看的文章...

在 Percona 的「innodb_stats_on_metadata and slow queries on INFORMATION_SCHEMA」這篇看到 innodb_stats_on_metadata 這個值對 InnoDB 效能影響的討論。

When the option is set to ON, InnoDB index statistics are updated when running SHOW TABLE STATUS, SHOW INDEX or when querying INFORMATION_SCHEMA.TABLES or INFORMATION_SCHEMA.STATISTICS.

值得提出來的是，這個值在 MySQL 5.6 內的 InnoDB 預設是關閉的，在 5.1 與 5.5 則是開啟的。這應該代表了官方的一些想法？不過看起來對一般的表格沒有影響...

還是關掉好了？

十個改善 MySQL 效能的方式

在 Zite 上看到這篇介紹 MySQL 效能調教的方式：「Ten ways to improve the performance of large tables in MySQL」。

這邊就順著作者的建議一路寫下去。

作者也是大力推薦用 InnoDB 解決問題。

InnoDB 有個特別的功能 (相較於 MyISAM 而言。這個功能在 MySQL 5.5 預設就是開啟的) 是 change buffering，會延遲寫入 non-unique secondary index，讓多筆 secondary index 合併起來一起寫，這會改善寫入的效能。

Partition 對於 index 的大小也會有幫助。InnoDB 的壓縮功能也是必備項目 (除非你的 Use case 很極端)，減少資料量就直接減少 i/o 並且拉高 hitrate。

再大量寫入資料時依照順序寫入會讓 InnoDB 寫入的順序僅可能連續。由於 InnoDB 的特性 (clustered index)，這樣可以讓寫入速度變快很多。

避免使用 UNIQUE key，因為 UNIQUE 的特性會犧牲很多效能...

因為 secondary index 是指到 PRIMARY KEY 的值，所以 PRIMARY KEY 的值僅可能單純，以 INT 或是 BIGINT 為佳。

第一次大量倒資料進系統時，可以先倒 data 以及 PRIMARY KEY 就好 (如上所說的，要依照 PRIMARY KEY 的順序倒進去)，等倒完後再建立 secondary index，這樣速度會快很多。

最後兩項就是，記憶體愈大愈好，硬碟愈快愈好，如果用 SSD 是可行的方案就用 :p