2010-10-02 67 views
2

我需要從一開始。我從Yakov Fain讀到關於在碼頭和blazeds上的表現突破。帶有非阻塞IO的Jetty或Tomcat(servlet 3.0)

我意識到,我們已經有一些麻煩,約1200個併發用戶,一些消費者不明白的消息和CPU是猛烈的炮火下。

難道有人已經嘗試過這種仁王使用BlazeDS? 這也適用於Tomcat嗎? 從哪裏開始,我需要什麼來提高消息傳遞性能?

太謝謝你了!

+0

更新:這是很久以前的事,但由於我們startet使用Jetty7(現Jetty8)與org.mortbay.jetty.asyncblazeds.AsyncAMFEndpoint的和長輪詢感覺非常快流幾乎實時的。如果有人對我們如何配置我們的應用程序感興趣(需要發佈很多內容),請隨時提問。 – 2012-02-04 11:19:34

回答

1

你去定製BlazeDS的支持NIO您分析您的應用程序,並驗證了該熱點的道路之前,我建議。你是否證實這是導致丟失消息的BlazeDS網絡堆棧?您是否分析了您的代碼,看看是否有優化措施可以更好地優化消息處理?

一些實際抗衡的Java NIO實際上並沒有提高通量 - http://paultyma.blogspot.com/2008/03/writing-java-multithreaded-servers.html

我這樣說是因爲BlazeDS的不支持NIO只有服務器的商業版本那樣 - LCDS。 LCDS實際上設置了它自己的NIO套接字,並通過這些連接管理請求,繞過標準的servlet堆棧。爲了獲得NIO的支持Yakov說:「爲了支持數千個併發用戶,你還需要定製BlazeDS的網絡層」我願意猜測這個定製的網絡層不是生產準備好的,而更像是一個原型,因爲它非常難以可靠地定製任何服務器的網絡層。

+0

這不是關於吞吐量,而是關於併發連接的數量。 – user359996 2010-10-14 04:48:00

+0

你是對的,但希望這將是標準並支持近期... – 2010-10-15 06:38:11

+0

的OP的原題引用雅科夫費恩(從Farata系統)是誰寫的關於企業Flex應用程序的一個偉大的書,並在其中他提供定製NIO,真使用BlazeDS而不是LCDS推送消息端點。只要我們有像Jetty 7和Tomcat 7這樣真正的servlet 3.0 API應用服務器,它就有效地否定了購買LCDS的必要性。 – HDave 2010-12-17 02:31:55