情罪正異
2022-1-5 07:55:12
而且每個synchronous function call都會令到其他async function變成synchronous
硬係有啲人 Promise.resolve(getFibonacci(100)) 就當自己 async 咗, 到發現 event loop被block死就投訴個framework寫得唔好。用 async construct 包住sync function嘅真正問題係 tie up user thread, 而唔係令其他async function 變返 sync。 包 sync function 包到block死 event loop 或 main thread 係低級錯誤, 係唔熟framework, 同 tie up user thread 根本係2個完全唔同嘅問題。 tie up user thread 呢啲係死症, 個個framework都有async db driver你唔用, 你一定要 legacy API 就自己睇路, 咩framework都幫唔到你。
C#就時不時有人直接用Task.Result, 搞到有bottleneck甚至deadlock
呢啲又係低級錯誤, code review 叫佢記得 async all the way, UI thread 要ConfigAwait(false) 之類, 再犯就炒得。
BTW, ASP.NET Core 已經唔再建議libuv
咁不如你再睇多啲,佢哋用咩嚟代替 libuv, 點解,同埋結果。 asp.net core 嘅 event loop 放棄咗 libuv loop, 用 c# 重寫。
點解個event loop要重寫 ?因為 libuv 仲係用 linux thread pool去處理disk IO (包括db) / network IO, 而無用到 linux 嘅 aio。
Linux AIO 透過 batching send/recv in networking IO (同 disk IO 嘅batching 原理一樣) 去減少 IO 嘅overhead, performance 高於 thread pool。
結果就係 libuv 嘅 IO 慢過 kestrel, 亦係nodejs喺performance上輸比asp.net core嘅其中一個原因, 某啲 benchmark 有3X 嘅分別。
但快又如何,單靠呢啲web framework都食唔到真正嘅大茶飯。
如果將 complex system 比喻為一間酒樓, asp.netcore / nodejs 呢啲web framework就好似門口嘅知客, 負責派飛帶位,偶然收下銀,僅此而已。以前啲經理on99叫知客落場斟茶, 推點心車,甚至入廚房煮飯, 門口梗係排長龍, 客人等等吓咪走人囉。
microservice / step function (aws) or durable function (azure) 都係解決呢類問題嘅其中一個辦法, 總之個結論係 nodejs is good but it's not that good, asp.net core is great but it won't be tomorrow.
nodejs用libuv
而且你話所有framework都有non blocking io,我唔係好認同
at least python java c#連rdbms大部份係blocking
JDBC interface直頭係全部blocking