Я слышал много хорошего о 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
JSF
источник
Если вы хотите более четко понять, как работает 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:
Я не смог найти правильного сравнения (по производительности), если кто-нибудь найдет тот, который я бы хотел увидеть!
источник
В общем, существует проблема с 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
JSPX
источник
GWT преобразует ваш код Java в сценарий Java. поэтому он работает как Java-скрипт на стороне клиента. А также, вы можете интегрировать CSS в свои приложения GWT. В общем, GWT является легким и может работать во всех браузерах без каких-либо проблем. Я не знаю много о JSF. Но я думаю, что JSF не такой гибкий, как GWT.
источник