最近花很多力氣優化 msgpack-nodejs 這個專案
參考了其他先進的優化策略、把效能拉到跟當時 nodejs 生態圈最快的專案同等級
但不夠多自己原創的東西，也還是覺得有優化空間，所以還是努力一點一滴的累積優化
終於在今天，撇除跑分太鬼的 msgpackr，編碼速度贏了 22%、解碼速度贏 19%，覺得終於可以休息了
這邊文章是想在把這些細節遺忘前做點紀錄
分類: 後端
ArrayBuffer 是本篇文章將提到各個 API 的根本
它的別稱是「Byte Array」，就是 Byte Array 的意思，在這個「Array」中每一個 element 就是一個 Byte（8 bits）。
因為在宣告時就要定義長度，比如 new ArrayBuffer(4) 便會分配總共 4 Bytes（32 bits）的空間。對於這樣連續的記憶體，JS 不允許你直接寫資料到裡面，而要透過一些 View 幫你操作，比如有多種類型讀寫能力、但一次只能讀寫一個數字的 DataView，或者一次只能使用一種資料類型、但可以一次性寫入多個數字的 TypedArray。
本篇文章整理了後端開發的各種知識點，可以在每次面試前再次確定自己是否瞭解並能解釋出這些概念。
Best Practices for InnoDB Tables
- 用最常查詢的欄位當 primary key，沒有的話用 auto increment numbers
- 設定 Foreign key 會讓該欄位被 indexed，因此加快 join 效能。並且能傳播 updates 跟 deletes 到相關 table
- 關掉 autocommit，不然一次寫入就是一次交易，一秒可能幾百筆交易，效能會打折（受限於硬碟的寫入速度）
- 適當的使用
START TRANSACTION和COMMIT把 SQL 包起來執行，不要太小包，也不要大包到要跑好幾個小時 - 不要用
LOCK TABLES敘述 - 可以考慮 page compression 功能對你的 access pattern 有沒有（效能上的？）幫助
- 啟動時加上
--sql_mode=NO_ENGINE_SUBSTITUTION參數
在我踩到坑、並找到解法之後，才發現這個很基礎
但踩到了就踩到了，還是紀錄一下🙈
根據 khiav223577 大大的「MySQL 編碼挑選與差異比較」分享，
一般常使用的「ci」字集，其意思是 case-insensitive，也就是大小寫不敏感。
這種設定相當適合用在文章網站、新聞網站的搜尋功能，因為無論使用者輸入大寫的「APPLE」或小寫的「apple」，都能找到所有帶有「Apple」關鍵字的資料。
但當你需要做如 ID 比對、token 比對、短網址代碼比對，可能都需要改成 case-sensitive 字集，
或者在 WHERE 條件中使用 binary 達成目的。
最近常常用 PHP / Laravel 寫匯入資料的程式。為了效率起見，通常一開始就會使用 csv 格式，但這格式並不是萬能的，當資料量從 1 筆提升到 30000 筆，需要不斷調整程式才能妥善處理。
不過還是在開發之前就先抓好資料量是最好的啦🥲
Laravel 提供簡單好用的 API，
比如它的 ORM 讓你能用 paginate() 拿到 LengthAwarePaginator
它的 links() 能直接 render 出分頁功能的 HTML
專案上線 N 年後，資料量大了，可能會遇到分頁越來越慢的狀況，
這篇文章會描述一下我考慮解決方法的思路
最近跟資安專家開會討論新專案，他們提問：「你要怎麼確定 User 連上的真的是你的網站？」
同事則問「有 HTTPS 不就夠了嗎？」
他們兩個問的都是好問題 😂
深入挖掘之後我認為 HTTPS 只是基本，還需要搭配 DNSSEC
到 laravel/laravel 下載 zip …
一般 public key 裡面的內容長的像這樣：
-----BEGIN PUBLIC KEY----- MII... -----END PUBLIC KEY-----
當我們要用 JWK 公開 public key 的時候會發現：JWK 裡面放的是 Public key 的 modulus、exponent