幹壞事是進步最大的原動力
AWS 上的 Redis 服務 (Amazon ElastiCache) 推出了 Global Datastore，也就是跨區同步的功能：「Now Available: Amazon ElastiCache Global Datastore for Redis」。
技術上會分成 read endpoint 與 write endpoint (在最後面的操作可以看到 $US_WEST_1_CLUSTER_READWRITE 與 $US_WEST_2_CLUSTER_READONLY)，所以算是蠻常見的 primary-secondary 架構。
不過我基本上不太愛 Redis，能用 Memcached 解決的偏好用 Memcached 解。不過如果把 Redis 當作是一種雲端服務的話，倒是還可以接受...
在 Hacker News Daily 上看到蘋果的「Apple Edge Cache」這個服務，看起來就是個自家的 CDN 方案。
網路要求最低要能夠 peak 到 25Gbps 不算低，不過以蘋果的用量來說應該不算是高估：
Minimum 25 Gb/s peak traffic across all Apple traffic.
各家 ISP 應該都會考慮，畢竟 iPhone 與 iPad 的數量可不是假的，所以目前在台灣測到的點都是台灣的機房 (看 ping latency)...
另外一個有趣的事情是 SSL 的部份，從 SSL Labs 的資料可以看到一些有趣的東西：「SSL Report: cache.edge.apple (17.253.119.201)」。
一個是蘋果跟 GeoTrust 買了 Intermediate CA 再簽自己的 AEC 服務，另外一個是同時有 RSA 2048 bits 與 EC 256 bits 的 key，然後是支援 TLS 1.3 了。
跟其他內容業者的玩法類似，像是 Netflix 的 Open Connect。
看到「Base64 encoding and decoding at almost the speed of a memory copy」這個，可以超級快速編解碼 Base64 的資料。
實做上是透過 Intel 的 AVX-512 加速，在資料夠大的情況下 (超過 L1 cache 的大小)，可以達到接近字串複製的速度 (這邊提到的 memcpy())：
We show how we can encode and decode base64 data at nearly the speed of a memory copy (memcpy) on recent Intel processors, as long as the data does not fit in the first-level (L1) cache. We use the SIMD (Single Instruction Multiple Data) instruction set AVX-512 available on commodity processors. Our implementation generates several times fewer instructions than previous SIMD-accelerated base64 codecs.
不過這樣 AMD 暫時要哭哭...
上次是 2018 年五月把 PHP 換到 7.2 (參考「把 Blog 換成 PHP 7.2」)，這次是在整理機器時發現 blog 這台機器還在跑 7.2，就更新一下系統把上面的站台都換到 7.3。
蠻多人都測過效能了 (像是「The Definitive PHP 5.6, 7.0, 7.1, 7.2 & 7.3 Benchmarks (2019)」)，目前看到的資料都會快一些，應該是沒有太大問題，之後可以考慮再把 OPcache 的可用空間大小再降一些 (預設是 128 MB，但用 opcache-status 看起來只用了 65 MB 左右)，把記憶體空間讓給其他程式用...
不過 7.4 也快出了...
在「Prepare For Fewer Cache Hits As Chrome Partitions Their HTTP Cache」這邊看到的，Google Chrome 打算要拆開 HTTP Cache 以提昇安全性與隱私性。
有 cache 跟沒有 cache 可以從讀取時間猜測出來，這樣就可以知道瀏覽器是否有這個特定 url 的 cache。
在原文的作者所給的例子沒有這麼明顯，這邊舉個實際一點的例子來說好了... 我想要知道你有沒有看過 zonble 的「返校」這篇文章，我就拿這篇文章裡面特有的資源來判斷。
以這篇文章來說，我可以選擇第一張圖片的網址 https://i0.wp.com/c1.staticflickr.com/1/603/31746363443_3c4f33ab18_n.jpg?resize=320%2C200&ssl=1 這個 url 來判斷讀取時間，藉此我就可以反推你有沒有看過這篇文章，達到攻擊隱私的效果。
解決的方法就是作者文章裡所提到的方法，把 HTTP cache 依照不同的網站而分開 (在 Safari 已經支援這個功能，而 Firefox 正在研究中)。
當然這樣做應該會對流量有些影響，但考慮到這些日子有很多新技術可以增加下載速度，這個功能應該是還能做...
這篇是 StackOverflow 在講 cache 的文章，裡面不是什麼新東西，只是看到有趣的項目所以拿出來講：「How Stack Overflow Caches Apps for a Multi-Tenant Architecture」。
在講 cache 前通常都會說明各種儲存空間速度的差異，但裡面混了一個奇怪的東西：
裡面混了一個不是 storage 的東西進去比較，你們是對 Microsoft 的帳號系統有多不爽 XDDD
另外他們列出了目前 Redis 的使用情況：
For the curious, some quick stats from last Tuesday (2019-07-30) This is across all instances on the primary boxes (because we split them up for organization, not performance…one instance could handle everything we do quite easily):
- Our Redis physical servers have 256GB of memory, but less than 96GB used.
- 1,586,553,473 commands processed per day (3,726,580,897 commands and 86,982 per second peak across all instances – due to replicas)
- Average of 2.01% CPU utilization (3.04% peak) for the entire server (< 1% even for the most active instance)
- 124,415,398 active keys (422,818,481 including replicas)
- Those numbers are across 308,065,226 HTTP hits (64,717,337 of which were question pages)
然後更長的版本可以在作者自己的 blog 上讀到，裡面講到的 cache invalidate (purge) 這部份有談到一些他們的作法：「Stack Overflow: How We Do App Caching - 2019 Edition」。
從「Compressed favicons are 70% smaller but 75% of them are served uncompressed」這邊看到的，他們發現大約有 73.5% 的網站沒有壓縮 favicon.ico 檔：
The HTTP Archive dataset of favicons from 4 million websites crawled from desktop devices on May 2019 shows that 73,5 % of all favicons are offered without any compression with an average file size of 10,5 kiB, 21,5 % are offered with Gzip compression at an average file size of 4 kiB, and 5 % offer Brotli compression at an average file size of 3 kiB.
我自己的也沒加... 補上 gzip 相關的設定後，favicon.ico 的傳輸量從 4.2KB 降到 1.2KB。
我是使用 nginx，在 Ubuntu 上 nginx 的 nginx.conf 內 gzip 預設已經有開，所以只要增加一些設定讓他知道要處理 ico 檔案就可以了。
方法是在 /etc/nginx/conf.d/gzip.conf 裡面放：
gzip_comp_level 9; gzip_types image/vnd.microsoft.icon image/x-icon; gzip_vary on;
跟文章裡面提到的多了兩個設定，一個是 gzip_comp_level 改成 9 (預設是 1)，另外有 gzip 時應該要在 Vary 表示，避免 cache 出錯。
在「Live video just got more live: Introducing Concurrent Streaming Acceleration」這邊 Cloudflare 說明他們改善了同時下載同一個 cache-miss 檔案時的效率。
本來的架構在 cache-miss 時，CDN 這端會先取得 exclusive lock，然後到 origin server 抓檔案。如果這時候有其他人也要抓同一個檔案，就會先卡住，避免同時間對 origin server 產生大量連線：
這個架構在一般的情況下其實還 ok，就算是 Windows Update 這種等級的量，畢竟就是一次性的情況而已。但對於現代愈來愈普及的 HTTP(S) streaming 技術來說，因為檔案一直產生，這就會是常常遇到的問題了。
由於 lock 機制增加了不少延遲，所以在使用者端就需要多抓一些緩衝時間才能確保品質，這增加了直播的互動延遲，所以 Cloudflare 改善了這個部分，讓所有人都可以同時下載，而非等到發起的使用者下載完才能下載：
沒有太多意外的，從 Cloudflare 內部數字可以看出來這讓 lock 時間大幅下降，對於使用者來說也大幅降低了 TTFB (time to first byte)：
不確定其他家的情況...
先前知道不少單位會選擇用 CloudFront 的原因就是 S3 到 CloudFront 這段是不需要傳輸費用的。畢竟 CDN 的 hit rate 還是有限，用其他家 CDN 得付這塊費用。
而現在 Backblaze 宣佈跟 Cloudflare 合作，免除掉 Backblaze 到 Cloudflare 的費用：「Backblaze and Cloudflare Partner to Provide Free Data Transfer」。
Today we are announcing that beginning immediately, Backblaze B2 customers will be able to download data stored in B2 to Cloudflare for zero transfer fees.
AWS 這邊會不會有其他動作呢...
Twitter 上看到 Python 3 內建的 lru_cache()：
One of my favorite Python 3 builtins is functools.lru_cache(): with a simple decorator, repeated function calls become O(1) table lookups. https://t.co/ORphGWvkCz pic.twitter.com/NmYVIxO9mE
— Jake VanderPlas (@jakevdp) August 8, 2018
從文件上可以看到預設值是 128 個：
@functools.lru_cache(maxsize=128, typed=False)
tweet 裡面有討論到 memory leak 的問題可以看一下，不過如果是拿來寫工具的話，應該不會有什麼問題...