一味追求高併發效能表現?

我們是不是忘了真實世界存在的樣子?

Facebook 工程師,同時也是 MySQL 資料庫專家的 Mark Callaghan 表示,從 MySQL 5.6 到 5.7 乃至接下來的 8.0,都可以看到很多評比數據指出高併發工作 (high-concurrency workloads) 的效能表現愈來愈好。但一般人可能沒有注意到,低併發工作 (low-concurrency workloads) 的表現則是愈來愈差。

例如,MySQL 5.7 及 MySQL 8.0 的低併發工作表現只有 MySQL 5.6 的 60% ~ 70% (效能少了約三分之一)。

他呼籲除了不要忘了低併發工作表現外,也始終都致力發布並修補 MySQL 低併發工作的問題。雖然確實成功修補了很多,但 MySQL 整團開發團隊在效能比重上,仍然比較在意高併發上。

Peter Zaitsev,Percona (MySQL 知名顧問公司) 的共同創辦人兼 CEO 在 2013 年也寫過類似的言論

他指出低併發工作的表現也是很重要的。

  1. 有些業務情境非常重視 Response time,而併發數 1 通常都是最佳表現。若只追求高併發,會失去這個重要的市場。

  2. 很多情境都是單執行緒 (single-thread execution),例如很多批次工作 (batch jobs) 都是單執行緒;過去 MySQL Replication 也是單執行緒,雖然 MySQL 5.6 開始支援多執行緒,但在某些情況下,還是以單執行緒執行。

  3. 很多資料庫的維護操作都是單執行緒的,例如 “ALTER TABLE"。

所以,他認為,事實上大多數的時候,系統都是在低併發工作情境下運作。過度專注高併發工作表現,很容易在面對實際情況時誤判。例如,高併發表現明明就很好,為什麼系統上線時總是不理想?因為你忘了,系統實際面對的根本不是高併發,而是低併發的狀況。

總結,

  1. 軟體功能要求愈多,通常效能會愈來愈差。若效能只專注在高併發時,更可能犧牲的是低併發表現。

  2. 如果業務場景重視 Response time,或是非多核環境,一味把軟體升級到最新版,結果可能並非我們所想像的。

  3. 這不只是 MySQL 的問題,想想我們手中所依賴的各種軟體,開發者是不是有真正考慮到這個問題。至少 MySQL 團隊有人在意也專注解決。