小台機器上的 innodb_purge_threads 對效能的影響

雖然「MyISAM, small servers and sysbench at low concurrency」這篇標題是在講 MySQL 上的 MyISAM,但還是有提到一些 InnoDB 的東西...

其中提到了 innodb_purge_threads 對效能的影響:

the default value for innodb_purge_threads, which is 4, can cause too much mutex contention and a loss in QPS on small servers. For sysbench update-only I lose 25% of updates/second with 5.7.17 and 15% with 8.0.1 when going from innodb_purge_threads=1 to =4.

當機器不大的時候,innodb_purge_threads 對於效能帶來的影響其實頗大的?

另外從作者最近的一系列測試看起來,5.7 在小機器的效能比 5.6 差不少... 這點在考慮 RDS 的時候也許要注意 (因為 t2.* 應該不算大 XD)。

CloudFlare 推出 tag-based purge 功能

CloudFlare 推出這個功能很棒啊,不過這後面的資料結構必須設計的夠好才能這樣玩:「Introducing a Powerful Way to Purge Cache on CloudFlare: Purge by Cache-Tag」。

cache purge 一直都是 CDN 的痛處,用過的每一家 CDN 都在比慢的,大概都是 10 mins 起跳,但 CloudFlare 在這塊花了不少功夫:

可以想像到的方式是放入 user_gslin (在使用者停用時可以馬上更新) 或是 pic_id_1234567890 (可以針對各種縮圖一次刷新) 這樣的 tag 去歸類,然後就可以大規模刷...

Varnish 的 Super Fast Purger...

Reverse Proxy 的 Cache Infrastructure 在遇到 cache invalidate 都是很討厭的問題,不是不能做,而是效能不太好... 常見的作法是設計成不用 purge 的形式,只要是需要更新,就產生不同的 url,而舊的 url 在沒人 access 後會透過各種 Cache algorithms 自動回收掉,像是 LRU (Least Recently Used) 之類的演算法。

發展久了之後也因此衍伸出很多不同的架構,像是 groupcache 就是假設在同一個 address 的內容永遠不會變的前提。

Varnish Cache 這次發表的東西則是打算從根本問題解決,也就是想辦法讓 purge (cache invalidate) 的成本降低:「Simple scales better and faster in the real world」、「VAC 2.0.3 with high performance cache invalidation API (aka the Super Fast Purger)」。

官方的說法,在大台機器上可以到 60k reqs/sec:

Kristian nonchalantly mentioned that the Super Fast Purger did 60,000 requests per second, on a 6 core Xeon with 36GB memory, traffic over a gigabit network to a single Varnish Cache server, with httperf as test client. But we believe the Super Fast Purger can do a lot more with a little love and tuning.

Squid 效能不好,ATS 的文件很傷,是該找時間來測試看看...