在「Scaling Time Series Data Storage — Part I」這篇看到 Netflix 在 Time Series Data Storage 上所做的努力...
因為應用在寫多讀少的場景，所以選擇使用 Cassandra，遇到瓶頸後把常寫入的與不太會改變的拆開儲存，並且用不同方式最佳化。包括了 cache 與 compression 都拿出來用了...
不知道他們內部有沒有評估 ScyllaDB 的想法...
Tag: time
Home » Posts tagged "time" (Page 2)
針對 Ubuntu 16.04 + PPPoE 時，OpenNTPD 的 -s 不會在啟動時直接校正的問題 workaround...
發現機器時間跟標準時間差了 40 秒左右，結果有些服務因為會看雙方時間，就不讓我跑... XDDD
找問題找了半天，發現開機後 ntpdate 會回報找不到伺服器，看起來是網路根本就還沒通就跑起來了：
Jan 25 13:10:30 home ntpdate[757]: name server cannot be used: Temporary failure in name resolution (-3) Jan 25 13:10:30 home ntpdate[1171]: name server cannot be used: Temporary failure in name resolution (-3) Jan 25 13:10:30 home ntpdate[1347]: name server cannot be used: Temporary failure in name resolution (-3) Jan 25 13:10:30 home ntpdate[1410]: name server cannot be used: Temporary failure in name resolution (-3)
而理論上 與 openntpd 加上 -s 也會做類似的事情，所以這邊就在 /etc/default/openntpd 先加上 -s，讓他開機時強制對時一次，看看能不能解... 結果也是一樣在網路還沒通的時候就跑起來而失敗了：
Jan 25 13:10:45 home ntpd[1457]: no reply received in time, skipping initial time setting
由於這台機器是 HiNet 的 PPPoE，看起來有可能是某些條件沒寫好，造成執行順序不對... 所以就找個 workaround 來解決 @_@
後來找的方法是直接到 /etc/ppp/ip-up.d/ 下放一個 script 實作 workaround，直接在 PPPoE 連上後重跑 openntpd，然後用 hwclock 寫回主機裡，下次開機的時間就會比較準一些了：
#!/bin/sh -e /usr/sbin/service openntpd restart /sbin/hwclock -w
不過實際上還是要找看看要怎麼把 PPPoE 掛到 networking 那層行為裡面...
Microsoft 的 TTD 與 Mozilla 的 RR
也是個在瀏覽器 tab 上放了一陣子的連結... 先前看到 Microsoft 的 Time Travel Debugger (TTD)，可以錄下程式執行的狀態，然後回放與搜尋：「Thoughts On Microsoft's Time-Travel Debugger」，另外有 CppCon 2017 上的影片，在 YouTube 上：
另外 Mozilla 也有類似的工具，叫做 rr (在影片開頭就有人問類似的問題 XD)，程式碼在 GitHub 上：「mozilla/rr」。
而 TTD 與 rr 兩者最大的差異當然是平台支援的情況：
The most important and obvious difference between TTD and rr is that TTD is for Windows and rr is for Linux (though a few crazy people have had success debugging Windows applications in Wine under rr).
但另外一個也很重要的差異是 TTD 支援完整的 multi-threading，這對於現代的程式來說還蠻常見的：
TTD supports recording of multiple threads in parallel, while rr is limited to a single core.
當然，更完整的錄影也是要付出效能代價的：
On the other hand, per-thread recording overhead seems to be much higher in TTD than in rr. It's hard to make a direct comparison, but a simple "start Firefox, display mozilla.org, shut down" test run on similar hardware takes about 250 seconds under TTD and 26 seconds under rr.
不過有需要的時候應該會很方便？工具總是愈多愈好...
TP-Link 的 NTP 流量
在「TP-Link repeater firmware squanders 715 MB/month」這邊看到 TP-Link 因為 NTP 的關係而狂吃流量的情況：(這邊是用逗點表示小數點，所以是 715.4 MB/month)
You should probably avoid TP-Link products if you’re on a tight bandwidth budget. By design, TP-Link firmware sends six DNS requests and one NTP query every 5 seconds, for a total of 715,4 MB per month.
如果拿 24 小時都開機的 Windows 相比的話，會發現這數字天差地別：
To put this number in context: an always-on Windows device will use around 1,6 KB per month on NTP.
作者抓出韌體上面的設定，發現裡面寫死了不少伺服器... 那個 au 與 nz 的選擇讓人頗好奇，另外直接把幾個大學的 NTP server 放進去不知道是什麼樣的想法：
TP-Link has hardcoded the following non-configurable NTP servers and server pools in their firmware:
- time.nist.gov, time-a.nist.gov, time-b.nist.gov, time-nw.nist.gov
- au.pool.ntp.org, nz.pool.ntp.org
- 133.100.9.2, 128.138.140.44, 192.36.144.22
The first sets of servers are operated by the US National Institute of Standards and Technology (NIST). The second is the Australian and New Zealand public NTP project time server pools. The IP addresses are owned by universities in Japan, Colorado; US, and Sweden respectively.
而從行為可以看到沒有遵守這些 NTP service 的規範：
The NTP Pool project asks device manufacturers and vendors to register (and optionally sponsor) their own pools through the service (e.g. tplink.pool.ntp.org), and emphasize that they “must absolutely not use the default pool.ntp.org zone names”. They also request that vendors don’t check more often than every 5 minutes at the most.
而且因為沒有地方可以修改這些設定，唯一的解法是不要買 TP-Link 的產品：
You can avoid buying TP-Link products to avoid this problem.
You can’t turn this behavior off in TP-Link’s web administration interface nor in their management app for mobile. You can’t change the NTP server addresses it targets either.
Amazon CloudWatch 支援縮放與拖拉調整時間區間
Amazon CloudWatch 的操作上支援 Zoom 與 Pan 了：「Amazon CloudWatch now supports two new chart visualization options in metrics and dashboards」。
Zoom 是改變時間的粒度：
You can use the CloudWatch console to graph metric data generated by AWS services and your applications. Now, you can zoom into a shorter time period such as one minute or five minutes while viewing the metric graph at a longer interval.
Pan 則是維持一樣的粒度，但改變開始與結束的時間：
Once zoomed, you can also pan the metric graph across your selected interval, but at a zoomed detail level.
變得更容易操作，而不用滑鼠移過去修改...
英文母語的人學習外語所需的時間
這個報導蠻有趣的：「A Map Showing How Much Time It Takes to Learn Foreign Languages: From Easiest to Hardest」。
文章裡分成這幾種：(扣除已經是母語的英語，Category 0)
- Category I: 23-24 weeks (575-600 hours) Languages closely related to English
- Category II: 30 weeks (750 hours) Languages similar to English
- Category III: 36 weeks (900 hours) Languages with linguistic and/or cultural differences from English
- Category IV: 44 weeks (1100 hours) Languages with significant linguistic and/or cultural differences from English
- Category V: 88 weeks (2200 hours) Languages which are exceptionally difficult for native English speakers
其中時間最長的這部份引用一下：
Arabic
Cantonese (Chinese)
Mandarin (Chinese)
*Japanese
Korean
* Usually more difficult than other languages in the same category.
AWS 環境裡面提供 NTP Service 了 (Amazon Time Sync Service)
以前在 AWS 環境裡都要自己架設兩台可以連外的 NTP server，然後將內部機器指到這兩台上，現在可以用現成的了：「Keeping Time With Amazon Time Sync Service」。
服務放在 169.254.169.123：
You can access the service via the link local 169.254.169.123 IP address. This means you don’t need to configure external internet access and the service can be securely accessed from within your private subnets.
然後也有提到 leap second 的解法，用的解法是 leap smearing：
Leap seconds are known to cause application errors and this can be a concern for many savvy developers and systems administrators. The 169.254.169.123 clock smooths out leap seconds some period of time (commonly called leap smearing) which makes it easy for your applications to deal with leap seconds.
先前 AWS 也有 leap time，但不包括 Amazon EC2 這些系統 (EC2 裡的時間是獨立的)，不過還是可以看一下 AWS 處理 leap time 的方式，因為這次 NTP Service 就會拿去用了。
最近一次 leap time 是 2016 年底的「Look Before You Leap – December 31, 2016 Leap Second on AWS」，處理的方式跟 2015 年時的方法還是一樣：「Look Before You Leap – The Coming Leap Second and AWS (Updated)」。
類似於下圖左上角這張的變化：
然後全區開放，都可以用了：
This service is provided at no additional charge and is immediately available in all public AWS regions to all instances running in a VPC.
Netflix 對 Landing Page 的效能改善計畫...
幹掉 React (噗)：
Removing client-side React.js (but keeping it on the server) resulted in a 50% performance improvement on our landing page pic.twitter.com/vM7JhWhYKu
— Netflix UI Engineers (@NetflixUIE) October 26, 2017
官方帳號丟戰文出來... 後面就有人開始亂 XDDD
everyone keeps talking about this PlainJS framework, guess I need to learn it. is it on @npmjs?
— swyx 🇸🇬 (@swyx) October 26, 2017
不過先拉回來看... 依照說明，其他頁面都還是跑 React，只有 Landing Page 被改寫，看起來 Landing Page 的 TTI (Time to Interactive) 是他們的 KPI，所以就被拿出來另外處理了...
當然也有可能有其他的陰謀論 (而且我覺得可能性是在的)：因為之前 React 的專利問題，變成之後 Facebook 如果真的出手提出告訴，會以惡意侵權來告 (因為鬧這麼大以後，沒有理由裝作不知道了)。這次只換 Landing Page 可以當作是試水溫練功 (累積 migration 的經驗)，後續再換內頁...
Firefox 的 Input 要支援 Date/Time 格式了
在 Hacker News Daily 上看到六月的文章，看起來是 Firefox 下一個版本要支援所以冒出來了：「Date/Time Inputs Enabled on Nightly」。
然後支援多國語系：(官方拿的範例剛好就是中文)
依照 MDN 上的說明「<input type="date">」以及 Can I Use 往站上的說明「Can I use Date and time input types」，可以看到這樣又多了一個瀏覽器啦：
Safari 被稱為新世代的 IE 真不是蓋的 XDDD
Facebook 在 MySQL 裡存時間的型態
在 MySQL at Facebook 的這邊說明提到了，Facebook 內部是使用 INT UNSIGNED 儲存時間：
Which gets us to the point that it is no different than storing INT (hello 2038?) or UNSIGNED INT (a bit later) or BIGINT (till the end of time) and possibly passing binary values in efficient protocols eventually.
If you got that far of this post, your likes in Facebook graph are stored with 'INT UNSIGNED' time field.
順道一提，INT 是 2038 年問題，INT UNSIGNED 是 2106 年問題。
而 Facebook 在 MySQL 上會選擇不使用 DATETIME 與 TIMESTAMP 的原因其實跟技術搭不上太多關係，主因是因為 MySQL 根本沒打算修 XDDD
It is my favorite MySQL bug, simply because it forces any reasonable mind not to use TIMESTAMP, and MySQL is never going to fix it (nor will ever understand time). I lost my temper a bit on that bug: https://bugs.mysql.com/bug.php?id=38455
我的猜測是已經爛成一團了，而且大家都有 workaround (呃，其實就是 Facebook 推薦用 INT UNSIGNED 的方法)，再考慮到有一票現有程式，在上面狂用 side effect 讓執行結果正確，不如就不要修這種吃力不討好的東西了 XDDD
另外一方面 timezone 資訊其實常常變化，常常需要更新 MySQL 的 timezone database (而這對於維運來說不是什麼開心的事情)：
There're few ways around that. One of them is side-load and maintain timezone data inside MySQL itself - it has support for internal timezone database and tracks obscure time shifts like ones for "Pacific War Time" and "Pacific Peace Time". That is operationally feasible (you have to remind yourself to update the database whenever time rules change, and they do change a lot, if you consider every timezone in the world), but has limited value.
這就是為什麼大家遇到 MySQL 時都會推薦用 INT UNSIGNED 了...
另外可以參考三年前的文章「MySQL 裡儲存時間的方式...」，裡面引用了 Baron Schwartz 的說明：
All date and time columns shall be
INT UNSIGNED NOT NULL, and shall store a Unix timestamp in UTC.
其實這已經是個 best practice 了...