我最近工作上一直在 tune 一條 queue 的處理。

我最近工作上一直在 tune 一條 queue 的處理。 本來是每個單位每個單位分開寫 table row，一堆worker分開批次吃，跑排程定期執行。但我後來一直覺得一個個吃，這件事情本質上 worker 沒有最高效率被使用。排程跟排程中間的空窗也有點浪費。 運算浪費的比例有點高，實際上也是效能真的有點慢（大概尖峰30-40分鐘才能清理完的慢）。另一方面當然這也跟 fetch queue的機制有關。 後來調整了一下 fetch mode ，從排程每次取一定量變成，排程跑一定時間，取完了就做下一批，降低因為排程造成的吞吐量不足障礙。（某種 eager mode ?) 然後我又加了另一個同路的運算進來串連，所以 worker 吞吐能力下降（因為做的事情/運算量變多了），但這種倚賴db的worker 如果要從db層再做多負載要搞的事情又很多，worker 要用人海戰術的話有點蠢，不是我喜歡的策略。 但我往前又發現任務其實是有同質性的，同批的單位放一起運算的話， context 的準備可以共用，效能可以極大化(未經準確測量的預期，單從計畫面角度約可以降低最少最少保底2倍的運算量吧，運氣好一點還可能更多，簡單來說那包單位越多省越多），所以我把源頭進 queue 的地方又做了一次打包分組。 成效非常顯著，我現在都把吞吐直接壓回尖峰一分鐘內都能做完了。 但我還再想要不要針對一包太大包的（可能超過500單位的），直接分幾支worker專門處理他們，讓小包的可以分流優先處理。 我之所以寫這個是因為，馬的我怎麼覺得我又在玩異形工廠或戴森求了，單位是原料，worker 是加工廠............ 事實上主管工作真的就是這樣，每個各種各行各樣的人，放進一個運作模式，然後等著收割成果。

原始 Facebook 貼文