跳至主要內容

分類: 後端

用 encodeInto() 提高 MessagePack 中的字串編碼速度

最近花很多力氣優化 msgpack-nodejs 這個專案
參考了其他先進的優化策略、把效能拉到跟當時 nodejs 生態圈最快的專案同等級
但不夠多自己原創的東西,也還是覺得有優化空間,所以還是努力一點一滴的累積優化
終於在今天,撇除跑分太鬼的 msgpackr,編碼速度贏了 22%、解碼速度贏 19%,覺得終於可以休息了

這邊文章是想在把這些細節遺忘前做點紀錄

JS 的 ArrayBuffer、Uint8Array、DataView、Buffer 之間的關係

ArrayBuffer 是本篇文章將提到各個 API 的根本

它的別稱是「Byte Array」,就是 Byte Array 的意思,在這個「Array」中每一個 element 就是一個 Byte(8 bits)。

因為在宣告時就要定義長度,比如 new ArrayBuffer(4) 便會分配總共 4 Bytes(32 bits)的空間。對於這樣連續的記憶體,JS 不允許你直接寫資料到裡面,而要透過一些 View 幫你操作,比如有多種類型讀寫能力、但一次只能讀寫一個數字的 DataView,或者一次只能使用一種資料類型、但可以一次性寫入多個數字的 TypedArray

MySQL 5.7 – InnoDB 文件的讀後筆記

Best Practices for InnoDB Tables

  • 用最常查詢的欄位當 primary key,沒有的話用 auto increment numbers
  • 設定 Foreign key 會讓該欄位被 indexed,因此加快 join 效能。並且能傳播 updates 跟 deletes 到相關 table
  • 關掉 autocommit,不然一次寫入就是一次交易,一秒可能幾百筆交易,效能會打折(受限於硬碟的寫入速度)
  • 適當的使用 START TRANSACTIONCOMMIT 把 SQL 包起來執行,不要太小包,也不要大包到要跑好幾個小時
  • 不要用 LOCK TABLES 敘述
  • 可以考慮 page compression 功能對你的 access pattern 有沒有(效能上的?)幫助
  • 啟動時加上 --sql_mode=NO_ENGINE_SUBSTITUTION 參數

MySQL「ci」字集做字串比對會無視大小寫

在我踩到坑、並找到解法之後,才發現這個很基礎
但踩到了就踩到了,還是紀錄一下🙈

根據 khiav223577 大大的「MySQL 編碼挑選與差異比較」分享,
一般常使用的「ci」字集,其意思是 case-insensitive,也就是大小寫不敏感。
這種設定相當適合用在文章網站、新聞網站的搜尋功能,因為無論使用者輸入大寫的「APPLE」或小寫的「apple」,都能找到所有帶有「Apple」關鍵字的資料。
但當你需要做如 ID 比對、token 比對、短網址代碼比對,可能都需要改成 case-sensitive 字集,
或者在 WHERE 條件中使用 binary 達成目的。

由 Compete Themes 設計的 Author 佈景主題