最近在公司裏進行了一次深入HTTP分享,有同事提到了lighttpd在處理大文件時性能很差,不如ngix. 之前也沒有對ngix研究過,所以無法評估.加上這麼多年的linux上大型系統的開發經驗和仔細研究過lighttpd 的代碼,當時對同事的答覆是估計ngix也提高不了到哪裏去,最多10%,只是代碼寫法的一點差異. 同事們不太相信. 結束後上google查了一下ngix的資料，並下載了原代碼進行研究(個人喜好從代碼級研究認證,不喜歡看網上的評論,尤其是國內的評論，很多評論是沒有經過深入研究之後的誤人之第),並從網上找了一些評論,果然有看到lighttpd大文件下載或大併發連接性能不好之類的評論.
經過仔細研究ngix代碼之後發現,ngix的技術架構是結合lighttpd和apache之長, module的寫法基本上與apache 一致,非常類似; 網絡處理的架構與lighttpd類似,都是使用單進程單線程方式,並使用異步I/O,sendfile等,在linux2.6內核都使用epoll處理網絡事件,因此很難看出本質上的區別,唯一的區別是ngix充分利用了C語言的特性來節省內存(如bit位).
經過20000個併發連接測試10萬次小文件下載測試,兩者性能上差別不大,CPU消耗都在10%以內; 再進行大文件測試10萬次下載，併發2000,兩者相差不大，CPU消耗都是在4%以內,lighttpd的CPU消耗甚至還小一點. 這個時候的網絡帶寬已經完全被消耗乾淨,充分利用了網絡帶寬.
因此就非常奇怪爲什麼網上有評價lighttpd性能差的原因? 仔細思考後，估計是lighttpd的event_handler配置問題,因爲默認event_handler是使用poll, 而不是epoll(linux). 然後註釋掉#server.event-handler="linux-sysepoll" 再進行性能測試,果然發現lighttpd的CPU消耗就上去了. 看來網上的評論就是這個緣故,使用了默認配置,而ngix默認配置就是使用了epoll.
說明了國內很多人沒有仔細研究過系統,就對系統枉加評論,結果誤倒了很多人.這也是我聽到同事說什麼什麼問題是網上評論的時候,我總是懷疑其正確性的原因.