Tag: rate

Reddit 在處理 Page View 的方式

Reddit 說明了他們如何處理 pageview：「View Counting at Reddit」。

以 Reddit 的規模有提到兩個重點，第一個在善用 Redis 的 HyperLogLog 這個資料結構，當量大的時候其實可以允許有微小的誤差：

The amount of memory varies per implementation, but in the case of this implementation, we could count over 1 million IDs using just 12 kilobytes of space, which would be 0.15% of the original space usage!

維基百科上有說明當資料量在 109 這個等級時，用 1.5KB 的記憶體只有 2% 的誤差值：

The HyperLogLog algorithm is able to estimate cardinalities of > 109 with a typical error rate of 2%, using 1.5 kB of memory.

第二個則是寫入允許短時間的誤差 (pageview 不會即時反應)，透過批次處理降低對 Cassandra cluster 的負荷：

Writes to Cassandra are batched in 10-second groups per post in order to avoid overloading the cluster.

可以注意到把 Redis 當作 cache 層而非 storage 層。

主要原因應該跟 Redis 定位是 data structure server 而非 data structure storage 有關 (可以從對 Durability 的作法看出來)，而使用 Cassandra 存 key-value 非常容易 scale，但讀取很慢。剛好兩個相輔相成。

GitHub Apps (前身 GitHub Integrations) 的 Rate Limiting 變得更彈性

GitHub 宣佈了把 GitHub Integrations 改名為 GitHub Apps，另外 Rate Limiting 變得更彈性：「GitHub Apps (formerly Integrations) General Release」。

All GitHub Apps start with a rate limit of 5000 requests per hour. To facilitate growth we have added a dynamic rate limit for installations: organization installations with more than 20 users receive another 50 requests per hour for each user. Installations that have more than 20 repositories receive another 50 requests per hour for each repository.

所以對於超過 20 個使用者以及超過 20 個 repository 的 organization 都會增加 Rate Limiting。每個單位增加 50 requests/hour 不算太多，不過想一下好像也不少... (尤其對大一點的團體來說)

Backblaze 2017Q1 對硬碟的分析

Backblaze 放出 2017Q1 對硬碟的分析資料：「Hard Drive Stats for Q1 2017」。

相較於之前的報告 (Backblaze Hard Drive Stats for 2016)，這次則是把硬碟數量考慮進去，做了一份有正負誤差的：

最近的趨勢沒什麼變，整體上來看 HGST 的品質還是最好的。

超越線性成長的資料庫架構

標題取自 Percona 的「Better Than Linear Scaling」。

其實是因為機器數量增加，而且有妥善規劃，使得 cache 的 hit rate 上升而讓整體效率變好 (也就是 1 + 1 > 2)。

不只在 database 上會發生，在其他系統上其實會有類似的情況，剛好看到覺得很懷念 XD

Stripe 對於控制 API 使用量的作法

在「Scaling your API with rate limiters」這篇 Stripe 的 Paul Tarjan 提到了四種如何保護 API 的作法。

前兩種都是 rate limit。第一種是最標準的「你一分鐘可以用幾次」的方式，這是最容易理解的方式。第二種是「你同時間可以用幾個 API request」，這通常會用在大量消耗資源的 API 上，避免短時間內被打爆。

第三種是拉到整體來看，把 API 分成重要與不重要的，然後直接保留確保重要的 API 有一定的 capacity 可以用：

We always reserve a fraction of our infrastructure for critical requests. If our reservation number is 20%, then any non-critical request over their 80% allocation would be rejected with status code 503.

第四種方式是當過載時的自動化處理，平常就把各種工作排優先順序，當超量的時候自動先將低優先權的拿掉：

Only 100 requests were rejected this month from this rate limiter, but in the past it’s done a lot to help us recover more quickly when we have had load problems. This load shedder limits the impact of incidents that are already happening and provides damage control, while the first three are more preventative.

不過還是有點怪，Stripe 應該是全部都建在 AWS 上面 (AWS Case Study: Stripe)，跟 auto scaling 的配合好像都沒提到？

歸類的方式還蠻有條理的，可以學這個方法來規劃...

Google Chrome 55 的記憶體改善

前陣子 Google Chrome 55 出了，其中最讓人期待的是對記憶體的改善，有人整理了數據：「Chrome 55 uses ~30% less memory than Chrome 54」。

依照作者拿 weather.com 與 reddit.com 測試，前者的記憶體省了 26%，後者省了 30%，都相當明顯。我自己在升到 55 後有明顯感覺到改善，尤其是重開 Chrome 時重新讀取頁面的速度也快了不少...

這些改善主要是出自於「Fall cleaning: Optimizing V8 memory consumption」這邊提到對 V8 engine 的改寫，我感覺到速度變快應該是記憶體用量降低使得 CPU cache rate 提高的關係吧...

電信商對 Zero Rating 與網路中立性的問題

在「AT&T users will be able to stream DirecTV Now without using their data」這邊才看到 FCC 在這個月月初針對電信商對特定服務的 zero rating 發出警告：「The FCC tells AT&T it may be violating net neutrality with its DirecTV plans」：

AT&T is far from the only US carrier to zero rate data. T-Mobile has been ostentatiously offering free data for music and movies for a year now, and Verizon also zero rates video from its Go90 app. But in zero rating DirecTV, the FCC thinks AT&T may have gone too far.

AT&T 說任何人只要付錢都可以參加這個 plan：

AT&T’s argument is that any company that participates in its Sponsored Data program has to pay AT&T for it, and that includes DirecTV.

但問題還是在 AT&T 擁有 DirecTV，所以是左手付到右手：

Except, again, AT&T owns DirecTV, so even if one division is paying another, the overall company still ends up not paying any money.

而且這筆金額其實不小：

The situation for other companies is very different — and the FCC believes that the price they’d have to pay is “significant[.]”

不過總統快換人了，很有可能會往更糟的方向前進...

AWS 美東第二區開放

如同之前 AWS 的規劃，宣佈啟用美東第二區了 (us-east-2，在俄亥俄州)：「Now Open – AWS US East (Ohio) Region」。看了一下 EC2 的價錢，與 us-east-1 是同一個級別的，其他的服務應該是都差不多...

另外因為跨州了 (而且跟 us-east-1 很近)，所以官方也推薦拿來做異地服務：

With just 12 ms of round-trip latency between US East (Ohio) and US East (Northern Virginia), you can make good use of unique AWS features such as S3 Cross-Region Replication, Cross-Region Read Replicas for Amazon Aurora, Cross-Region Read Replicas for MySQL, and Cross-Region Read Replicas for PostgreSQL.

其中有個特別的地方在於 us-east-{1,2} 之間傳輸的費用會以 Inter-AZ 計費，而非以跨 region 計費。大概是希望讓大家有動力多放些東西過去，畢竟 us-east-1 實在太大，穩定性超有名的關係 XDDD：

Data transfer between the two Regions is priced at the Inter-AZ price ($0.01 per GB), making your cross-region use cases even more economical.

Adblock 與 Paywall 帶來的影響

這邊探討了新聞網站引入 Adblock 反制與 Paywall 帶來的影響：「Sites that block adblockers seem to be suffering」。

作者拿了 WIRED、Bild (Axel Springer)、Forbes、City AM 以及 Washington Post 的 Alexa 數字來歸納，可以看出新聞網站的取代率太高 (甚至看不到就算了)，可以看到 bounce rate 大幅增加 (很多人發現不能看就不會繼續看下去)，而且 pageview 也大幅下降。

WIRED：

Bild：

Forbes：

City AM：

Washington Post：

不過文章還是很粗糙，有太多變數沒有考慮進去...

Let's Encrypt 宣佈脫離 Beta

Let's Encrypt 宣佈脫離 beta，正式開放：「Leaving Beta, New Sponsors」。

翻資料的時候發現在今年 3/26 的時候，限制已經放寬了：「Rate Limits for Let’s Encrypt」。

首先一張證書只能包括 100 個 hostname，跟原來相同：

Names/Certificate is the limit on how many domain names you can include in a single certificate. This is currently limited to 100 names, or websites, per certificate issued.

再來是每個禮拜可以申請的數量從 5 個 hostname 變成 20 個，另外本來 renew 也算 quota，現在變成不會吃到 quota：

Certificates/Domain limits how many certificates can be issued that contain a single registered domain*.
This is limited to 20 certificates per domain per week. Exception: When you request a certificate with the same exact set of FQDNs as previously-issued certificate, this rate limit does not apply, but the one below does.

不知道會不會再放寬限制...