為了更好的支援前端能夠自由組合、展示收到的資料，筆者使用graphql-go 框架開發了負責的模組，但測試過程中發現，使用graphql會有n+1 query的問題。經過調研發現兩種解決方案：
在使用graphql-go的同時使用facebook開源的dataloader工具，詳細例子見dataloader的issues: example to use with graphql-go
scheme (simplified):
「「 type query
type order
type client
「「query:
query
getorders
}}
為了返回100個orders，必須傳送101個請求給微服務（1個請求獲取批量的orders，100個獲取它的client資訊（每個order都需要執行一次client資訊查詢）。詳細資訊見issues: no way to get requested fields inside resolver
使用vegeta工具向服務傳送流量，然後使用pprof和go-torch工具對服務進行分析。
向服務傳送流量命令
傳送流量結果分析
vegeta vegeta report -inputs=r.bin
requests [total, rate] 6000, 200.03
duration [total, attack, wait] 29.998652838s, 29.994999868s, 3.65297ms
latencies [mean, 50, 95, 99, max] 3.740812ms, 3.649598ms, 4.53176ms, 5.088892ms, 22.366809ms
bytes in [total, mean] 222000, 37.00
bytes out [total, mean] 2802000, 467.00
success [ratio] 100.00%
status codes [code:count] 200:6000
error set:
go tool pprof -seconds 25 http://localhost:8080/debug/pprof/profile，持續25s後輸入web，生成如下所示的內容：
雖然go1.9在使用pprof工具生成cpu耗時分析的時候較之前的版本已經加入了顏色，但是看起來仍不是很直觀，這個時候就需要使用火焰圖了。
在使用vegeta命令壓測的同時使用go-torch工具生成火焰圖，命令go-torch -u -t 25生成的火焰圖如下圖所示：（192.168.189.168為本地的localhost）
通過火焰圖分析，graphql-go框架的占用很多的cpu耗時，查詢資料發現，主要原因是graphql的resolver函式的解析並非併發解析，所以會產生上面描述的n + 1 query的問題。
Docker踩坑之路
這是由於在啟動容器時沒有給docker容器配置足夠的記憶體，預設64m，因此讀入資料集會超出記憶體，所以要在run容器時給容器配置記憶體，解決方案位址 shm size 8g 表示分配給容器8g的記憶體 nvidia docker run it name yangxiaoli5 shm size 8...
ant design pro 踩坑之路
新入手react 我司要用螞蟻金服那個框架 從頭開始熟悉。慢慢踩坑之路。實時更新 1.使用靜態檔案資源 2.關閉自帶eslint檢查 找到package.json 檔案 刪除裡面的 pre commit npm run lint staged 3.proxy proxy裡面的 的千萬不要和你的位址裡...
RxDB indexedDB的踩坑之路
演示例子?這是乙個schema的定義 const schema required color 在rxdb中，schema在設計之初就應乙個純潔的json，始終能夠解析與字串化，所以並不支援函式，但是這樣的好處多多，比如 那如果我們希望實現類似上方 這種預設值生成器，該怎麼做呢？那就是！使用middl...