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

Мы до сих пор не уверены, правильно ли мы поступаем, выбирая jsf, и поэтому хотели бы услышать от вас все об этом и принять во внимание ваш вклад.

Можно ли настроить JSF для удовлетворения высоких требований к производительности социальных сетей? Также до какой степени возможно выжить с текущими проблемами в JSF. В чем именно его проблемы?

Меня не волнуют сложности разработки с JSF, на которые обычно жалуются другие, потому что, исходя из моего личного опыта, я считаю, что это совсем не так, но меня больше беспокоит то, какие проблемы с производительностью и масштабируемостью. И, пожалуйста, не злоупотребляйте им по старым проблемам, связанным с предыдущими версиями. Я просто забочусь о настоящем состоянии, каким бы оно ни было.

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

Некоторые ребята из Wicket говорили о производительности JSF, но в соответствии с этим сложным тестом JSF на самом деле работает лучше, чем Wicket: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/

Обратите внимание, что пока сервер не насыщен, JSF также работает лучше, чем GWT. Сравнение эталонных тестов GWT / JSF затруднено, поскольку действительно важно, чтобы сервер для GWT также выполнял преобразование и проверку данных в обратной передаче, которую выполняет JSF. Это то, что вы просто не можете оставить на практике (никогда не доверяйте клиенту). Кроме того, для графов GWT и 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-страницей, оба из которых просто выводят «hello world»

Servlet

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, когда «Show XMLHttpRequests» включена, регистрирует любой AJAX-запрос, показывая ответ сервера ...

Каркас проверен

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

... очевидно, единственная реализация JSF без серьезных потерь производительности - это PrimeFaces ...

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

В общем, существует проблема с Facelets, которую, по-моему, использовать довольно неудобно. Это в четыре раза громче, чем необходимо, и требует слишком много ручной работы, как только вы сделаете один шаг от чего-то примитивного. HybridJava был бы хорошей заменой Facelets в качестве движка презентаций в JSF - он выполняет ту же работу (и даже намного больше, в частности - он делает все «привязки» и идентификаторы для вас) с гораздо меньшим количеством нажатий клавиш.

Поэтому я хотел добавить аналогичный тест. Я взял страницу примера начальной загрузки в Твиттере и преобразовал ее в строгий xhtml. После этого я установил ровно один компонент CDI ApplicationScoped, который возвратил Hello, World. Я положил выражение EL на странице. Для версии JSF я использовал обработчик ресурсов JSF, для версии JSPX я использовал стиль CSS css и js includes.

Я использовал apache bench для проверки времени загрузки главной страницы. Тест проводился на неоптимизированном сервере TomEE + v1.5.2. Я запускал каждый тест 5x, затем выполнял полный сбор данных перед измерением. Бост-тесты проводились в том же экземпляре JVM без перезапуска JVM. У меня есть доступный APR в libpath, но я не уверен, что это повлияет на этот тест.

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. Но я думаю, что JSF не такой гибкий, как GWT.