2011-07-17 21 views
4

我還沒有找到一個關於JSF性能的良好基準。我知道你在想什麼,它取決於你的代碼/設計/數據庫設置等。我知道在你需要優化你的表示層之前,你必須優化許多事情(例如你應該看看你的數據庫模式有多好) ,但是爲了說明我們已經達到了必須審查我們的表示層的程度。JSF性能:JSF的可擴展性如何?

JSF是會話密集型的。我讀過很多次,在編寫可伸縮應用程序時這可能是一個缺點。在集羣環境中進行大量的用戶會話可能會產生問題。有沒有關於此的文章?我討厭去生產只是爲了看到偉大的JSF生命週期和CDI集成在性能上有巨大的成本。

+0

請問[programmers.stackexchange.com](http://programmers.stackexchange.com/)。 –

+2

此問題已被封閉,因爲它徵求意見,辯論,投票等。這些都是主觀的,它絕對不是我要找的。我一直在尋找關於JSF性能的事實,或者是關於其使用內存的專業知識,並且可能是優化它的方法。也許有足夠的知識的人可以告訴我不要擔心它或相反,建議我轉向更無國籍的平臺。我不認爲這需要接近,因爲很多人都有疑問。關於JSF的信息太多,但沒有關於性能不過時的信息。 – arg20

+0

@ arg20你需要閱讀2件事1)http://blog.oio.de/2013/05/06/jsf-performance-tuning/ 2)http://ovaraksin.blogspot。in/2013/05/jsf-choice-between-legacy-components.html – Sam

回答

0

我不知道是否有任何斷言JSF會話數據很重要的事實。但是,我還以爲那的方式來解決可擴展性問題,由於大量的會話數據將是:

  • 複製前端服務器(你無論如何都要做到超出某個點縮放)和

  • 根據會話令牌向前端分派請求,以便會話數據可能已經在內存中可用。

0

呈現層是-> embarrassingly parallel應用的一個實例。原則上你可以通過添加硬件來擴展它;一個極端就是在每個用戶的網站最大用戶數的一分鐘內擁有一個超線程。所以可伸縮性在這裏不是問題。可能存在的問題是頁面必須按順序呈現,並且即使在單用戶模式下也需要很長時間才能呈現:如果JSF需要一分鐘才能以單用戶模式呈現,那麼多用戶模式,如果你不能並行渲染它,那麼這是非常必要的。

+0

如果我們需要投入10臺以上的服務器,這不是問題。但在某些時候,經濟變化。如果您可以通過花費1年時間完成軟件優化,從而減少100臺服務器,這是值得的。 – irreputable

+0

是的,我同意,如果你長到巨大的規模,總會有一種折衷。 –

1

對於高性能,無論框架或語言如何,都必須實施會話粘性。如何完成取決於你的設置;例如硬件負載平衡器通常具有此功能。那麼你不必擔心服務器之間的網絡延遲。

但是,單機上的JSF + CDI性能也非常重要。假設開銷是300ms,這意味着一個4核服務器每秒只能處理10個請求。不錯,但不是在高性能課堂上。 (通常JEE公司的電動車公司不會遇到問題;它們通常是企業規模的,而不是互聯網規模的;而且他們有大量服務器的現金可供使用)

雖然我沒有真正的性能數字,如果有人報告了一些CDI + JSF統計信息,例如處理中等大小的典型頁面需要多長時間,這將會很有趣。