Home » Posts tagged "benchmark"

原來 Oracle 與 Microsoft 裡的條款是這樣來的...

看到「That time Larry Ellison allegedly tried to have a professor fired for benchmarking Oracle」這篇文章的講古,想起很久前就有聽過 Microsoft 有這樣的條款 (禁止未經原廠同意公開 benchmark 結果),原來是 Oracle 在三十幾年前創出來的?而且這種條款還有專有名詞「DeWitt Clauses」,出自當初被搞的教授 David DeWitt...

Microsoft 的條款是這樣:

You may not disclose the results of any benchmark test … without Microsoft’s prior written approval

Oracle 的則是:

You may not disclose results of any Program benchmark tests without Oracle’s prior consent

IBM 的反而在 license 裡面直接允許:

Licensee may disclose the results of any benchmark test of the Program or its subcomponents to any third party provided that Licensee (A) publicly discloses the complete methodology used in the benchmark test (for example, hardware and software setup, installation procedure and configuration files), (B) performs Licensee’s benchmark testing running the Program in its Specified Operating Environment using the latest applicable updates, patches and fixes available for the Program from IBM or third parties that provide IBM products (“Third Parties”), and © follows any and all performance tuning and “best practices” guidance available in the Program’s documentation and on IBM’s support web sites for the Program…

PHP 7.2 的效能改善

作者在「PHP 7.1 vs 7.2 Benchmarks (with Docker and Symfony Flex)」這邊拿 Symfony 測試 PHP 7.2 的效能,發現效能提昇主要來自於多個連線時的情境:

前面的數字是前端頁面 (用了 Twig),後面的數字是純 API 呼叫。都可以看出 conc = 1 時其實沒有顯著差異,但只要有多個連線同時存取時,效能的提昇就會展現出來。對於繁忙的站台感覺會有不少幫助...

作者的猜測是 opcache 模組的改善,也就是在這段提到的:

- Opcache:
  . Added global optimisation passes based on data flow analysis using Single
    Static Assignment (SSA) form: Sparse Conditional Constant Propagation (SCCP),
    Dead Code Elimination (DCE), and removal of unused local variables
    (Nikita, Dmitry)

Branchless UTF-8 解碼器

看到「A Branchless UTF-8 Decoder」這篇,先來回憶一下「非常經典的 UTF-8...」這篇,以及裡面提到的 encoding:

因為當初在設計 UTF-8 時就有考慮到,所以 decoding 很容易用 DFA 解決,也就是寫成一堆 if-then-else 的條件。但現代 CPU 因為 out-of-order execution 以及 pipeline 的設計,遇到 random branch 會有很高的效能損失,所以作者就想要試著寫看看 branchless 的版本。

成效其實還好,尤其是 Clang 上說不定在誤差內:

With GCC 6.3.0 on an i7-6700, my decoder is about 20% faster than the DFA decoder in the benchmark. With Clang 3.8.1 it’s just 1% faster.

而後來的更新則是大幅改善,在 Clang 上 DFA 版本比 branchless 的快:

Update: Björn pointed out that his site includes a faster variant of his DFA decoder. It is only 10% slower than the branchless decoder with GCC, and it’s 20% faster than the branchless decoder with Clang. So, in a sense, it’s still faster on average, even on a benchmark that favors a branchless decoder.

所以作者最後也有說這是個嘗試而已 XD:

It’s just a different approach. In practice I’d prefer Björn’s DFA decoder.

Symfony 4 將放棄 HHVM

PHP 7.x 的效能已經趕上 HHVM (甚至在某些項目超越,參考下面的連結),這使得後來大家為了相容性與擴充性的考量,HHVM 的社群一直沒有成長 (參考「PHP Versions Stats - 2017.1 Edition」這邊,作者從 packagist.org 上得到的數據):

這使得 Symfony 決定在 Twitter 上蒐集意見,而後決定下一個 major version (4) 將不再支援 HHVM:「Symfony 4: End of HHVM support」。

馬上想到的是 Laravel 用了一堆 Symfony 的元件啊,之後應該會看到 Laravel 也開槍... 可以預料 HHVM 接下來會只剩下 Facebook 用,甚至過個幾年後有可能看到 Facebook 又換回 PHP (然後再打自己的 patch 上去)。

用 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 S3HDFS 的速度差異:「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 VersionAverage Page Load time
HTTP 1.x9.07 sec.
SPDY/3.17.06 sec.
HTTP/24.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 VersionPercentage of Hits
HTTP 1.x19.36%
SPDY/3.157.02%
HTTP/223.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.

Archives