node.js的event loop是單進程單線程的，只有壹個epoll/kqueue事件輪詢被執行。所以無法利用到多核的計算優勢。
swoole的event loop是多線程的，是基於epoll/kqueue的Multi-Reactor模型。這點與nginx/golang相同。另外swoole的多線程Reactor之間不存在鎖，這點與nginx不同。它啟用了專門的accept線程，類似與JAVA的netty。
所以在多核CPU的機器上，node.js對網絡IO事件的處理能力絕對是要差swoole數倍的，在4核的機器上至少要查2-3倍。
雖然node.js也提供了多線程的擴展，但對於event_loop來說必須是內核提供，擴展不行的。
另外node.js未來是否會改造成為多線程Reactor，我估計不會，這不是技術上的難題。而是壹旦改成多線程Reactor，node.js恐怕就不是node.js了。失去了原來單線程的各種優勢後，反而會壹無是處。當然可能node.js官方開發組會思考出解決問題的巧妙辦法，壹切都是後話了。
不只是event_loop，執行用戶層代碼是也是單線程的，不能利用多核計算優勢。需要用戶自己去fork多進程或者創建線程池。使用難度增加了很多。不像swoole，配置壹下參數即可，是天然多進程。
異步網絡IO
node.js和swoole都是基於epoll/kqueue實現的全異步非阻塞IO，所以這方面大同小異，沒有差別。維持TCP長連接的能力是壹樣的。
node.js在這裏有壹個優勢就是它支持windows的IOCP。swoole僅支持Linux/FreeBSD/MacOS的epoll/kqueue.
異步文件讀寫
node.js和swoole都提供了基於線程池的異步文件讀寫，DNS查詢功能。node.js最早基於libeio實現，後來才自行實現線程池。swoole壹開始就基於線程池設計的。
實際上這裏都是通過多線程阻塞來模擬的，並非真正的異步讀寫文件。比如同時讀寫數百個文件時，性能遠不如普通的多進程PHP程序。
swoole中還提供了Linux Native AIO的支持，是真正的內核層異步並行文件讀寫，不過需要通過修改宏開關，重新編譯才可以使用。
最後結論
node.js和swoole比沒有明顯優勢，僅在Windows支持方面比swoole要好。node.js中有的特性swoole中都有。個人認為Node.js最大的優勢在於：
node.js使用JavaScript語言，與瀏覽器、HTML之間的融合度非常高，使用同壹種語言既寫前端又寫後端
支持Windows平臺，利用node-webkit，可以開發PC客戶端軟件
node.js的定位應該是前端與後端結合非常緊密的應用場景。如websocket推送，JSON-RPC，輕量級HTTP接口。
而對於真正專業的後端領域，分布式系統，node.js不適合。