JSF có thực sự sẵn sàng cung cấp các ứng dụng web hiệu suất cao không? [đóng cửa]


16

Tôi đã nghe rất nhiều về JSF nhưng theo tôi biết mọi người cũng đã phàn nàn rất nhiều với công nghệ này trong quá khứ, không biết tình hình đã được cải thiện đến mức nào. Chúng tôi đang xem xét JSF như một công nghệ có thể xảy ra cho một dự án mạng xã hội. Nhưng chúng tôi không nhận thức được điểm hiệu năng của JSF và chúng tôi không thể thực sự bắt gặp bất kỳ trang web hiệu suất cao hiện có nào đang sử dụng JSF. Mọi người phàn nàn về các vấn đề khả năng mở rộng hiệu suất của nó.

Chúng tôi vẫn không chắc chắn liệu chúng tôi có đang làm đúng hay không bằng cách chọn jsf, và do đó muốn nghe ý kiến ​​của bạn về điều này và xem xét đầu vào của bạn.

Có thể định cấu hình JSF để đáp ứng nhu cầu hiệu năng cao của dịch vụ mạng xã hội không? Ngoài ra cho đến mức nào thì có thể tồn tại với các vấn đề hiện tại trong JSF. Chính xác thì vấn đề của nó là gì?


Tôi không lo lắng về sự phức tạp phát triển với JSF những gì người khác thường phàn nàn vì theo kinh nghiệm cá nhân của tôi, tôi tin rằng điều đó không hoàn toàn đúng, nhưng tôi quan tâm nhiều hơn đến vấn đề hiệu năng và khả năng mở rộng. Và xin đừng lạm dụng nó vào các vấn đề cũ liên quan đến các phiên bản trước. Tôi chỉ quan tâm đến tình trạng hiện tại bất cứ điều gì đã là quá khứ của nó.


7
ptrthomas.wordpress.com/2009/05/15/jsf-sucks Tôi biết rằng đã có phản hồi của kiến ​​trúc sư trưởng của JSF, người biện minh cho mọi quyết định, nhưng với tôi, một người biết một số công nghệ web và đã chịu đựng, ngay cả với JSF 2.0, Facelets và SEAM, đây là sự nhạo báng. Ngay cả James Gosling sais: "Tôi ghét JSF với một niềm đam mê." Tôi sẽ sử dụng Wicket hoặc Tapestry và tránh JSF và các vấn đề của nó hoàn toàn.
Falcon

12
@ ThorbjørnRavnAndersen Tôi không đồng ý với bạn một cách nhẹ nhàng. Tôi nghĩ sẽ tốt hơn nếu cung cấp nhiều lời giải thích hơn là chỉ nói: "Tôi ghét JSF"
Chiron

6
@ ThorbjørnRavnAndersen Tôi hiểu quan điểm của bạn nhưng tôi thực sự khuyến khích mọi người cung cấp thêm thông tin. Ví dụ, một cuộc bỏ phiếu mà không có bình luận luôn làm tôi khó chịu.
Chiron

3
@Chiron, câu hỏi không phải là liệu JSF có thể sử dụng được hay không, mà là có thể tạo ra JSF để thực hiện hay không. Những người bắt đầu bằng cách đặt khung xuống, rất có thể không trả lời được câu hỏi thực tế. Tự mình duy trì một ứng dụng JSF, tôi cũng muốn biết.

3
> Ngay cả James Gosling sais: "Tôi ghét JSF với một niềm đam mê." - Nó được biết là đây là một sai lầm, như ông muốn nói là JSP. Lắng nghe cẩn thận đến đoạn trong câu hỏi. Đó là về những gì đã được tạo ra để đáp ứng với ASP cổ điển và đó là JSP chứ không phải JSF.
Arjan Tijms

Câu trả lời:


24

JSF chắc chắn có khả năng cung cấp các ứng dụng web hiệu suất cao. Ứng dụng tôi hiện đang làm việc hoàn toàn nằm trong JSF và từ các thống kê nhật ký, tôi có thể thấy rằng nhiều trang không chuyên sâu DB có thời gian thực hiện tối thiểu là 0ms và thời gian trung bình dưới 10ms.

Một số anh chàng Wicket đã nói những điều về hiệu suất của JSF, nhưng theo tiêu chuẩn công phu này, JSF thực sự hoạt động tốt hơn Wicket: http://prezi.com/dr3on1qcajzw/www-world- Worldwide -wait-devoxx-edition /

Lưu ý rằng miễn là máy chủ không bão hòa, thì JSF cũng hoạt động tốt hơn so với GWT. Mặc dù vậy, việc so sánh điểm chuẩn của GWT / JSF rất khó khăn, vì điều thực sự quan trọng là máy chủ cho GWT cũng thực hiện chuyển đổi và xác thực dữ liệu trong phần hậu kỳ mà JSF thực hiện. Đây là điều bạn đơn giản không thể bỏ qua trong thực tế (không bao giờ tin tưởng khách hàng). Ngoài ra, đối với các biểu đồ GWT vs JSF / Wicket, cần lưu ý rằng bước kết xuất của trình duyệt là không đáng kể đối với JSF / Wicket (vì chúng chủ yếu phục vụ HTML sẵn sàng để kết xuất), nhưng ứng dụng khách GWT vẫn có một số công việc để làm sau khi nhận được phản hồi của máy chủ.

Một trong những vấn đề hiệu suất / khả năng mở rộng lớn mà phiên bản JSF (trước 2.0) đã có, đang lạm dụng nhà nước tiết kiệm bằng cách đặt cách quá nhiều dữ liệu trong đó. Những thứ tuyệt đối không nên có ở đó đặt vào đó (như các hằng số như 'foo' như trong <my:tag attribute="foo"/>).

JSF 2.0 đã giới thiệu partial state savingcơ chế này, có nghĩa là chỉ trạng thái delta đang được lưu. Trong thực tế, điều này có thể rất ít và việc giảm hai bậc độ lớn so với JSF 1.x không phải là hiếm.

Sau nhiều năm sử dụng JSF, tôi có thể nói rằng ngoại trừ việc lưu quá nhiều trạng thái trong JSF 1.x, tôi chưa bao giờ gặp phải bất kỳ vấn đề hiệu năng nào mà tôi có thể gán cho JSF. Bất kỳ vấn đề về hiệu năng nào chúng tôi từng gặp phải luôn bắt nguồn từ DB và / hoặc cách chúng tôi thiết lập các dịch vụ back-end, viết các truy vấn của mình, v.v.


1
0 ms ... Tôi nghĩ rằng phương tiện đo lường của bạn cần nhìn vào.
gbjbaanb

2
@gbjbaanb Tôi không nghĩ vậy, những điều này xuất phát từ số liệu thống kê được thiết lập khá chuyên nghiệp. Xin lưu ý rằng tôi đang nói về thời gian tối thiểu và về các trang chuyên sâu không phải DB . Các trang thực thi trong thời gian đó rõ ràng không có 1000 thành phần trên chúng trải rộng trên 100 bao gồm. Chúng ta đang nói về các trang tương đối đơn giản ở đây, có thể là 10 thành phần, 1 mẫu chính, có thể 1 bao gồm, trên một máy chủ đã chạy được một lúc nên mọi thứ đều nóng và trong bộ nhớ. Thời gian trung bình cao hơn (10ms như tôi đã đề cập) và 90% cũng cao hơn. Max có thể là bất cứ điều gì.
Arjan Tijms

Tình hình là thế giới này chỉ phê phán những điều có khả năng giải quyết tất cả các vấn đề. Nhưng việc giải quyết tất cả các vấn đề luôn phải trả giá và đòi hỏi sự nhiệt tình và nhiệt huyết. Những gì tôi đã thấy trong các đội là họ bắt đầu phát triển mà không hiểu về vòng đời. Nó liên quan đến một đường cong học tập dốc nhưng nó cũng đẹp và đáng chú ý.
Shirgill Farhan

Nút cổ chai có nhiều khả năng nằm trong cơ sở dữ liệu / IO và băng thông (di động ...) so với chính máy chủ. Java thực sự nhanh khi được sử dụng tốt.
Barshe Roussy

8

Tất cả các lý thuyết trên thế giới đều có thể nói rằng JSF là tuyệt vời, nhưng hãy xem trang của bạn trông như thế nào. Nó tạo ra hàng đống javascript và những thứ nhảm nhí khác sẽ làm mất khả năng của bạn để thêm vào các mô-đun như jQuery hoặc sử dụng CSS một cách sạch sẽ. Không nói rằng nó không thể được thực hiện, nhưng với giá nào.

Kinh nghiệm cá nhân với một dự án tương đối nhỏ và độ phức tạp trung bình. Một thảm họa. Đó là một mớ hỗn độn đối phó với tất cả các cuộc gọi lại và bạn không thể trộn lẫn các công nghệ khác một cách dễ dàng. Chúng tôi đã có một lỗi rất lớn, hóa ra là do sử dụng JSTL trộn lẫn với JSF. Chúng tôi không bao giờ có thể sử dụng tất cả các công cụ jQuery do thực tế là MỌI liên kết là một cuộc gọi lại javascript.

Chạy đi và chạy thật nhanh.

Ngoài ra khi bạn nói quy mô, bạn đang nói về loại quy mô nào. Số lượng trang, số người dùng, số lượng yêu cầu mỗi giây, số lượng tính năng. Các câu trả lời cho những điều này có thể giúp bạn. Ngoài ra khi ai đó nói với bạn, nó cần mở rộng quy mô hỏi họ ở mức độ nào và nhanh như thế nào. Câu trả lời sẽ giúp bạn rất nhiều. Nếu bạn đang nói về quy mô google trong một tuần hoặc bạn đang nói về 1000 người dùng và 10000 lượt xem trang mỗi ngày trong một năm.

Hầu như bất kỳ khuôn khổ nào, thiếu bạn gõ phản hồi theo thời gian thực trong nền, sẽ mở rộng để đáp ứng 99,999% các trường hợp sử dụng.


3
-1 cho bất kỳ thang đo khung nào. Điều đó giống như nói "không quan tâm đến hiệu suất."
Raynos

3
Bản thân bất kỳ khung web được xuất bản nào cũng sẽ mở rộng quy mô bao gồm cả JSF. Tất cả họ đều nói rằng họ làm, đó sẽ là một khuôn khổ khá nhảm nhí nếu không. Điều đó nói rằng, nhiều người làm những điều ngu ngốc với nó và đó thường là nơi phát sinh vấn đề mở rộng.
Bill Leeper

1
đúng, nhưng một số khung khuyến khích bạn làm mọi thứ với tỷ lệ cản trở, vì khung này khuyến khích hoặc cộng đồng khuyến khích nó. Tôi sẽ tranh luận những khuôn khổ không quy mô.
Raynos

Bit "làm thế nào để bạn đo tỷ lệ" có lẽ nên là một nhận xét cho câu hỏi?

4

Tuyên bố miễn trừ trách nhiệm: Tôi thích JSF. Dù sao, ngay cả với RI (Mojarra 2.2.x) hoặc MyFaces mới nhất, ngay cả với hiệu suất triển khai không trạng thái được chờ đợi từ lâu là rất kém. Điều này là do vòng đời của JSF và thực tế là mỗi Chế độ xem được xây dựng (chi phí) cho mọi yêu cầu.

Để có được manh mối, đây là một điểm chuẩn đơn giản so với java servlet đơn giản so với trang JSF, cả hai chỉ in "hello world"

Phục vụ

glassfish-3.1.2.2$ ab -n 10000 -c 100 http://localhost:8080/mavenproject-web/NewServlet

Server Software:        GlassFish
Server Hostname:        localhost
Server Port:            8080

Document Path:          /mavenproject-web/NewServlet
Document Length:        128 bytes

Concurrency Level:      100
Time taken for tests:   0.970 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      4300000 bytes
HTML transferred:       1280000 bytes
Requests per second:    10307.02 [#/sec] (mean)
Time per request:       9.702 [ms] (mean)
Time per request:       0.097 [ms] (mean, across all concurrent requests)
Transfer rate:          4328.14 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.0      1       5
Processing:     1    9   4.6      8      51
Waiting:        1    8   4.4      7      40
Total:          4   10   4.1      8      51

Percentage of the requests served within a certain time (ms)
  50%      8
  66%     10
  75%     11
  80%     11
  90%     12
  95%     14
  98%     29
  99%     33
 100%     51 (longest request)

JSF

glassfish-3.1.2.2$ ab -n 10000 -c 100 http://localhost:8080/mavenproject-web/xhtml/test/jsf.xhtml

Server Software:        GlassFish
Server Hostname:        localhost
Server Port:            8080

Document Path:          /mavenproject-web/xhtml/test/jsfxhtml
Document Length:        100 bytes

Concurrency Level:      100
Time taken for tests:   4.676 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      4250000 bytes
HTML transferred:       1000000 bytes
Requests per second:    2138.60 [#/sec] (mean)
Time per request:       46.759 [ms] (mean)
Time per request:       0.468 [ms] (mean, across all concurrent requests)
Transfer rate:          887.60 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       6
Processing:     5   46   6.0     46      73
Waiting:        2   45   5.5     45      72
Total:          8   47   5.8     46      73

Percentage of the requests served within a certain time (ms)
  50%     46
  66%     48
  75%     50
  80%     51
  90%     54
  95%     56
  98%     60
  99%     62
 100%     73 (longest request)

1
Tôi không nghĩ rằng một trang hellowworld đơn giản có thể là đại diện hoặc có ý nghĩa. Một so sánh nghiêm túc phải cung cấp thông tin cần thiết như số phiên bản, cấu hình được sử dụng, v.v. Vui lòng đọc phần so sánh giữa JSF và Wicket trong câu trả lời trước.
lu4242

Hãy để tôi không đồng ý. Tôi thấy thực sự có ý nghĩa rằng trong bối cảnh không trạng thái đơn giản nhất jsf chậm hơn 5 lần so với jsp. Thật tầm thường khi xác minh rằng trong các tình huống phức tạp hơn, hiệu suất của jsf trở nên tồi tệ nhất. Hoặc tôi có thể cung cấp nhiều điểm chuẩn hơn cho người lười biếng nhất :-) Việc thực hiện jsf là mojarra 2.2 như đã nêu ở trên, với cá thủy tinh 3
gpilotino

"... jsf chậm hơn 5 lần so với jsp ..." Tôi nghĩ rằng lỗi ở đây là không tính đến thông lượng và hành vi cơ bản của jsp vs jsf. Quá phức tạp để giải thích, nhưng trong trường hợp này, thời gian phản hồi rõ ràng là chậm hơn vì jsf có hiệu ứng đồng thời mà jsp không có. Nhưng cuối cùng, chính xác hơn là so sánh các chu kỳ mỗi giây. Ngoài ra, Mojarra không giống như MyFaces, vì vậy cả hai triển khai đều có số khác nhau từ góc độ hiệu suất. Lưu ý hiệu ứng đồng thời trong trường hợp này là quá mức.
lu4242

Trong thực tế, việc so sánh một servlet đơn giản với JSF là hoàn toàn vô lý. Sự so sánh duy nhất có ý nghĩa là một "ứng dụng" được tạo ra bằng cách sử dụng JSP / servlets so với một "ứng dụng" khác thực hiện chính xác như vậy khi sử dụng JSF. Tại sao? bởi vì JSF cung cấp các giải pháp tích hợp để kết xuất / ajax / điều hướng / xác thực, những thứ cần được thực hiện từ đầu hoặc bằng tay trong JSP. Ngay cả khi so sánh thú vị từ góc độ hiệu năng (không có khung nào sẽ nhanh hơn servlet / jsp), thì JSP không phù hợp với JSF, bởi vì nó thậm chí không làm một phần nhỏ nào mà JSF làm cho bạn.
lu4242

"Hoàn toàn vô lý khi so sánh một servlet đơn giản so với JSF". không, không phải vậy cả hai công nghệ được cho là cung cấp nội dung. đây là lý do tại sao tôi đang tính đến các bối cảnh không quốc tịch, nơi xác nhận và những thứ khác không được tính. "Thời gian phản hồi rõ ràng là chậm hơn vì jsf có hiệu ứng đồng thời mà jsp không có" đây không phải là vấn đề về khả năng mở rộng? về myfaces, afaik mojarra đó là cách thực hiện nhanh nhất xung quanh (tôi sẽ điều tra việc này)
gpilotino

3

Nếu bạn muốn hiểu rõ hơn về cách thức hoạt động của JSF (cả Mojarra 2.1.7 và MyFaces 2.1.7) và so sánh nó với một khung tương tự như Apache Wicket (cả 1.4.20 và 1.5.5), hãy xem phần này trong- so sánh sâu (tháng 5 năm 2012):

Hiểu về JSF 2 và Wicket: So sánh hiệu suất

Phần tốt là mọi thứ đều có sẵn (mã, dữ liệu thử nghiệm, hướng dẫn về cách tái tạo thử nghiệm, báo cáo đầy đủ chi tiết). Nó sẽ giải quyết tất cả các câu hỏi của bạn về hiệu năng của JSF và bạn sẽ thấy Apache MyFaces có thể làm gì.


3

Một bài viết có thể giúp một chút (mặc dù không thực sự kết luận) là Khung máy chủ trung tâm Java: So sánh hiệu suất tại DZone Javalulk:

... Bài viết này xem xét mức độ hiệu quả của hầu hết các khung web Java SPI đối với các thay đổi một phần do máy chủ cung cấp. Chúng tôi không quan tâm đến các sự kiện không có giao tiếp với máy chủ, nghĩa là các sự kiện không có sự kiểm soát máy chủ (có thể).

Làm thế nào họ sẽ được đo

Chúng tôi sẽ đo lượng mã được gửi cho khách hàng liên quan đến thay đổi trực quan được thực hiện trong máy khách .

Chẳng hạn, đối với một thay đổi trực quan nhỏ (một số dữ liệu mới) trong một thành phần mà chúng tôi mong đợi không có nhiều mã từ máy chủ, nghĩa là, đánh dấu mới cần dưới dạng HTML đơn giản hoặc được nhúng trong JavaScript hoặc một số hướng dẫn cấp cao có chứa dữ liệu mới hình dung. Mặt khác, có vẻ như có gì đó không đúng, thành phần hoặc vùng trang hoàn chỉnh được xây dựng lại, gây lãng phí băng thông và sức mạnh máy khách (và có thể cả sức mạnh máy chủ).

Bởi vì chúng tôi sẽ sử dụng các bản demo công khai, chúng tôi sẽ không có được một tiêu chuẩn hạt rõ ràng và chính xác . Nhưng bạn sẽ thấy sự khác biệt rất mạnh mẽ giữa các khung.

Kỹ thuật thử nghiệm rất dễ dàng và mọi người đều có thể làm điều đó mà không cần cơ sở hạ tầng đặc biệt, chúng tôi chỉ cần FireFox và FireBug. Trong thử nghiệm này, FireFox 3.6.8 và FireBug 1.5.4 được sử dụng.

Bảng điều khiển FireBug khi "Hiển thị XMLHttpRequests" được bật ghi nhật ký mọi yêu cầu AJAX hiển thị phản hồi của máy chủ ...

Các khung đã được thử nghiệm

RichFaces , IceFaces , MyFaces / Trinidad , OpenFaces , PrimeFaces , Vaadin , ZK , ItsNat

... rõ ràng việc triển khai JSF duy nhất không có hình phạt hiệu suất nghiêm trọng là PrimeFaces ...

Tôi chưa thể tìm thấy một so sánh thích hợp (về hiệu suất), nếu có ai tìm thấy tôi muốn xem nó!


2

Có một vấn đề với Facelets nói chung mà IMHO là một điều khá bất tiện khi sử dụng. Nó dài gấp bốn lần so với thực sự cần thiết và cần quá nhiều công việc thủ công một khi bạn thực hiện một bước khỏi một cái gì đó nguyên thủy. HybridJava sẽ là sự thay thế tốt cho Facelets như công cụ trình bày trong JSF - nó thực hiện cùng một công việc (và thậm chí nhiều hơn, đặc biệt - nó tạo ra tất cả các "ràng buộc" và id cho bạn) với ít lần nhấn phím hơn.


1

Vì vậy, tôi muốn ném một điểm chuẩn tương tự. Tôi lấy một trang ví dụ về bootstrap của twitter và chuyển đổi nó thành xhtml nghiêm ngặt. Sau đó, tôi thiết lập chính xác một bean CDI ApplicationScoped trả về Hello, World. Tôi đặt biểu thức EL trên trang. Đối với phiên bản JSF, tôi đã sử dụng trình xử lý tài nguyên JSF, đối với phiên bản JSPX, tôi đã sử dụng css kiểu HTML và js bao gồm.

Tôi đã sử dụng băng ghế apache để kiểm tra thời gian tải trang chính. Thử nghiệm được thực hiện trên máy chủ TomEE + v1.5.2 chưa được tối ưu hóa. Tôi đã chạy từng điểm chuẩn 5x, sau đó chạy một GC đầy đủ trước khi thực hiện phép đo. Các thử nghiệm Bost đã được thực hiện trong cùng một cá thể JVM mà không cần khởi động lại JVM. Tôi có sẵn APR trên libpath, nhưng tôi không chắc điều đó ảnh hưởng đến bài kiểm tra này.

JSF chậm hơn, nhưng không nhiều, vì chúng tôi đang xử lý với số lượng rất nhỏ. Điều không được chứng minh là khi các trang trở nên phức tạp hơn, thì JSF / JSPX có tỷ lệ tuyến tính hoặc theo cấp số nhân.

Một điều tôi nhận thấy là JSPX tạo ra rất ít rác so với JSF. Việc chạy điểm chuẩn trên trang JSPX khiến cho heap được sử dụng tăng từ 184mb lên 237mb. Việc chạy điểm chuẩn trong cùng một JVM trên trang JSF khiến cho heap được sử dụng nhảy từ 108mb lên ít nhất 404mb, nhưng một bộ sưu tập rác tự động đã khởi động tại thời điểm đó. Dường như điều chỉnh trình thu gom rác của bạn cho JSF là một điều cần thiết tuyệt đối .

JSF

jonfisher@peanut:~$ /usr/local/bin/ab -n 10000 -c 100 http://localhost:8080/cdi-jsp/index.jsf
This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /cdi-jsp/index.jsf
Document Length:        2904 bytes

Concurrency Level:      100
Time taken for tests:   2.138 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      32160000 bytes
HTML transferred:       29040000 bytes
Requests per second:    4677.27 [#/sec] (mean)
Time per request:       21.380 [ms] (mean)
Time per request:       0.214 [ms] (mean, across all concurrent requests)
Transfer rate:          14689.55 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.3      1      21
Processing:     1   20   9.0     18      63
Waiting:        1   19   8.8     17      62
Total:          2   21   8.8     20      64

Percentage of the requests served within a certain time (ms)
  50%     20
  66%     23
  75%     25
  80%     27
  90%     32
  95%     39
  98%     46
  99%     50
 100%     64 (longest request)

JSPX

jonfisher@peanut:~$ /usr/local/bin/ab -n 10000 -c 100 http://localhost:8080/cdi-jsp/page2.jspx
This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /cdi-jsp/page2.jspx
Document Length:        2440 bytes

Concurrency Level:      100
Time taken for tests:   1.273 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      26290000 bytes
HTML transferred:       24400000 bytes
Requests per second:    7856.63 [#/sec] (mean)
Time per request:       12.728 [ms] (mean)
Time per request:       0.127 [ms] (mean, across all concurrent requests)
Transfer rate:          20170.98 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    5   2.3      6      20
Processing:     1    8   4.6      6      40
Waiting:        1    8   4.3      6      40
Total:          2   13   3.8     12      41

Percentage of the requests served within a certain time (ms)
  50%     12
  66%     12
  75%     13
  80%     13
  90%     17
  95%     20
  98%     24
  99%     28
 100%     41 (longest request)

-3

GWT chuyển đổi mã java của bạn thành tập lệnh java. vì vậy nó chạy như một tập lệnh java ở phía máy khách của bạn. Ngoài ra, bạn có thể tích hợp css vào các ứng dụng gwt của mình. Nói chung, gwt có trọng lượng nhẹ và có thể chạy trên tất cả các trình duyệt mà không gặp vấn đề gì. Tôi không biết nhiều về JSF. Nhưng tôi nghĩ dt, JSF không linh hoạt như GWT.


1
Nó không trả lời câu hỏi, đó là về hiệu suất của JSF và không phải là khuyến nghị khung. Dù sao, GWT thường được yêu thích bởi những người không biết JavaScript ^^
Danubian Sailor
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.