Home » Computer » Archive by category "Programming" (Page 2)

Instagram 解決 Cassandra 效能問題的方法

在解決 Cassandra 效能問題中大概就 ScyllaDB 特別有名,用 C++ 重寫一次使得效能大幅改善。而 Instagram 的人則是把底層的資料結構換掉,改用 RocksDB (這公司真的很愛自家的 RocksDB...):「Open-sourcing a 10x reduction in Apache Cassandra tail latency」。

主要原因是他們發現 Cassandra 在處理資料的部份會有 JVM 的 GC 問題,而且是導致 Cassandra 效能差的主要原因:

Apache Cassandra is a distributed database with it’s own LSM tree-based storage engine written in Java. We found that the components in the storage engine, like memtable, compaction, read/write path, etc., created a lot of objects in the Java heap and generated a lot of overhead to JVM.

然後在換完後測試可以看到效能大幅提昇,也可以看到 GC 的延遲大幅降低:

In one of our production clusters, the P99 read latency dropped from 60ms to 20ms. We also observed that the GC stalls on that cluster dropped from 2.5% to 0.3%, which was a 10X reduction!

比較一下這兩者的差異:在 ScyllaDB 是全部都用 C++ 改寫 (資料結構不換),這樣就直接解決掉 JVM 的 GC 問題。在 Rocksandra 則是在 profiling 後挑重點換掉 (這邊看起來是處理資料的 code,直接換成 RocksDB),另外順便把一些界面抽象化... 兩個不一樣的解法,都解決了 JVM 的 GC 問題。

Trac 1.2 裡 datepicker 每個禮拜的第一天改成星期天

Trac 1.0 搭配舊的 DateFieldPlugin 時,預設每週的第一天會是星期一,但這個設定可以在 trac.ini 內用 first_day 參數調整,像是這樣:

[datefield]
format = ymd
separator = -
first_day = 0

但在 Trac 1.2 在 trac.ini 裡就沒有提供設定讓人調整了... 而由於 Trac 是用 jQuery UIDatepicker,在這個套件裡有提供方法讓人調整,所以解決的方向變成在 site.html 內用 JavaScript 處理,把這段程式碼塞到 JavaScript 的區段內就可以了:

// Datepicker
jQuery.datepicker.setDefaults({firstDay: 0});

一整個繼續惡搞中... 然後把 wiki 上的 Trac 條目也更新上去。

用 pipsi 管 Python 的 command line 工具...

在「My Python Development Environment, 2018 Edition « Jacob Kaplan-Moss」這邊看到 Python 開發有哪些工具可以用 (介紹了三個),其中管理不同 Python 版本的 pyenv 用一陣子了,另外兩個則是之前沒用過...

pipsi 是將套件用 virtualenv 包起來,讓使用者在用的時候不會受到其他環境的干擾。我是拿來跟系統的 python3 (目前在 Ubuntu 16.04 上是指到 3.5.1) 使用,所以安裝 pipsi 時先切到 system 再透過 python3 安裝 (讓他偵測到系統的 python3):

$ pyenv shell system
$ which python3
$ curl https://raw.githubusercontent.com/mitsuhiko/pipsi/master/get-pipsi.py | python3

接著把 PATH 參數設好後 (設到 .bashrc 或是 .zshrc 之類的檔案),重新開一個 terminal 或是 shell (讓路徑生效),再把 awscli 裝進去:

$ pipsi install awscli

這樣這些工具就會吃系統的 python3 了...

測試 TPUv2 的 C/P 值

有人用相同演算法實際測試 Google 的 TPUv2 與 NVIDIATesla P100 的 C/P 值了:「Benchmarking Google’s new TPUv2」。

如果以 ResNet-50 當作計算的演算法,可以看到其實 C/P 值的差距沒有想像中大。主要原因是 GPU 可以使用較低的精度計算以加快速度,而非 Google 之前新聞稿故意使用較高精度比較 (TPU 使用 8-bit matrix engine,所以 GPU 使用較低的 fp16 版本比較會比較有參考價值):

真正的差異是在 LSTM

It turns out that the TPU is even faster on the LSTM model (21402 examples/s): ~12.9 times faster than a P100 (1658 examples/s) and ~7.7 times faster than a V100 (2778 examples/s)!

不過這邊就沒特別提到精度了...

IDA 免費版

Update:被 comment 提醒,找了一下資料,看起來有段歷史了,所以說 RetDec 的影響就未必是這樣了。下面的文章內容就不修正了...:「IDA Support: Evaluation Version」。

IDA 居然也提供免費版了,雖然是比較舊的版本,而且不提供技術支援:「IDA Support: Freeware Version」。IDA 是個可以反組譯以及當 debugger 的工具:

IDA is a Windows, Linux or Mac OS X hosted multi-processor disassembler and debugger that offers so many features it is hard to describe them all. Just grab an evaluation version if you want a test drive.

我猜是 Avast 放出 MIT 授權版本的 RetDec 的關係 (參考「Avast 放出他們的 Decompiler,RetDec」這篇),導致 IDA 這邊要做一些動作推廣試用...

不過我覺得有了 open source 的工具後,會看到 open source 工具慢慢成長...

Ethereum Smart Contracts 裡的 PRNG

現代密碼學的安全性有很大一塊是基於亂數產生器 (RNG) 非常難被預測。如果這個前提不成立的話,利用亂數產生器產生出來的各種資訊都會被預測出來 (尤其是 Private Key)。

但真正的 RNG 需要靠硬體支援,而且產生速度很慢,一般都會使用 PRNG (Pseudorandom number generator) 產生。也就是「看起來」很亂的亂數產生器。

PRNG 通常是指在統計學上通過許多測試,像是在多種測試都是 Discrete uniform distribution,不需要防止有惡意人,可以從產生出的 PRNG 的值而推導出後續結果的用途。

在「Predicting Random Numbers in Ethereum Smart Contracts」這篇裡面,作者列出了一堆實做 Ethereum Smart Contracts 卻誤用 PRNG 的行為。

文章裡提到的問題都是因為 PRNG 拿著可被預測的資訊當作 entropy source (e.g. seed),而且提出來的範例都是拿 block 本身或衍生的資訊 (像是 block 的 hash) 來用:

  • PRNGs using block variables as a source of entropy
  • PRNGs based on a blockhash of some past block
  • PRNGs based on a blockhash of a past block combined with a seed deemed private
  • PRNGs prone to front-running

然後列了大量的程式碼當例子,建議有需要接觸的人看過一次,或是有時間的人都值得看這些負面範例... XDDD

不過作者在文章裡面也給了一堆有問題的方法,像是從外部網站取得亂數之類的 XDDD

正確的方法是使用 CSPRNG (Cryptographically secure pseudorandom number generator),這是專門設計給密碼學用的 PRNG。

CSPRNG 有幾種方法可以取得:

  • 在大多數的程式語言內都有對應的 library 可以用,另外在比較近代的瀏覽器內 (如果問 IE 的話,是 11+),可以透過 RandomSource.getRandomValues() 得到。
  • 如果打算自己搞底層而需要直接取得 CSPRNG 的產出,在 Unix-like 的環境下可以透過 /dev/urandom 取得,在 Microsoft Windows 下則可以透過 CryptGenRandom 取得。

別學作者那邊奇怪方法啊 XDDD

V8 version 6.5 (Chrome 65) 的改變

V8 version 6.5 將會有不少改變:「V8 release v6.5」。

其中因為 Spectre 的關係,新的 V8 設計了 Untrusted code mode,拿來跑不信任的程式,裡面會設計反制措施。而且這在新版的 Chrome 將會預設開啟:

In response to the latest speculative side-channel attack called Spectre, V8 introduced an untrusted code mode. If you embed V8, consider leveraging this mode in case your application processes user-generated, not-trustworthy code. Please note that the mode is enabled by default, including in Chrome.

另外是針對 WebAssembly 提供邊下載邊 compile 的能力,這讓速度大幅提昇。在原文是拿一個比較大包的 WebAssembly 來測試:

For the graph below we measure the time it takes to download and compile a WebAssembly module with 67 MB and about 190,000 functions. We do the measurements with 25 Mbit/sec, 50 Mbit/sec, and 100 Mbit/sec download speed.

可以看到網路不夠快的使用者就會直接被 compile 速度跟上,讓瀏覽器在下載時就做一些事情。

另外在某些情況下對 Array 的操作會有大幅改善:

這些新功能與改善都會在 Chrome 65 推出。依照「Chrome Platform Status」這邊的資料,stable 版預定在三月初,beta 版應該是要出了... (雖然上面寫著 2/1,但目前好像還沒更新)

Cloudflare Worker 進入 Open Beta 讓大家玩了...

去年 Cloudflare 宣佈了 Cloudflare Worker,讓使用者可以在 Edge 端跑 JavaScript (參考「Cloudflare 也能在各端點跑 JavaScript 了」),也就是可以在 Cloudflare 節點上面對 HTTP request 與 HTTP response 做更多事情,類似於 AWSLambda@Edge

不過去年公佈的當時需要申請才有機會用,算是 Private Beta。現在則是開放讓大家玩 (Open Beta) 讓大家幫忙測試了:「Cloudflare Workers is now on Open Beta」。

文件在「Cloudflare Workers Docs」這邊可以取得,就如同去年 Cloudflare 所提到的,程式的撰寫上是透過 Service Worker 的界面,這樣就不用再學一套:

Cloudflare Workers are modeled on the Service Workers available in modern web browsers, and use the same API whenever possible.

現階段 Cloudflare Worker 是免費的,看起來是用這段時間的用量與用法來看要怎麼設計收費機制:

Cloudflare Workers is completely free during the open beta. We do intend on charging for Workers, but we will notify you of our plans at least thirty days before any changes are made.

Seam Carving (接縫裁剪)

看到有人實做 Seam Carving (接縫裁剪) 了,用 Golang 寫的,放在 GitHubesimov/caire 這邊,副標題「Content aware image resize library」。實做了「Seam Carving for Content-Aware Image Resizing」這篇論文。

Seam Carving 指的是知道內容的 resize,像是把上面這張變成下面這張:

或是變大:

馬上可以想到的應用是需要保留資訊內容,但又想要大量提供資訊的地方,像是 Nuzzle 的縮圖 (或是以前的 Zite),或是網路新聞媒體的首頁所用的縮圖。不知道還有沒有其他地方可以用...

Archives