最近換到 Firefox 後覺得開很多 tab 時很卡，但 CPU 也沒滿，大概是某種 lock/mutex/semaphore 機制導致硬體資源沒用完但是自己限制住...
找資料研究的時候發現 Firefox 對單一 server 的最大連線數是 6 個，而 Chrome 是 10 個：「Max parallel http connections in a browser?」。這對於網路速度夠的使用者就很卡，像是透過 RSS reader 同時對一個站台狂開分頁時就會卡住。
翻了一下 Firefox 的設定，找到相關的幾個設定，其中上面提到的是 network.http.max-persistent-connections-per-server，預設的確是 6 個，改成 10 個後測了一天好不少，決定改成跟 IE11 一樣的 13 個... (奇怪的數字)
另外一個是 network.http.max-connections，預設是 900 了，應該夠用...
Amazon Aurora 推出了 Parallel Query，可以加速計算速度：「New – Parallel Query for Amazon Aurora」。原理是利用 Aurora 把 storage 層打散的前提，所以有機會透過螞蟻雄兵處理：
官方給的範例可以連到原文去看，可以看到有打開 aurora_pq 與沒打開的效能差異：
15 rows in set (1 min 53.36 sec)
15 rows in set (1 hour 25 min 51.89 sec)
打開後大約是原來的 1/45 時間，提昇超多...
不過還是有些限制，我最在意的就是目前只支援相容於 MySQL 5.6 的版本 (居然不是先支援 5.7)：
Engine Support – We are launching with support for MySQL 5.6, and are working on support for MySQL 5.7 and PostgreSQL.
然後沒有多餘費用，只是 i/o cost 可能會增加：
Cost – You can make use of Parallel Query at no extra charge. However, because it makes direct access to storage, there is a possibility that your IO cost will increase.
AWS 宣佈了 Amazon Aurora (MySQL) 支援 Parallel Query：「Amazon Aurora Parallel Query is Available for Preview」。
這邊提到的 Parallel Query 比較像是 Amazon Athena，直接把單一 Query 打散到多台機器上跑：
Amazon Aurora Parallel Query improves the performance of large analytic queries by pushing processing down to the Aurora storage layer, spreading processing across hundreds of nodes.
也就是說，這算是單一 SQL Query 平行運算的進階版本。
在這之前，AWS 都已經支援單一 Query 在單台機器上利用多 CPU 平行運算。其中 PostgreSQL 是 9.6+ 本身就有支援。Amazon Aurora (MySQL) 則是在 2016 時透過 Parallel Read Ahead 支援某些情境下的的單一 Query 多 CPU 運算了 (發現之前沒寫到...)：「Amazon Aurora Update – Parallel Read Ahead, Faster Indexing, NUMA Awareness」。
這個功能目前是 Preview 階段，然後開在這些地區讓大家測試使用：
The preview is available for the MySQL-compatible edition of Amazon Aurora, and is currently available in the US East (N. Virginia), US East (Ohio), US West (Oregon), and Europe (Ireland) Regions. Sign up to get access.
這個功能提供了想要提昇效能，但懶得改架構的人可以用錢直接硬換出來...
Git 推出新版的時候，幾家 Git Hosting 都會撰文寫一些重要的進展，像是 GitHub 這次的內容：「Git 2.8 has been released」。
GitHub 這次說明平行下載的範例直接清楚表示出來功能：
git fetch --recurse-submodules --jobs=4
用 Google 找了一個 .gitmodules 裡面有很多筆的 repository 測了一下，的確是快了不少...
PostgreSQL 9.6 將會支援 Parallel Aggreation，在多 CPU core 下 aggreation operation 單一 query 的平行化效能改善 (改善非常多)：「pgsql: Support parallel aggregation.」：
Parallel workers can now partially aggregate the data and pass the transition values back to the leader, which can combine the partial results to produce the final answer.
在「Parallel Aggregate – Getting the most out of your CPUs」這邊有測試 worker 數量與執行的速度差異：
We performed some tests on a 4 CPU 64 core server with 256GB of RAM using TPC-H @ 100 GB scale on query 1. This query performs some complex aggregation on just over 600 million records and produces 4 output rows.
由於是 64 cores，所以作者測 1 到 64 workers 的效能，這是測試出來的結果：
要注意 Y 軸是對數比例，紅色是理論值，藍色是實際值，可以看出來平行化的效能頗不錯，雖然開到 64 workers 時效率已經不到一半了。
這對離鋒時間的報表運算超好用啊...
在「Parallel Sequential Scan is Committed!」這邊看到 PostgreSQL 9.5 (還沒出) 將會有 Parallel Sequential Scan 的功能。
文章的作者直接拿了一個大家超常用的惡搞來示範，也就是經典的 LIKE '%word%'：
rhaas=# \timing Timing is on. rhaas=# select * from pgbench_accounts where filler like '%a%'; aid | bid | abalance | filler -----+-----+----------+-------- (0 rows) Time: 743.061 ms rhaas=# set max_parallel_degree = 4; SET Time: 0.270 ms rhaas=# select * from pgbench_accounts where filler like '%a%'; aid | bid | abalance | filler -----+-----+----------+-------- (0 rows) Time: 213.412 ms
這功能真不錯 XD
在「Introducing mysqlpump」這邊提到了 MySQL 5.7 將會有 mysqlpump 這個新工具，主要是避免影響 mysqldump，但又可以產生容易平行處理的 dump data：
The goal of mysqlpump is to have a modern utility that is extendable and has native support for parallelization.
看了一下範例還蠻簡單的 (目標也很明確)，應該是之後的參考工具...
「Multithreaded Replication to the Rescue」這篇提到了 Replication 的 Parallel Worker 機制。
作者給了平行的數量對 replication lag 的影響：
可以看得出來 Parallel Worker 機制對 Replication Lag 改善頗大，不過作者在 comment 提到中雷了：「MTS breaks in after restart」。
對於還在使用 traditional master-slave 架構的人可以參考看看。
「MySQL Replication – Multi-Threaded Slaves (Parallel Event Execution)」這篇在講 MySQL 5.6 的 multi-threaded replication。
在文章裡提到，在 5.6.3 之前的版本，MySQL replication 都是 single-threaded，所以當 master 可以充分發揮多 CPU 能力時，slave 仍然要一個更新跑完才會跑下一個更新。
舉例來說，假設 master server 上有兩個 thread 在跑：
UPDATE table1 SET foo = 0 WHERE ...; (SQL 1，假定是 CPU bound，需要跑 100 秒)UPDATE table2 SET bar = 1 WHERE ...; (SQL 2，也假定是 CPU bound，也需要跑 100 秒)假設 thread 1 先執行完，這時候 slave 就會在跑完的時候收到 SQL 1，然後把資料同步進去。等到 100 秒過去後，再跑 SQL 2，再花 100 秒。這導致了最少 100 秒的 replication lag (master 與 slave 不同步的時間)。
在 master server 執行時會是這樣：
兩個 SQL query 可以同時跑。
到了 slave 時，在 MySQL 5.6.3 之前的 replication 會變成這樣：
可以看到還是得先執行 SQL 1 再執行 SQL 2，所以最長會有 200 秒的 replication lag。
而 5.6.3 之後支援 multi-threaded replication，可以用 slave_parallel_workers 指定平行執行 SQL query 的數量，這讓 master server 與 slave server 之間的 replication lag 降低不少：
在收到同步的 SQL 指令後就可以同時跑，這讓 replication lag 降到 100 秒。
不過還是要提，如果希望把資料同步問題降到最低，那麼 Galera Cluster 可以解的更徹底，不論是寫入的那台 master server，或是其他的 master server (在 Galera Cluster 架構裡都是為 master)，一律都是同步執行：
不會有 master server 與 slave server 不同步的問題，可以減少很多 application 層的麻煩...