我不知道這是因爲頁面加載花了一點時間，還是servlet在HTTP的「裸機」之上有一個抽象框架，或者僅僅是因爲Jave-EE中的「Enterprise」，但是在我的腦海中，我認爲基於servlet的應用程序本質上是增加開銷，而不是直接處理套接字的Java應用程序。基於servlet的堆棧是否有大量開銷？
忘記網頁，想象一下，通過HTTP請求向其發送問題的Java服務器應用程序，它從內存中查找答案，並在響應中返回答案。您可以輕鬆編寫一個基於Java套接字的應用程序來完成這項工作，您也可以使用servlet方法並擺脫套接字的「裸機」。
是否有任何可衡量的性能影響被期望實現相同的方法使用Servlets而不是自定義的基於套接字的HTTP偵聽應用程序？
是的，我對HTTP請求中發送的確切數據感到朦朧，我知道這是一個模糊的問題。這實際上是關於servlet實現是否具有大量的間接層或其他任何會增加每次調用大量開銷的內容，其中重要的意思可能是額外的0.1s或更多。
當然有一些開銷。難以定義的是多少，不是因爲難以衡量，而是因爲很難找到一種替代方案，它不會帶來更脆弱，麻煩纏身和可擴展性差的風險。
換句話說，假設你真的死於表現......你會推出你自己的服務器嗎？它將如何處理管理併發請求（全部命中相同的端口）？你會爲HTTP請求編寫自己的解析器嗎？它能夠與所有瀏覽器正常工作嗎？你如何識別特定客戶的會話？
換句話說，您的問題有點像問「關係數據庫在測試一個虛擬的自定義數據存儲時沒有人寫過，但會刪除所有不需要的功能而支持原始速度？」
我的回答：是的，當然。我仍然會使用數據庫，因爲它現在可以工作，並且已經針對開發人員認爲理所當然的很多事情進行了調整，但是如果每次發現需要它們用於應用程序時都要重新進行重構。
我強烈建議，如果你還沒有準備好，在Jetty來一看，特別在WebSockets實施。
請重新閱讀的問題，這不是關於服務網絡的頁面，但一個更通用的服務器應用程序，多想想客戶之間的實時通信。 – 2010-06-05 19:23:21
我不會推出自己的服務器，併發客戶端有套接字庫。我問是否servlet適合這種事情。 – 2010-06-05 19:29:16
我沒有提到「網頁」。我提到了http請求，就像你一樣。而「瀏覽器」引用則適用於Ajax，Flex和Silverlight等。更何況你可以使用像Selenium這樣的東西來測試你的服務器。 – 2010-06-06 09:12:54
當然，每個抽象都會增加開銷。
從很多基於Java的Web應用程序的存在來判斷 - 它在性能方面完全沒問題。
所以總之 - 不用擔心。有機會，你會創造一個比javax.servlet更不理想的解決方案。性能問題主要來自糟糕的代碼。
您是否在討論與構建和提供整個網頁相比較小的開銷，或者與我爲隱藏原始套接字而編寫的簡單框架相比，即使對於通用客戶端 - 服務器通信而言，開銷也很小？ – 2010-06-05 19:27:56
無論你從哪裏看，它都是疏忽:)除了實時，時間敏感的數據傳輸，也許。但是，這不是HTTP的作用， – Bozho 2010-06-05 21:15:28
它的作用是什麼，它的能力可以完全不同。只要看看他們把HTML扭曲成了:) – 2010-06-05 22:08:48
我不認爲會有太多的開銷。 HTTP消息非常小，解析起來非常簡單。 Servlet體系結構對裸HTTP消息沒有太多的抽象。
即使一個天真的servlet實現應該只花費客戶端發送http請求消息到服務器所需的時間的一小部分。也就是說，開銷並不明顯。
在初始化servlet時需要做些什麼。儘管只有在servlet收到第一個請求時纔會發生這種情況。
太含糊。如果你沒有測量它，它不存在。 – bmargulies 2010-06-05 19:00:57
對不起，但這是一個愚蠢的迴應。當設計一個多用戶應用程序時，您必須事先考慮_架構_性能。有關「過早優化」的着名引用並不意味着您不應該在設計階段優化。 – 2010-06-05 19:21:41
如果只是我寫了一個問題_asking_關於那個話題... – 2010-06-05 19:25:52