1樓：陳連傑
express底層是connect，connect預設的靜態處理是static外掛程式，static直接封裝send模組，send模組核心功能呼叫了node的pipe把檔案pipe到res，順便處理一些httpheader. 然後最核心的是send預設是沒有cache的，也沒有zip。
如果測試併發，最好直接返回已經在記憶體的資料，並且沒有開啟zip。
所以要在node上找個支援cache的靜態檔案中介軟體，或者自己隨便寫乙個handle。
如果純比靜態檔案處理，nginx理論上還是比node快，差距主要在native和v8的切換。如果更公平的測試，應該在nginx上啟用lua做返回乙個靜態檔案然後做快取。這樣node估計略微有優勢。
目前靜態資源都CDN化，自己的伺服器可能只處理index檔案和api請求或者動態網頁，如果閘道器有較為複雜的業務規則或者需要安全，限流，會話等公共邏輯，nginx簡單的配置檔案很難符合要求，如果在nginx啟動lua指令碼，那等於就是node了。如果團隊沒有lua的工程師，用node其實很核實。
2樓：張義軍
壓測方法本身也有問題吧？5000併發，10000個請求，為什麼會有這樣的設計？你按這個案例測試看看nginx能到怎樣的tps？
Swoole比Node js有哪些優勢？有哪些知名的Swoole案例？
這位大哥，說句實在的，你根本就不懂PHP吧！首先 HHVM 和 Swoole 根本就是倆個東西？Swoole在於難上手，但是高併發下效能比node.js高得多吧 幾乎近倆倍的效能差距 對於新手來說乙個PHP檔案就是乙個網頁，那麼對於新手來說會懂Nodejs嗎？所以不要盲目地下結論，高併發不是Node...
前端和高併發有關係麼？
能問這個問題。是說明後台正在將效能問題差甩鍋前台嗎？認真回答的分割線 這裡問的應該是後端 api 高併發問題。前端能做的是儘量減少不必要的請求。手法其實比較有限，比如加個快取 加個防抖 儘量減少互動的資料報大小什麼的。畢竟瀏覽器已經對 http 請求併發設定了限制，印象中是 6 8 個併發請求。 i...
Node js 真的有協程嗎？
原子筆 聽說過物件導向的上下文麼？誰說上下文一定只能存在於暫存器和棧上呢？把棧指標暫存器換成this指標，這叫做無棧協程 再配合點語法糖，讓訪問物件成員如同訪問區域性變數一樣 連主流編譯語言都支援省略this直接訪問成員 這不是很平凡的操作麼 有棧協程 用 e rsp棧暫存器來索引區域性變數，上下文...