Я чув багато хорошого про JSF, але, наскільки я знаю, люди також мали багато серйозних скарг на цю технологію в минулому, не знаючи, наскільки ситуація покращилася. Ми розглядаємо JSF як вірогідну технологію проекту соціальних мереж. Але ми не знаємо показників ефективності JSF, і ми не могли дійсно натрапити на будь-який існуючий веб-сайт з високою ефективністю, який використовував JSF. Люди скаржаться на проблеми масштабування його продуктивності.

Ми все ще не дуже впевнені, чи правильно ми робимо, вибираючи jsf, і, таким чином, хотіли б почути від вас все про це і врахувати ваші дані.

Чи можливо налаштувати JSF так, щоб задовольнити високі потреби в послугах соціальних мереж? Крім того, до якої міри можна вижити з поточними проблемами JSF. Які саме його проблеми?

Мене не турбують складності розвитку JSF, на що зазвичай скаржаться інші, тому що, на моєму особистому досвіді, я вважаю, що це зовсім не так, але мене більше хвилює питання щодо ефективності та масштабованості. І будь ласка, не просто зловживайте ним у своїх старих питаннях, пов’язаних із попередніми версіями. Мене просто хвилює теперішній стан того, що було його минулим.

JSF, безумовно, здатний надавати високоефективні веб-програми. Додаток, над яким я зараз працюю, повністю знаходиться в JSF, і з статистики журналу я бачу, що на багатьох сторінках, що не мають інтенсивних БД, є мінімальний час виконання 0 мс і середній час менше 10 мс.

Деякі з хлопців з Віккету говорили про результати діяльності JSF, але відповідно до цього розробленого орієнтиру JSF насправді працює краще, ніж Wicket: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/

Зауважте, що поки сервер не насичений, JSF також працює краще, ніж GWT. Порівняння базових показників GWT / JSF є важким, оскільки це дійсно важливо, щоб сервер для GWT також здійснював перетворення та перевірку даних у післягарантійному звороті, що робить JSF. Це те, що ви просто не можете залишити на практиці (ніколи не довіряйте клієнту). Крім того, для графіків GWT vs JSF / Wicket слід враховувати, що крок візуалізації браузера є тривіальним для JSF / Wicket (оскільки вони в основному обслуговують готовий до візуалізації HTML), але клієнт GWT все ще має певну роботу робити після отримання відповіді сервера.

Однією з найважливіших проблем продуктивності / масштабованості, яку мали старі версії JSF (до 2.0), було зловживання економією держави, розміщуючи в ній занадто багато даних. Речі, яких абсолютно не повинно було бути там, де їх помістили (як константи типу "foo", як у <my:tag attribute="foo"/>).

JSF 2.0 запровадив partial state savingмеханізм, що означає, що зберігається лише дельта-стан. На практиці це може бути дуже мало, і скорочення на два порядки порівняно з JSF 1.x не є рідкістю.

Після багатьох років використання JSF я можу сказати, що за винятком збереження занадто багато стану в JSF 1.x, я ніколи не стикався з жодною проблемою продуктивності, яку я міг би віднести до JSF. Будь-які проблеми з продуктивністю, які ми коли-небудь мали, завжди були корінням у БД та / або тому, як ми створювали резервні служби, писали запити тощо.

Всі теоретичні в світі можуть сказати, що JSF чудовий, але просто погляньте, як виглядають ваші сторінки. Це створює масивні купи javascript та інших лайнів, які суттєво перешкоджають вашій можливості додавати такі модулі, як jQuery або чисте використання CSS. Не кажучи, що цього не можна зробити, але якою ціною.

Особистий досвід із відносно невеликим проектом та середньою складністю. Катастрофа. Це було безладно з усіма зворотними викликами, і ви не можете легко поєднувати інші технології. У нас була величезна помилка, яка виявилася причиною використання JSTL, змішаного з JSF. Ми ніколи не змогли використати всі матеріали jQuery через те, що ВСЯКОГО посилання - це зворотний дзвінок javascript.

Біжи і швидко тікай.

Також коли ви говорите шкалу, про яку шкалу ви говорите. Кількість сторінок, кількість користувачів, кількість запитів в секунду, кількість функцій. Відповіді на них можуть вам допомогти. Також коли хтось скаже вам, що потрібно масштабувати, запитайте їх до якої міри та як швидко. Відповідь вам надзвичайно допоможе. Якщо ви говорите про шкалу google протягом тижня або ви говорите про 1000 користувачів та 10000 переглядів сторінок на день за рік.

Практично будь-яка рамка, якщо ви не набираєте відповіді у реальному часі у фоновому режимі, може відповідати 99,999% випадків використання.

Відмова: Мені подобається JSF. У будь-якому разі, навіть із останніми RI (Mojarra 2.2.x) або MyFaces, навіть із довгоочікуваною реалізацією без громадянства продуктивність дуже низька. Це пояснюється життєвим циклом JSF та тим, що кожен вид (дорого) будується для кожного запиту.

Щоб отримати підказку, це простий орієнтир проти простого сервалета java проти сторінки JSF, обидва просто друкують "привіт світ"

Сервлет

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)

Якщо ви хочете чіткіше зрозуміти, наскільки працює JSF (як Mojarra 2.1.7, так і MyFaces 2.1.7) та порівняти їх із аналогічною рамкою, як Apache Wicket (як 1.4.20, так і 1.5.5), погляньте на цю ін- глибоке порівняння (травень 2012 р.):

Розуміння JSF 2 та Wicket: Порівняння продуктивності

Гарна частина - все, що є в наявності (код, експериментальні дані, інструкції щодо відтворення тесту, детальний вичерпний звіт). Це вирішить усі ваші питання щодо продуктивності JSF, і ви побачите, що Apache MyFaces здатний зробити.

Стаття, яка може трохи допомогти (хоча і не дуже переконливо) - це орієнтована на сервер фреймворки Java: Порівняння продуктивності в DZone Javalobby:

... У цій статті розглядається, наскільки ефективні більшість веб-рамок SPI Java на часткові зміни, які надає сервер. Нас не цікавлять події без зв'язку з сервером, тобто події без (можливого) управління сервером.

Як вони будуть вимірюватися

Ми будемо вимірювати кількість коду, який надсилається клієнтові щодо візуальної зміни, виконаної у клієнті .

Наприклад, для незначної візуальної зміни (деяких нових даних) в компоненті ми очікуємо, що не дуже багато коду від сервера, тобто нова розмітка, необхідна як звичайний HTML, або вбудований у JavaScript, або деякі інструкції високого рівня, що містять нові дані, які будуть візуалізується. В іншому випадку щось здається неправильним, наприклад, повна складова компонента чи сторінки сторінки перебудовується, витрачаючи трафік на пропускну здатність та потужність клієнта (і, можливо, потужність сервера).

Оскільки ми будемо використовувати публічні демонстрації, ми не збираємось отримати остаточний та тонкий показник зерна . Але ви побачите дуже сильні відмінності між рамками.

Техніка тестування дуже проста, і кожен може зробити це без спеціальної інфраструктури, нам просто потрібні FireFox та FireBug. У цьому тесті використовуються FireFox 3.6.8 та FireBug 1.5.4.

Консоль FireBug, коли включено "Показати XMLHttpRequests", записує будь-який запит AJAX, що показує відповідь сервера ...

Рамки перевірені

RichFaces , ICEfaces , MyFaces / Тринідад , OpenFaces , PrimeFaces , Vaadin , ZK , ItsNat

... мабуть, єдиною реалізацією JSF, яка не має серйозних штрафних санкцій, є PrimeFaces ...

Я не зміг знайти належного порівняння (для продуктивності), якщо хтось знайде таке, я хотів би його побачити!

Взагалі є проблема з Facelets, яку IMHO - це дуже незручна річ. Це в чотири рази більше, ніж справді потрібно, і вам потрібно занадто багато ручної роботи, як тільки ви зробите один крок від чогось примітивного. HybridJava була б хорошою заміною для Facelets як двигуна презентації в JSF - він робить ту саму роботу (і навіть набагато більше, зокрема - робить усі "прив'язки" та ідентифікатори для вас) із значно меншими натисканнями клавіш.

Тому я хотів запустити подібний показник. Я взяв сторінку прикладу завантажувального закладу щебетати і перетворив його на строгий xhtml. Після цього я встановив рівно один боб CDI ApplicationScoped, який повернувся Hello, World. Я розміщую вираз EL на сторінці. Для версії JSF я використовував обробник ресурсів JSF, для версії JSPX використовував HTML-стиль css і js включає.

Я використовував лавку apache, щоб перевірити час завантаження основної сторінки. Тест проводився на неоптимізованому сервері TomEE + v1.5.2. Я запускав кожен бенчмарк 5x, потім виконував повний GC перед тим, як проводити вимірювання. Найкращі тести проводилися в тому самому екземплярі JVM без перезапуску JVM. Я маю доступну КВП на лібпаті, але я не впевнений, що впливає на цей тест.

JSF повільніше, але зовсім не дуже, оскільки ми маємо справу з дуже невеликими кількостями. Що не демонструється, так як сторінки стають складнішими, чи масштабує JSF / JSPX лінійно чи експоненціально.

Одне, що я помітив, - це те, що JSPX виробляє дуже мало сміття порівняно з JSF. Запуск еталону на сторінці JSPX призвів до того, що використана купа підскочила з 184 Мб до 237 Мб. Запуск еталону в тому ж JVM на сторінці JSF змушує використану купу стрибати з 108 Мбайт принаймні до 404 Мб, але в цей момент починається автоматичне збирання сміття. Здавалося б, налаштування вашого сміттєзбірника для JSF є абсолютно необхідною .

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)

GWT перетворює ваш код Java в сценарій java. тому він працює як сценарій java на стороні вашого клієнта. Крім того, ви можете інтегрувати css у свої gwt-додатки. Загалом, gwt - це невелика вага і може працювати без проблем у всіх браузерах. Я не знаю багато про JSF. Але я думаю, dt, JSF не такий гнучкий, як GWT.