幹壞事是進步最大的原動力
EC2 推出的新功能：「Amazon EC2 Auto Scaling introduces Warm Pools to accelerate scale out while saving money」。
重點只有這個，這個作法是先把機器準備好，然後關掉放在 stopped 狀態：
Additionally, Warm Pools offer a way to save compute costs by placing pre-initialized instances in a stopped state.
理論上可以快到 30 秒：
Now, these applications can start pre-initialized, stopped instances to serve traffic in as low as 30 seconds.
不過考慮到就算是 stopped 的機器，啟動時還是得去確認有沒有新版程式... 目前可以理解的部份，應該是加快 EBS 的準備時間吧？
這個功能在 ELB Classic 年代時有跟 AWS 提過，到 ALB 支援了 (總算...)：「Application Load Balancer Announces Slow Start Support for its Load Balancing Algorithm」。
Application Load Balancers now support a slow start mode that allows you to add new targets without overwhelming them with a flood of requests. With the slow start mode, targets warm up before accepting their fair share of requests based on a ramp-up period that you specify.
然後時間可以設定，從 30 秒到 15 分鐘：
Slow start mode can be enabled by target group and can be configured for a duration of 30 seconds to 15 minutes. The load balancer linearly increases the number of requests sent to a new target in a target group up to its fair share during the slow start ramp-up window.
就之前的經驗來說，這在跑 PHP 的時候會很需要這個功能 (之前是在 F5 的設備上設定)。其他的語言因為性質不太一樣，可能不會這麼吃這個功能。
主要是因為 PHP 是在 request 進來時 compile 並且 cache。所以在機器剛起來時，儘量將 CPU 留給 opcache，把常用的頁面 compile 完並且放進 cache，而不是讓大量的連線灌進來，這樣對使用體驗不會太好... (要避免 CPU 吃滿 100% 很久，造成每個連線都很慢才跑完)
AWS 推出 Slow Start 後對 auto scaling 時的順暢度會好不少...
Amazon 的其中一個辦公室拿隔壁 data center 的廢熱借來當自己辦公室的空調：「Amazon to use data centre waste heat to warm corporate offices」，原始報導在「The super-efficient heat source hidden below Amazon's Seattle headquarters」。除了嘗試省電省成本以外，對企業形象也比較好...
隔壁 Westin Building Exchange 的地址是「2001 6th Ave #300, Seattle, WA 98121」，辦公室則是在「2040 6th Ave, Seattle, WA 98121」，無論是從地址上看，或是 Google Maps 上可以看，都可以看出來兩棟就在旁邊而已，拉管線就簡單很多了。
預定二十五年省 80M 度電，所以一年大約是 3.2M 度，以「Seattle, WA Electricity Rates | Electricity Local」這邊給的數字來算，商業用店每度是 USD$0.068，每年大約省下 USD$217,600 (所以每年大約可以省下台幣六百萬)，以 3800 人的辦公室來說其實有點微妙，不過以 PR 的角度還看其實就很划算了 XDDD：
It is expected, over the course of 25 years, to save approximately 80 million kWh of electricity use by Amazon.
不知道這套系統花多少錢...
Percona 的人討論了 InnoDB 提供的 buffer pool preload 功能：「Using the InnoDB Buffer Pool Pre-Load Feature in MySQL 5.7」。
就如同他所講的，因為硬體設備的進步 (主要是 SSD 的興起)，而導致 preload 的需求已經沒以前重要了：
Frankly, time has reduced the need for this feature. Five years ago, we would typically store databases on spinning disks. These disks often took quite a long time to warm up with normal database workloads, which could lead to many hours of poor performance after a restart. With the rise of SSDs, warm up happens faster and reduces the penalty from not having data in the buffer pool.
由於 SSD 的 random read 很快，反而可以直接推上線讓他邊跑服務邊 warm up。不過相對的，傳統硬碟的 InnoDB database 還是可以規劃需求，畢竟 random read 還是痛點...
Percona 整理了一份 MySQL 5.6 到 5.7 改變的預設值，對於評估與轉移的人都很有用：「MySQL Default Configuration Changes between 5.6 and 5.7」。
sync_binlog 居然從 0 改成 1 了，這對效能的影響應該不少。
performance_schema_* 有不少改成自動調整了，可以省下不少功夫。
innodb_buffer_pool_dump_at_shutdown 與 innodb_buffer_pool_load_at_startup 都打開了，這避免了正常重啟時的 warm up 問題，不過在存在有效的手段可以手動 warm up 的時，應該還是會關掉吧。(參考 2013 的文章「熱 MySQL InnoDB 的方式...」)
另外介紹了 InnoDB 預設格式的改變，這點到是因為使用 COMPRESSED，反而不太受到影響。
之前寫過一篇「熱 MySQL 的方法...」，主要是利用 InnoDB 在 SELECT COUNT(*) 時會掃過一次 primary key 來熱：
pt-find --charset=utf8 --print -h $1 -u USER -p PASSWORD | xargs -t -P8 -I% -n1 sh -c "echo 'SELECT COUNT(*) FROM %;' | mysql -h $1 > /dev/null"
但想要熱整個表格時 (data 部份)，這個方法就不夠力了，今天才想到可以這樣做：
SELECT COUNT(*) FROM (SELECT * FROM table_name) t;
這方法會把整個表格資料拉出來，但又不會造成大量的網路 i/o (以及洗畫面)。實際測過後發現效果還不錯... (對於 table scan 使用量很大的表格，靠這個把整個表個塞進 InnoDB buffer)
看到 jnlin 寫的「利用 Percona Playback warm-up MySQL 資料庫...」，把之前用到的「用 pt-find 加熱 (暖機) InnoDB table」改良讓他可以平行跑，儘可能吃完 I/O capacity：
pt-find --charset=utf8 --print -h $1 -u USER -p PASSWORD | xargs -t -P8 -I% -n1 sh -c "echo 'SELECT COUNT(*) FROM %;' | mysql -h $1 > /dev/null"