About “The way of the Gopher”

關於The way of the Gopher這篇文章

The way of the Gopher by Alexandra Grant

這篇由digg工程師所寫的文章: The way of the Gopher,裡面提到由於node.js event loop單執行緒的本質,使得他們的service有個很大的瓶頸。當在他們的Octo服務在跟Amazon S3溝通時,由於S3反應時間有時候相當慢,使得等待回應的main thread反而被阻斷(block)住了,結果造成服務品質下降(*)。

那她的解法是什麼? 她發現了網路上一篇文章說Go一分鐘可以處理上百萬請求,awesome! 所以就把Octo用Go重製了一遍,結果也如同她所預期,瓶頸消除了,不用在每幾周就重開一次instance,可以處理的request數還提高了。

What a pretty day, right?

但事情也不只是看結果而已,怎麼說? 事實上,他們的其中一個問題,只要建立worker pool並把這些events與對應的event handler分派給worker去平行處理,當這些worker從S3那邊拿到資料後,再將結果送回主執行緒,主執行緒被阻斷的問題便可以有效地改善。該篇文章下面的留言也不只一次提到這個解法。

要記得,不要換到了node.js後,就忘記concurrency怎麼處理了,在其他語言會使用worker pool去分散式地處理較花時間的程式邏輯,怎麼切到node.js環境就忘記了?就只會把全部的工作都丟給event loop就好? 應該不是這樣吧。Event loop是沒那麼magic沒錯,但其實這邊問題本質卻不是因為node.js所造成的。

有的時候,語言本身會引導developer解決問題的想法,因為node.js有個神奇的non-blocking模型,所以就忘了concurrency怎麼寫。其實如果這個Octo服務當初並不是node.js的版本,而是使用php或是java去製作,那在建構過程中自然就會使用worker去對付平行處理的問題,也自然不會遇到該篇文章描述的情況。

總之呢,原本想看在使用相同實作下,Go vs node.js結果如何的某些鄉民似乎有點失望(**),畢竟文章談到的解決方案本質與使用Go或是node.js並沒有關係,而是與服務本身使用的邏輯與解法有關聯。而這篇文章,也並沒有把Go與node.js放在相同基準,相同邏輯實作下來比較,自然沒辦法分出個高下囉。(**)

(*) 其實我簡化問題了,詳細可看該文章描述
(**) 當然也很多鄉民覺得選擇Golang的信心大增。
(***) 愛看執行效能分勝負的可以看https://benchmarksgame.alioth.debian.org

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.