Tag: benchmark

用 Go 寫的 Badger

Dgraph 在推銷自家發展出來的 Badger：「Introducing Badger: A fast key-value store written natively in Go」。

標靶是 RocksDB，號稱比 RocksDB 快好幾倍：

Based on benchmarks, Badger is at least 3.5x faster than RocksDB when doing random reads. For value sizes between 128B to 16KB, data loading is 0.86x - 14x faster compared to RocksDB, with Badger gaining significant ground as value size increases. On the flip side, Badger is currently slower for range key-value iteration, but that has a lot of room for optimization.

不過我覺得有些重要的功能在 Badger 不提供，這比起來有種橘子比蘋果的感覺... 像是 RocksDB 提供了 Transaction，而 Badger 則是直接講明他們不打算支援 Transaction：

Keep it simple, stupid. No support for transactions, versioning or snapshots -- anything that can be done outside of the store should be done outside.

細看 MySQL 的 Performance Schema 對效能的影響

Percona 的人對 MySQL 5.7 的 OLTP RW 測試中，Performance Schema 的各種不同的功能對效能帶來的影響：「Performance Schema Benchmarks: OLTP RW」。

原文章裡有定義這些分別是打開哪些功能，這邊就跳過去... 重點是 default 值對效能的影響其實不算高，所以除非是想要壓榨每一分效能，不然其實可以考慮打開 (針對 OLTP RW 類似的應用)：

影響比較大的是 Stages 與 Waits 的部份。而 Mark Callaghan 在 comment 提到在 Performance Schema Event Timing 這邊有相關的資料... 看起來應該可以降低對 Stages 與 Waits 的效能衝擊。

Amazon S3 與 HDFS 的速度差異

作者繼續以 A Billion Taxi Rides 的資料測試各種差異，這次測了 Amazon S3 與 HDFS 的速度差異：「A Billion Taxi Rides: AWS S3 versus HDFS」。

前半部都在說明測試的環境設定，重點在文章的最後面 (也就是「Benchmarking HDFS」這段)，裡面有各種 query 的速度。HDFS 的速度大約是 Amazon S3 的 1.25 到 1.75 倍，作者給的結論是：

Though the speed improvements using HDFS are considerable, S3 did perform pretty well. At worst there's a 1.75x overhead in exchange for virtually unlimited scalability, 11 9's of durability and no worrying about over/under-provisioning storage space.

雖然 HDFS 比較快，但 Amazon S3 其實表現的不錯，另外資料安全性 (平均 99.999999999%，也就是 11 個 9 的 durability) 及不需要怕空間不夠的優點也是應該考慮進去的因素。

對各類 Message Queue 的效能測試

在「Benchmarking Message Queue Latency」這篇看到作者測了一輪 Message Queue 軟體：

RabbitMQ (3.6.0), Kafka (0.8.2.2 and 0.9.0.0), Redis (2.8.4) pub/sub, and NATS (0.7.3)

測試包括了從一個 9 到六個 9 的 latency (i.e. 90%、99%、99.9%、99.99%、99.999%、99.9999%)，另外也測了 message 大小帶來的效能差異。

99.9% 表示 1/1000，而 99.99% 表示 1/10000，如果差距跟 90% 很大，表示系統反應時間會很不一致。另外有些 Message Queue 軟體有 disk persistence 的功能，也因為寫入資料，會看到更大的差距。

善用或是避開這些特性去規劃才能減少問題，像是關掉 disk persistence 之類的方法。

PCIe 的 SSD 與 SATA 的比較

LogicMonitor 的人比較了 PCIe SSD 與 SATA SSD，他們在意的重點是 read/write latency 非單純的 throughput：「Device Utilization of PCIe and SATA SSDs」。

文章裡講得很長，把他們找原因的過程寫出來，從 latency 的影響改變到 queue service 的變化：

後來換成 PCIe SSD 後 write latency 從 1.8ms 掉到 0.02ms 左右，大約是兩個零的差距。

另外文章裡也提到了 fio 這個測試工具，找時間來測試看看，熟悉一下...

CloudFlare 正式推出 HTTP/2，可以與 SPDY 同時混搭

CloudFlare 推出了 HTTP/2 服務，與其他 CDN 業者不一樣的地方在於，他可以同時接受 HTTP/2 與 SPDY：「HTTP/2 is here! Goodbye SPDY? Not quite yet」。

CloudFlare 拿自家的 www.cloudflare.com 官網測試，顯示 HTTP/2 的效能比 SPDY 又好了不少：

Access via HTTP Protocol Version Average Page Load time
HTTP 1.x 9.07 sec.
SPDY/3.1 7.06 sec.
HTTP/2 4.27 sec.

在正式上 HTTP/2 前，有 80.38% 對 www.cloudflare.com 的 SSL/TLS 連線是 SPDY：

During the week before our HTTP/2 launch, 80.38% of all SSL/TLS connections to our own website at www.cloudflare.com were made over SPDY/3.1.

上線後其實沒有想像中的高：

Protocol Version Percentage of Hits
HTTP 1.x 19.36%
SPDY/3.1 57.02%
HTTP/2 23.62%

這也說明了為什麼 CloudFlare 要推出 SPDY + HTTP/2 的服務：

Why choose, if you can have both? Today CloudFlare is introducing HTTP/2 support for all customers using SSL/TLS connections, while still supporting SPDY. There is no need to make a decision between SPDY or HTTP/2. Both are automatically there for you and your customers.

剛剛連到後台確認，由於本來已經打開 SPDY 的使用者會自動開啟 HTTP/2，這表示全球 HTTP/2 的使用率會馬上拉高很多，有太多資源掛在 CloudFlare 上：(像是 cdnjs.com，剛剛確認也已經是 HTTP/2 了)

If you are a customer on the Free or Pro plan, there is no need to do anything at all. Both SPDY and HTTP/2 are already enabled for you.

Customers on Business and Enterprise plans can enable HTTP/2 within the "Network" application of the CloudFlare Dashboard.

AWS 上 MySQL + MHA、Galera Cluster、Amazon RDS for Aurora 的比較

在 Twitter 上看到的文章，對三套有 High Avaiilability 能力的 MySQL 系統比較：「AWS Aurora Benchmarking - Blast or Splash?」。

測試的項目包括了 MySQL + MHA、Galera Cluster 以及 Amazon RDS for Aurora 三種，包括了 failover 的各種速度以及資料庫效能的比較。

測試的結果可以看到 Galera Cluster 有不少優勢，不過我必須說 Galera Cluster 並不好搞，初期要使用的話乾脆用 Aurora 就好，failover 的確是比較慢，而且效能也沒有 Galera Cluster 好，但管理上輕鬆很多啊...

用 sysbench 測試 MySQL 效能

很久前是用 tpcc-mysql 測試 MySQL 效能：「用 tpcc-mysql 測試 LSI 的 Nytro MegaRAID NMR 8100-4i」，最近剛好又有測試需求，想說拿來學個新玩具測試，就想到 sysbench 的 oltp 測試。

先用 Google 找了找測試的方式，appleboy 之前寫的「Sysbench 測試 Percona XtraDB Server 效能」算是還不錯的文件，就拿來當起點了。

我是拿 AWS 測試，主要是因為幾乎所有的效能都是固定的，這樣測出來才有意義。

Amazon EC2 用 c4.8xlarge，用 10Gbps 網路測試會比較準確一點。硬碟的部份是掛上 100GB 的 SSD 硬碟，如果是測 I/O bound 的人就選擇有固定 IOPS 的 Provisioned 版本，但我這次測的都是 CPU bound，就只選用 General 版本了。

跑起 Ubuntu 14.04 後直接用 apt-get install sysbench 就可以裝起來了。

Percona 的 apt repository 設定可以參考官方的「Installing Percona Server on Debian and Ubuntu」這篇文章。設好後要裝什麼版本測試就是自己的選擇了。

都裝好後，測試的方式是先用 prepare 塞資料，再用 run 測試。

這是 prepare 部份的指令：(粗體字的 x 需要帶入自己對應的參數)

sysbench --test=oltp --db-driver=mysql --mysql-engine-trx=yes --mysql-table-engine=innodb --mysql-host=x --mysql-user=x --mysql-password=x --oltp-auto-inc=off --test=/usr/share/doc/sysbench/tests/db/oltp.lua --oltp-table-size=10000000 prepare

這是 run 部份的指令，我這邊用了 --oltp-read-only=on 只測 read transaction 的速度：

sysbench --test=oltp --db-driver=mysql --mysql-engine-trx=yes --mysql-table-engine=innodb --mysql-host=x --mysql-user=x --mysql-password=x --oltp-auto-inc=off --test=/usr/share/doc/sysbench/tests/db/oltp.lua --oltp-table-size=10000000 --oltp-read-only=on --num-threads=256 --report-interval=5 --max-time=60 --max-requests=0 run

大致上就是這樣測，然後用 gnuplot 畫圖。

Benchmark DAC2 HGC 在 Ubuntu 14.04 LTS 下使用 USB 沒有聲音的問題

記得剛買來的時候是有聲音的，後來突然有一天沒聲音... 試了一堆方法都沒用 (換 kernel 版本、禁用 xHCI、換 USB 線、...)，最後是在「Benchmark DAC2 HGC impressions (and Linux setup notes)」這邊看到方法。

這邊有幾個重點：

DAC2's USB 1.0 mode doesn't work with Linux kernel 3.8.x, but USB 2.0 does. So switch it to USB 2.0 and forget about it. Next, I figured that the audio was simply being muted in some instances. The solution is to open a terminal window, run AlsaMixer, hit F6 to configure the DAC 2. Even though their levels cannot be altered (they're fixed at 00), the first two items must be unmuted in order to get any sound:

如同文章裡說的，USB 1.0 模式 (會抓到「Benchmark DAC2 USB Audio 1.0」) 是不會動的，而 USB 2.0 可以 (會抓到「Benchmark DAC2 USB Audio 2.0」)，但播放時沒有聲音。

解法則是使用 alsamixer，進入後按 F6 選 Benchmark DAC2，將前面兩個用 m 給 unmute 掉就好了：

為此學到一堆底層看 USB 的工具...

支援多 CPU 的 ab：wrk

在「wrk」這邊看到 wrk 這個工具：「Modern HTTP benchmarking tool」。

利用 multi-threading 與 epoll/kqueue 撐出效能：

wrk is a modern HTTP benchmarking tool capable of generating significant load when run on a single multi-core CPU. It combines a multithreaded design with scalable event notification systems such as epoll and kqueue.