Internet 上的 3rd party js 的情況

Twitter 上看到這則:

裡面提到了「patrickhulce/third-party-web」的分析 (作者是從 HTTP Archive 的資料分析),裡面依照不同種類的 3rd party js (像是 ad,或是 social element,或是分析工具) 需要執行的時間,以及使用的站台數量。

Social 那邊意外看到 PIXNET 有上去,然後速度只比 Disqus 快一些,應該是沒有 optimize 的關係。

如果整體一起看的話 (總和花費時間),可以看到 Google 各項產品都在最前面,畢竟裡面每個項目都是被廣泛使用的。

WireGuard 上 macOS 了...

在「WireGuard for macOS」這邊看到 WireGuard 進到 Apple 家的 Mac App Store 了。

除了是透過 app store 下載外,另外的重點在於整合了 NetworkExtension API

This is built from the same code base as our existing iOS app and makes use of Apple's Network Extension API to provide native integration into the operating system's networking stack.

這樣可以確保相容性,而且可以用內建的 VPN 機制管理。另外也給了一些 screenshot 可以看,可以看出來就是走 Mac 上的管理方式:

openrsync

在「openrsync imported into the tree」這邊看到 openrsync 專案進入到 OpenBSD 的 source tree 內。

rsync 是使用 GPLv3 授權,這個授權剛出來的時候,幾個比較大的 BSD 的團隊都有找律師研究過,最後都是做出不要把 GPLv3 的軟體放進 source tree 的建議,但 rsync 算是很好用的工具 (尤其是在效率上)。

看起來 openrsync 這個專案主要的目的就是重新實做出 ISC license 版本的 rsync:

This is an implementation of rsync with a BSD (ISC) license. It's compatible with a modern rsync (3.1.3 is used for testing, but any supporting protocol 27 will do), but accepts only a subset of rsync's command-line arguments.

然後目前只有設計在 OpenBSD 上跑,其他平台可能需要花些時間 porting 修正相容性:

At this time, openrsync runs only on OpenBSD. If you want to port to your system (e.g. Linux, FreeBSD), read the Portability section first.

GitHub 上的 Git repository 只是個 mirror,真正在管理程式碼的部份還是使用 CVS

This repository is a read-only mirror of a private CVS repository. I use it for issues and pull requests. Please do not make feature requests: I will simply close out the issue.

AWS 推出新的 Bare Metal Instances

AWS 針對各個 family type 都推出 Bare Metal 版本:「Now Available – Five New Amazon EC2 Bare Metal Instances: M5, M5d, R5, R5d, and z1d」。

AWS 第一次推出 Bare Metal 版本是在 2017 年年末推出的 i3.metal:「Amazon EC2 推出第一款 Bare Metal 的 Instance」,這樣算一算也一年多了,這次算是補產品線...

要注意的是,這次推出依照區域有不同的機種,像是 Ohio 沒有 z1d.metal 但有其他四種,N. California 則是沒有 m5d.metal 但有其他四種... 要先看一下表格才能確認每一區的情況 @_@

Amazon EFS 的 IA Storage Class

Amazon EFS 一直找不太到好用的使用情境,因為 NFS 的關係所以大量 I/O 時的 latency issue 使得速度快不起來,而拿來堆 log 的成本又超級高...

最新推出的 storage class 則是透過提供低儲存成本的版本,解決了堆 log 這種使用情境:「New – Infrequent Access Storage Class for Amazon Elastic File System (EFS)」。

不過 EFS 不像 S3 可以直接選擇 storage class,是需要讓系統管理的:

開啟後 30 天沒有被碰過的檔案就會切過去:

Eligible Files – Files that are 128 KiB or larger and that have not been accessed or modified for at least 30 days can be transitioned to the new storage class. Modifications to a file’s metadata that do not change the file will not delay a transition.

而 latency 也會增加:

Files that have not been read or written for 30 days will be transitioned to the Infrequent Access storage class with no further action on your part. Files in the Standard Access class can be accessed with latency measured in single-digit milliseconds; files in the Infrequent Access class have latency in the double-digits.

us-east-1 為例子來說,Standard 是 USD$0.3/GB-month,而 IA 只要 USD$0.045/GB-month,但抓取時會有 USD$0.01/GB 的傳輸費用,可以看出價錢低不少。

不過文章裡沒提到什麼時候會把資料從 IA 跳回 Standard,可能得找機會問問看...

從 Microsoft SQL Server 轉移到 PostgreSQL 的工具

在「How to Migrate from Microsoft SQL Server to PostgreSQL」這邊看到作者的客戶需要把 Microsoft SQL Server 轉移到 PostgreSQL (但沒有提到原因)。

裡面主要是兩個階段的轉換,第一個階段是 schema 的轉換,作者提到了 dalibo/sqlserver2pgsql 這個用 Perl 寫的工具:

Migration tool to convert a Microsoft SQL Server Database into a PostgreSQL database, as automatically as possible http://dalibo.github.io/sqlserver2pgsql

第二個階段是資料的轉換,是選擇用 Pentaho Data Integration 的 Community Edition:

Pentaho offers various stable data-​centric products. Pentaho Data Integration (PDI) is an ETL tool which provides great support for migrating data between different databases without manual intervention. The community edition of PDI is good enough to perform our task here. It needs to establish a connection to both the source and destination databases. Then it will do the rest of work on migrating data from SQL server to Postgres database by executing a PDI job.

所以用兩個工具串起來... 另外在文章裡面沒提到 stored procedure 之類的問題,應該是他們的客戶沒用到或是很少用到?

PostgreSQL 對 fsync() 的行為傷腦筋...

FOSDEM 2019 上的演講,討論 PostgreSQL 在確保 ACID 特性中的 Durability 時遇到 fsync() 的行為跟預想的不一樣 (主要是當 fsync() 失敗的行為):「PostgreSQL vs. fsync」。

在「PostgreSQL vs. fsync. How is it possible that PostgreSQL used fsync incorrectly for 20 years, and what we'll do about it.」這邊的 Q&A 形式的訪談有快速描述了短期的計畫與長期的想法:

The short-term solution is ensuring that we detect fsync errors reliably at least on sufficiently recent kernels (since 4.13). On older kernels we can’t do much better, unfortunately.

The long-term solution is still being discussed in the community, but it’s hard to say how we could keep relying on buffered I/O in the future. So we may end up with direct I/O, but that’s a pretty significant change and is likely going to be a multi-year project.

MySQL 這邊則是以 O_DIRECT 為主的世界,受到的影響就小很多了...

實際比較 Linode 的 Dedicated 主機與 AWS 的 c5.*

先前有提到 Linode 出了 Dedicated 主機:「Linode 推出 Dedicated CPU Instances」,現在找機會測試看看,拿了 Linode 的 Dedicated (4GB) 與 AWSc5.large 比較,同樣都是 2 vCPU 與 4GB RAM。

這邊用了 n-st/nenchOpenSSL 的 speed (包括了 aes、md5、rsa、sha1 與 sha256) 測試,我把結果都貼到這邊:「Linode (Dedicated 4GB) v.s. AWS (c5.large)」。

可以看到在 CPU 方面主要的差異是 Linode 用的是 AMD,而 AWS 用的是 Intel,所以就會有蠻多不同的數字表現...

如果仔細看 OpenSSL 的測試數據,可以看到不同演算法的差異還蠻大的,馬上可以想到的應該是硬體加速方式與 cache 架構差異造成的:

  • 在 cipher 類的測試我只測了 AES (目前的主流),小的 block (16/64/256 bytes) 時 AMD 會輸一些,但大的 block (1024/8192/16384 bytes) 反而會贏不少。
  • 在 hash 類的測試中,跑 MD5 時 Linode 則是輸一些,但 SHA1 反而是贏一些,然後 SHA256 時效能好到爆炸贏了一倍 XDDD
  • 在 public key 類的測試我測了 RSA,則是 Linode 輸的蠻慘的...

如果考慮到價位大約只有 AWS 的一半,應該是還不錯...

組一台 RISC-V 的 PC

RISC-V 是目前最有名的 open source 指令集,但似乎不太好找對應的硬體... 在「Building a RISC-V PC」這篇則是介紹了怎麼弄一台 RISC-V 的 PC:

採用的硬體是 HiFive Unleashed (USD$999),硬體架構包括了:

  • SiFive Freedom U540 SoC
  • 8 GB DDR4 with ECC
  • Gigabit Ethernet port
  • 32 MB quad SPI flash from ISSI
  • microSD card for removable storage
  • FMC connector for future expansion

沒有 USB 與 HDMI,作者是透過 HiFive Unleashed Expansion Board (USD$1999) 接出來的,不過這張還包括了 FPGA,這好像有點超過,兩個套件再加上 M.2 或是 SATA 的 disk 應該是超過台幣十萬...

不過畢竟算是早期的產品,之後有規模後應該會開始有中低價位的產品出現...

Mercury Web Parser 開源

看到「Mercury Goes Open Source!」這篇,Postlight 的團隊開源了 Mercury Web Parser,程式碼在 GitHub 上的 postlight/mercury-parser 可以取得。

這個版本是用 Node.js 寫的,可以從範例看出用法以及結果:

import Mercury from '@postlight/mercury-parser';
Mercury.parse(url).then(result => console.log(result););
{
  "title": "Thunder (mascot)",
  "content": "<div><div><p>This is the content of the page!</div></div>",
  "author": "Wikipedia Contributors",
  "date_published": "2016-09-16T20:56:00.000Z",
  "lead_image_url": null,
  "dek": null,
  "next_page_url": null,
  "url": "https://en.wikipedia.org/wiki/Thunder_(mascot)",
  "domain": "en.wikipedia.org",
  "excerpt": "Thunder Thunder is the stage name for the horse who is the official live animal mascot for the Denver Broncos",
  "word_count": 4677,
  "direction": "ltr",
  "total_pages": 1,
  "rendered_pages": 1
}

先前其他的軟體與服務可以參考「Evaluating Text Extraction Algorithms」這篇的整理與比較,不過這篇連原網站都不見了... 只能從 Internet Archive 上翻出來。

這個主題有不少團隊都做過 (給一個 html 網頁,抓出實際的內容塊落),但也死了不少團隊... 比較有印象的是 Readability,在 2016 年收掉了:「The Readability bookmarking service will shut down on September 30, 2016.」。

要撈資料可以拿來用...