電信商對 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[.]”


保護 macOS 的方法

在「drduh/macOS-Security-and-Privacy-Guide」這邊列出了許多保護方式,如果考慮到 APT 的話應該是個不錯的指南...



MyRocks 與 InnoDB 對於不同硬碟效能的差異

在「MyRocks: use less IO on writes to have more IO for reads」這邊有提到當使用 Disk Array、Slow SSD 與 Fast SSD 時效能 MyRocks 與 InnoDB 的效能差異。

可以看到當 I/O 層能提供的 IOPS capacity 愈高,MyRocks 與 InnoDB 之間的差異就愈低... 換句話說,RocksDB 對 IOPS 比較有效率的應用,這點在「Why is MyRocks more write-efficient than InnoDB?」這邊也可以看出一些說明 (不過這篇的 InnoDB 完全沒用 COMPRESSED)。

算是推銷... 不過可以持續關注看看 :o

InnoDB 的 Isolation Level 以及 Performance Schema 對效能的影響

雖然 Mark Callaghan 現在的主力都在 MyRocks 上,但他還是對 InnoDB 上的效能頗關注 (畢竟是個成熟而且競爭的產品)。而這篇「Sysbench, InnoDB, transaction isolation and the performance schema」講到 MySQL 5.6.26 裡的 InnoDB,了解 isolation level 與 performance schema 對效能的差異。結果可以在這邊翻到。

關掉 performance schema 會讓效能變好是預期的,不過看起來比預期小很多。另外某些情況下 RR (REPEATABLE-READ) 的效能會比 RC (READ-COMMITTED) 好倒是頗意外,這邊也有給出原因:

Using repeatable-read boosts performance because it reduces the mutex contention from getting a consistent read snapshot as that is done once per transaction rather than once per statement.

不過看了看數據,純粹讀取的部份 RC 會在某些地方快一些,不過整體來說在 MySQL 5.6.26 上的 RR 與 RC 差異真的不算太明顯了...

Amazon SQS 支援 FIFO 了

Amazon SQS 支援 FIFO 了:「FIFO (First-In-First-Out) Queues」。新的 FIFO Queue 有保證順序,但也因此效能上有限制:

In addition to having all the capabilities of the standard queue, FIFO (First-In-First-Out) queues are designed to enhance messaging between applications when the order of operations and events is critical, or where duplicates can't be tolerated. FIFO queues also provide exactly-once processing but are limited to 300 transactions per second (TPS).

可以看到舊版的 FAQ 對於 FIFO 的回答是 Standard Queue 會盡力做到 FIFO,但不保證:(出自 2016/08/26 的版本)

Q: Does Amazon SQS provide first-in-first-out (FIFO) access to messages?

Amazon SQS provides a loose-FIFO capability that attempts to preserve the order of messages. However, we have designed Amazon SQS to be massively scalable using a distributed architecture. Thus, we can't guarantee that you will always receive messages in the exact order you sent them (FIFO).

If your system requires the order of messages to be preserved, place sequencing information in each message so that messages can be ordered when they are received.

而現在則是名正言順的說有提供 FIFO 了:

Q: Does Amazon SQS provide message ordering?

Yes. FIFO (first-in-first-out) queues preserve the exact order in which messages are sent and received. If you use a FIFO queue, you don't have to place sequencing information in your messages. For more information, see FIFO Queue Logic in the Amazon SQS Developer Guide.

Standard queues provide a loose-FIFO capability that attempts to preserve the order of messages. However, because standard queues are designed to be massively scalable using a highly distributed architecture, receiving messages in the exact order they are sent is not guaranteed.

Amazon Aurora 支援 t2.medium...

Amazon Aurora 宣佈支援 t2.medium:「Use Amazon Aurora for Dev & Test Workloads with new T2.Medium DB Instance Class」。

雖然官方的文章標題是寫提供給 dev & test 情境下使用,但其實對於某些 production 應該也不錯:

The db.t2.medium should be a great fit for many of your development and test scenarios, and you should also consider them for some of your less-demanding production workloads.

沒提供更低的 t2.small 有點可惜...

Dropbox 在全球建機房加速...

Dropbox 為了加速傳輸,在全球到處建機房降低 latency:「Infrastructure Update: Pushing the edges of our global performance」。

就他們測試發現,透過 proxy server 降低 latency 的效果很不錯:

We’ve tested and applied this configuration in various markets in Europe and Asia. In France, for example, median download speeds are 40% faster after introducing proxy servers, while median upload speeds are approximately 90% faster. In Japan, median download speeds have doubled, while median upload speeds are three times as fast.


Amazon S3 與 Glacier 的降價...

這次 AWS 對 storage 類調降了不少幅度,包括了 S3Glacier:「AWS Storage Update – S3 & Glacier Price Reductions + Additional Retrieval Options for Glacier」。

S3 的部份降幅都不算低,要注意的是這次是 2016/12/01 開始,並沒有回朔:

We are reducing the per-GB price for S3 Standard Storage in most AWS regions, effective December 1, 2016.

另外 Glacier 則是大幅調降:

We are also reducing the price of Glacier storage in most AWS Regions. For example, you can now store 1 GB for 1 month in the US East (Northern Virginia), US West (Oregon), or EU (Ireland) Regions for just $0.004 (less than half a cent) per month, a 43% decrease. For reference purposes, this amount of storage cost $0.010 when we launched Glacier in 2012, and $0.007 after our last Glacier price reduction (a 30% decrease).

而 Glacier 取資料的方式也改成三種不同版本,主要是差在要等多久才能取得資料:

  • Standard (對應到本來的版本,通常約 3 到 5 個小時)
  • Expedited (速度快很多,一般的情況下約 1 到 5 分鐘,如果要保證的話可以買 Provisioned capacity)
  • Bulk (通常約 5 到 12 小時)


Amazon SES 的固定 IP 服務

怎麼這麼多消息啊... 這次是 Amazon SES 宣佈提供固定 IP 服務:「Amazon SES Now Offers Dedicated IP Addresses」。

這樣可以減少被其他人影響到 reputation,提昇穩定度:

Amazon Simple Email Service (Amazon SES) now offers dedicated IP addresses, which enable you to manage the reputation of the IP addresses that Amazon SES uses to send your email.


To request dedicated IPs, open an SES Sending Limits Increase Case in Support Center. In the use case details, specify that you are requesting dedicated IPs.

Linode 東京二號機房開幕

大家等 Linode 的東京新機房很久了,總算是開了:「New Linode Datacenter: Tokyo 2」。

在 comment 有特別提到東京一號機房不會擴充:

Tokyo 1 is at capacity and we have no plans to add any additional. You will need to move out of Tokyo 1 for plan upgrades, KVM, newest hardware, and so on.

該來搬了 XDDD