среда, 23 марта 2016 г.

Почему же все-таки покупают коммерческие сервера приложений, если есть бесплатные решения?

Вынесено из комментариев, мнение исключительно мое.

Железо, ОС, DB2 и WAS как часть общей платформы идут на мейнфреймах, да и то несколько месяцев назад анонсированы новые сервера LinuxONE, представляющие собой мейнфреймы, снабженные только IFL-процессорами, т.е. позволяющие запускать только Linux, позиционируемые как неограничено масштабируемая платформа для работы как IBM'овского, так и Open Source софта. Да что говорить, там поддерживаются даже Ubuntu и KVM. На остальных - дистрибьютед платформах, как мы их называем, - WebSphere Application Server покупают просто как сервер приложений, успешно ходят из него в Oracle Database и запускают на нем самые разные системы, как самописные, разработанные на самом предприятии или подрядчиком, так и известные пакетные приложения, например EMC Documentum. Насколько я знаю, даже Oracle SOA Suite может работать на WebSphere Application Server'е, правда скорее всего на Classic.

Почему же заказчики покупают сервер приложений с поддержкой от известного вендора, вместо того, чтобы использовать бесплатные решения? Частично я освещал эту тему в статье А почему бы мне не заплатить за мой Spring Framework? Ключевое - нефункциональные требования. Да, и Apache TomEE, и Glassfish (похоже R.I.P), и JBoss (платный?) являются платформами для того же самого стека Java EE, но дьявол как обычно кроется в мелочах. И задача продавца из IBM, который будет помогать вам аргументировать покупку, заключается в том, чтобы понять, а нужны ли вам эти опции. Нужны ли Dynamic Routing, Auto Scaling, Intelligent Management и т.д.

Другая причина, по которой покупают промышленные сервера приложений, - поддержка известным производителем. Существуют системы, несколько часов/сутки простоя которых стоят дороже, чем лицензии на сервер приложений, СУБД и другое програмное обеспечение. Речь даже не столько о финансовых учреждениях, хотя большинство россиян столкнулись со знаменитым простоем карточного процессинга одного известного банка несколько лет назад. Представьте себе простой любого московского аэропорта, крупной железнодорожной компании (единственной в стране крупной железнодорожной компании :)), энергосбыта и т.д. Я конечно не говорю, что у всех у них WebSphere Application Server, но менеджменту зачастую нужно, чтобы в случае критичных проблем тут же приехал (связался по телефону) человек и починил за четко установленное в SLA время. Я не знаю ни одного случая внедрения TomEE в нашей богоспасаемой стране, ровно как и фирмы, гарантирующей 24/7 поддержку данного сервера приложений. Аналогичные соображения про Glassfish, знаю только, что есть коммерческая версия данного сервера, но ее поддерживают коллеги из Туманного Альбиона и похоже только там + та Европа, что западнее Белоруссии. Red Hat, надо отдать должное, более активен.

А что можете сказать вы? Поделитесь своим мнением по поводу нужности/ненужности коммерческих серверов приложений в комментариях!

Понравилось сообщение - подпишитесь на блог

66 комментариев:

ZeroSetup комментирует...

Да, согласен, сервера приложений с поддержкой нужны для тех случаев, которые Вы описали, где это явно часть "Mission Critical" для копании.

Мне больше нравится бизес-модель с бесплатным OpenSource-продуктом, по которому можно купить поддержку(и лучше ну у одного поставщика). Это очень хорошо сказывается на популярности продкута, всегда можно взять полную версию ,даже для "production", а когда компания "дорастает" или решает, что выгоднее покупать поддержку, чем иметь своего специалиста, то она закупает эту поддержку.

Кстати, WAS Liberty не-opensource, а это тоже может быть причиной, что некоторые компании его не возьмут, ибо "backdoors".

Я примеряю на свою среду, где явно не нужно такого уровня SLA, но мысли попробовать стек JEE есть.

Уже два экземпляра WAS Liberty(development, test) по одному гигабайту не пойдет.

Pavel Samolysov комментирует...

Большое спасибо за столь развернутый комментарий.

Замечу только, что хотя сам WLP не Open Source, но большинство используемых им компонентов (как, впрочем, и у других коммерческих серверов приложений) имеют открытые исходники, например JPA-провайдеры OpenJPA и EclipseLink.

Можно сделать по-другому, пользоваться до некоторого момента бесплатным OpenSource сервером приложений, а затем смигрировать на WebSphere Application Server, мы можем помочь с этим.

Pavel Samolysov комментирует...

Еще хочу заметить, что WebSphere Liberty Profile не такой дорогой, как кажется. Посмотрите, пожалуйста, в сторону Family Edition: " For example, a purchase of 300 PVUs of Family Edition provides entitlement to deploy: 100 PVUs of WebSphere Application Server Network Deployment, 400 PVUs of WebSphere Application Server, 800 PVUs of WebSphere Application Server Liberty Core, at the same time".

ZeroSetup комментирует...

так и не нашел стоимость этого самого PVU. вот всегда так с этими гигантами, тяжело простой калькулятор сделать? Хотя нет, посмотрите на Amazon Web Services, сразу можно посчитать:

https://calculator.s3.amazonaws.com/


А тут: FAQ сделали, на http://www.ibm.com/financing отправили, цен так и не видно.

Нет, калькулятор то я нашел, но он считате PVU:
https://www-112.ibm.com/software/howtobuy/passportadvantage/valueunitcalculator/vucalc.wss

а где деньги?

Pavel Samolysov комментирует...

Не могу комментировать ценовую политику Amazon, скорее всего если обратиться в компанию, то можно узнать, что для курпных клиентов есть скидки и прочие плюшки. Касательно IBM - самый надежный способ узнать стоимость продукта - обратиться в локальное представительство Компании.

ZeroSetup комментирует...

Кажется я догадываюсь как дальше будет: региональные партнеры посмотрят сколько можно денег взять, может сделают специальное предложение людям принимающим или влияющим на решения на предприятии...

Пример Amazon в том, что все честно, цены видны, человеческого фактора нет.

Извиняюсь, это так лирика.

Pavel Samolysov комментирует...

Лучший способ проверить что будет дальше - позвонить по номеру +7 495 775 88 00 и спросить торгового представителя по WebSphere Application Server.

CGen комментирует...

А почему GlassFish R.I.P. ? Поддержки нет, но он вполне жив. Багфиксы выходят. Он же RI для Java EE. Выйдет Java EE 8 и RI для неё будет GlassFish. Без RI же нельзя.

Новую версию Java EE можно только на нём попробовать.
WebLogic Java EE 7 совсем недавно стал поддерживать: WebLogic Server 12c R2 (12.2.1) - October 26, 2015.

А как у WebSphere с Java EE 7 ?

Pavel Samolysov комментирует...

Сейчас раскручивается скандал, ну или не скандал, но хайп, что Оракл не будет развивать Java EE, ветки Glassfish 5 до сих пор нет. Поправьте, если я не прав.

WebSphere Liberty Profile был первым сервером, продакшн реади реализацией Java EE 7.

Pavel Samolysov комментирует...

На несколько месяцев раньше WebLogic'а: https://developer.ibm.com/wasdev/blog/2015/06/25/java-ee-7-has-landed-in-was-liberty/

ZeroSetup комментирует...

>Сейчас раскручивается скандал, ну или не скандал, но хайп, что Оракл не будет развивать Java > EE, ветки Glassfish 5 до сих пор нет.
Вот с этого момента подробнее!
Я нашел кое-что:
New sources are stepping up questions about Oracle's stewardship of the Java development platform
http://www.infoworld.com/article/2987529/java/insider-oracle-lost-interest-in-java.html

Так ведь это беда. Что же будет с Java и с нами?

Смогут ли они остановить JCP и развитее OpenJDK? Хотя кроме OpenJDK еще есть реализации,
вот у IBM-а тоже.

Странные они, в Oracle, хотят стать облачным провайдером, а что будет в этих облаках крутиться? Вот зачем нужна забота о платформе и разработчиках.

Pavel Samolysov комментирует...

Интформация из первых рук: http://blog.rahmannet.net/2016/03/why-i-left-oracle.html Сейчас сообщество активно старается перехватить развитие платформы. С Оракл не понимаю тоже, когда они купили BEA у них оказался весь стек: Java EE сервер + СУБД, после покупки Сана добавилась Java и железо. Все было логично и тут нате.

Уже пошли разговоры, что лучше бы Сан был куплен ИБМом...

Unknown комментирует...

Павел, а что думаете на счет того, зачем в некоторых коммерческих серверах свои имплементации JVM, с учетом того, что существует OpenJDK?

Pavel Samolysov комментирует...

Здравствуйте. Никогда не задумывался над этим вопросом, воспринимал как данность. Конкретно про IBM, считаю, что это вызвано необходимостью поддержки своих аппаратных платформ - Power и Mainframe.

ZeroSetup комментирует...

Знаете, Павел, я послушал и почитал Антона Кекса.
(Антон Кекс — Архитектура интернет-банка без Enterprise
https://youtu.be/y96fZdOoeiA

Как мы создали продвинутый интернет-банк за 5 месяцев
https://codeborne.com/ru/2012/12/17/online-bank-from-scratch-in-five-months-ru.html
)

Он известный противник энтерпрайзности. Приводил практические примеры и соображения:
1. Ожидается, что на апп-сервере будет крутиться много приложений, в реальности одно, а узлов много, ибо нагрузка.
2. В Эстонии коллектор данных со всех электросчетчиков крутится на чем-то маленьком(кажется Netty), два узла в кластере.
3. Свою банк-платформу они запилили на Play Framework, как я понял используя встроенный сервер(!),
а распараллеливали благодаря Stateless-природе своего приложения.

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

Pavel Samolysov комментирует...

Большое спасибо за ссылки, с удовольствием прочитал статью.

Как я понял, речь идет только лишь о системе доступа пользователя, system of engagement, автор сам в статье пишет, что они интегрируются с АБС, т.е. их вся из себя стейтлесс система сама по себе платежи не проводит, не является system of records. Это ни в коем случае не умаляет значение труда коллег, но требования к данным классам информационных систем все же разные. В интернете пишут, что АБС в Банке Санкт-Петербург - ЦФТ-Банк и крутится на Oracle Exadata, что может быть более кроваво энтерпрайзнее :-)

Конкретно про интернет-банк, было бы интересно почитать про кластеризацию и принятые решения для обеспечения отказоустойчивости, но про это в статье ничего нет, увы.

Pavel Samolysov комментирует...

По поводу одно приложение на апп-сервере, да есть нагрузка, но ею нужно управлять - можно посмотреть в сторону z/OS WLM, позволяет управлять чуть ли не каждым урлом.

Ну и стоит признать, что мой опыт радикально иной, нежели у Антона Кекса, у меня никогда не было проблем с JMS, по крайней мере на WebLogic'е, хотя прокачивалось более 5 млн. сообщений в сутки (хотя стоит признать, что были проблемы с распределенными транзакциями, но это из-за того, что адмнистраторы удаленных БД не давали нужных прав для их восстановления).

Придя в IBM, я познакомился с такой штукой, как MQ Queue Sharing, это в какой-то мере киллер-фича для MQ for z/OS - кластер из менеджеров очередей, работающих как единая группа, в случае падения одного из них, его сообщения подхватываются другим.

ZeroSetup комментирует...

Думаю в интернет-банке Антона свое хранилище было, какое-то lightweight, для финансовой части, конечно АБС.
Важным посылом считаю overengeneering энтерпрайз решений. По аналогии с JЕЕ, который, вероятно, произвели люди уже далекие от жизненных проблем и чаяний разработчиков. Да, уже исправили, но разработчики как ушли в Spring и что-то другое, так и не хотят возвращаться. В интернетах очень мало материала по решениям JEE.

ZeroSetup комментирует...

замечу, что решение команды Антона не тиражируемое, у него были сильные разработчики, они внесли изменения в Play Framework и Hibernate, но хорошо, что это стало доступно, ибо это опенсоурс проекты.
для меня это пример, что Java-решения жизнеспособны в вебе под нагрузкой без дорогого инфраструктурного ПО.

Pavel Samolysov комментирует...

Плачь Ярославен по поводу оверинжениред Java EE регулярно попадается в рунете, такое чувство, что люди живут в 2003-м году. За последние 10 лет выросло не одно поклление разработчиков и Java EE на мой взгляд становится все популярнее, особенно нп Западе конечно, но даже и в России живут уже не Спрингом единым, слава Богу, и Java EE, и ESB, и SOA восстребованы. Работают те же REST сервисы на EJB быстрее, чем на Спринг фреймворке, см. хотя бы мой бенчмарк, а сам спринг на вебсфере, кстати, быстрее чем на томкат.

В общем ненависть как EE это какой-то локальный тренд, возможно вызванный общей незрелостью ИТ. Т.е. Писать системы без ЕЕ конечно можно, кто бы спорил, вопрос в том - что за системы. Для десяти рестсервисов где все сопровождение построено на "переписать нахер" - это действительно оверинжениринг, хотя джоб секюрити индекс растет да и новые рабочие места создаются, был нужен один программист, а теперь пара, экстрим программинг и аджайл же. В жестком хайлоаде типа Одноклассников, EE возможно не нужна, какая разница ну потеряет тетя Маша картинку или пролежит вся система несколько часов как было пару лет назад - никто не умрет и денег со счета не потеряет. С другой стороны и плейфреймворк с хибернейтом и спрингом в таких проектах не используются. Если говорить о более приземленных вещах, то рекомендую блог Адама Бина, он собирает интервью от ЕЕ разработчиков со всего мира, очень интесно для расширения кругозора. Люди часто делятся как выкинули всякие фреймворки из своих варов и деплоят маленькие архивы на большие и не очень сервера и занимает это секунды, врут иногда чуваки, застрявшие во временах EJB 2.0, но продолжающие тянуть сваренный из топора сервер приложений внутри каждого джар/вар архива. Зато сам сделал, есть о чем пацанам на конференции рассказать.

ZeroSetup комментирует...

например, в Томкат, я положу библиотеки в общую папку, мое приложение станет маленьким для развертывания. Hot Deploy можно организовать из IDE, есть File Synchronization плагин под Eclipse.
Перегрузка классов без перезапуска приложения можно через HotSwap Agent(DCEVM), Spring loaded или коммерческий JRebel.

Кстати, Spring Loaded к удивлению заработал под IBM J9. Заставить работать "родной" HotSwap для J9 я не смог, информации крайне мало.

Насчет EE, вот попробуем заменить Spring MVC на EE-реализацию, нашелся Ozark https://ozark.java.net/, материалов там мало, в интернете ничего не находится. Кто-то этим пользуется? Заработают ли полезные фишки, как в Spring MVC (@PathVariable, @ResponseBody)?

Не только в рунете, в англоязычном инете мало информации по Java EE.

Да, глянул по-быстрому "MVC: Model-View-Controller API"(https://jcp.org/en/jsr/detail?id=371), нашел(@PathParam).

Мне кажется что все втайне надеются, что, например Spring MVC со сременем реализует спецификацию,
как это было с Hibernate и можно будет дальше им пользоваться. При желании писать только в соотв. с спецификацией и потом можно будет менять реализауцию MVC, как сейчас можно заменить Hibernate не меняя код.

Pavel Samolysov комментирует...

Ну т.е. Я возьму томкат, но так как он ничего не умеет, то приделаю ему крылья от мерседеса, двигатель от самолета, колеса от самоката и со всем с этим попытаюсь взлететь.

Конкретно стандартизированная реализация MVC планировалась как часть Java EE 8, ozark сейчас в бете, насколько я знаю.

Не понимаю вашего неоднкратно прозвучавшего замечания про то, что по ЕЕ мало информации. Какой именно информации не хватает? Публичных референсов, хаутушек, кода конкретных прилодений? Конечно, если в спринг несмотря на довольно хорошую документацию, принято публиковать мануалы вида как сварить кашу из топора, используя спринг и хибернейт (самая популярная статья в этом блоге, 50 000 просмотров), или спринг и JPA, то в ЕЕ достаточно обявить поле и использовать одну аннотацию, писать об этом заметку даже глупо как-то, официального туториала достаточно.

Pavel Samolysov комментирует...

Ошибки и опечатки прошу отнести на счет неудобнейшей экранной клавиатуры iPad

CGen комментирует...

Сейчас решил по Sping 4 новую книгу прочитать. Там первые 200 страниц посвящены способам конфигурации.

Java EE начинал с Sun-овского Starter Kit (уже не помню 2009 или 2010 год).
NetBeans + GlassFish 2.
За день приложение смог задеплоить.
И ещё потом Java EE tutorial прочитал.

Если нужна скорость и Java EE не применима, то Spring ещё более не применим. "Не хочу тяжёлый интерпрайз - выбираю Spring" - звучит странновато :-).


ZeroSetup комментирует...

так в Spring Source вроде осознали, что сами скатываются в ынтерпрайз и сейчас продвигают Spring Boot, чтоб народ с конфигурацией не мучался.

вот представьте, что нужен Web MVC, Dependency Injection и ORM, так проще положить эти части Spring в проект и запускаться в чем-то очень легком и бесплатном при разработке(Jetty, Tomcat) и потом еще получить полную свободу при развертывании: хочешь на том же легком, что было при разработке, хочешь на большом коммерческом. все таки львиная доля софта не требует такой доступности, как описывает Павел.
да, когда начинаешь что то неизвестное изучать, то нужны и Хауту , и туториалы, и примеры кода, всего как можно больше. по Спрингу этого вдоваль.
вот, копнул доки по WAS Liberty Profile и IBM J9 JVM и так и не нашел, как включить HotSwap классов.

Pavel Samolysov комментирует...

Все-таки есть разница между "не нашел как включить хотсвоп классов в J9" и "в сети очень мало информации по Java EE".

Ну и потом, пожалуйста, запускайте свое легкое Java EE приложение хотите на маленькой WebSphere Liberty, хотите - на ней же внутри CICS, хотите - на большой классик или WebLogic, а нужна бесплатность - в вашем распоряжении вилдфлай или глассфиш (пайарафиш).

Ну и спрингбут - не панацея, все равно внутри бины надо связывать, а значит читать мануалы вида как подружить в одном котле библиотеки А, Б и С, а потом с этим взлететь.

ZeroSetup комментирует...

Павел, я еще покопался с WAS Liberty Profile. Да, стартует и деплоит быстро, конфигурация радует, достаточно
jsp-2.3,servlet-3.1 чтоб он был как Tomcat 8. AppCenter немного сиротский, под Tomcat psi-probe получше будет, на первый взгляд.
Но, не получилось использовать "Spring loaded" для HotSwap, ни под IBM J9 JVM, ни под Oracle JVM. Даже если деплоймент быстый инициализация приложения занимает драгоценное время, нужен HotSwap. Может подскажете волшебные ключики для IBM J9 или какое-то другое решение для WLP?

CGen комментирует...

Ставите NetBeans Java EE https://netbeans.org/ вместе с GlassFish.
Выбираете "Файл", "Создать проект...", "Примеры", "Java EE".
Доступно примерно 30 разнообразных примеров, которые работают и автоматически деплоятся, если в контекстном меню проекта выбрать "Выполнение".

На netbeans.org огромное количество туториалов на все случаи жизни. И даже(если кому нужно) есть на русском.
Деплоить и отлаживать одним кликом мышки можно и для WebLogic, WildFly, TomCat.

Должен сказать, что с Eclipse порядок вхождения ЗАМЕТНО выше.

Однако если прочитать эту книгу, то никакие туториалы не нужны http://www.litres.ru/entoni-gonsalves/izuchaem-java-ee-7-2/


И вообще у меня с Java EE особых трудностей не возникало. HOWTO особо не нужны. Была непонятка с пассивацией бинов, но чтение спецификации всё расставило по местам. Т.о. HOWTO не нужны - есть первоисточник.

Pavel Samolysov комментирует...

Добавлю к комментарию коллеги так же, что на WAS Dev имеется множество хороших туториалов по использованию Java EE 7 и WAS Liberty, в частности рассказано про новую модель потоков Java EE и как подружить Liberty с RxJava.

Поинт про HotSwap понял, не обещаю ответить в ближайшее же время, но надеюсь поразбираться. Спасибо.

ZeroSetup комментирует...

Заработал HotSwap, у IBM он называется "Hot method replace", описан здесь:

"Hot method replace when debugging applications on WebSphere Application Server"
https://www.ibm.com/support/knowledgecenter/was_beta/com.ibm.websphere.wdt.doc/topics/chotcode.htm?lang=en

Нужно переключить в теге "applicationMonitor" updateTrigger="mbean", запустить WLP сервер в debug режиме,
например: "bin/server debug SERVERNAME" и подключится дебаггером.
Тогда он стартует приложение и начинает работать "Hot method replace". я подключился из Eclipse: Run->Debug Configuration->Remote Java Application.

Тело метода менять можно, но сигнатуру не получится на ходу. Но это уже здорово, можно пробовать использовать при разработке.

У меня приложение не использует JSP, в списке features я оставил только "servlet-3.1". Мда, в "Tomcat" такого не сделаешь. :-)

Pavel Samolysov комментирует...

@ZeroSetup, большое спасибо за ваши комментарии и такой живой интерес к теме. Не часто встречаешь людей, действительно желающих разобраться.

@CGen, большое спасибо за то, что поделились опытом. Одно дело, когда человек на зарплате в IBM рассказывает о Java EE и совсем другое - услышать мнение незаинтересованной стороны.

ZeroSetup комментирует...

@Pavel Samolysov, но есть еще проблема - перезапуск приложения в debug-режиме, как его сделать?
так как Hot Deploy отключен, чтоб он не перестартовал при каждом изменнении, AdminCenter у меня конфликтует по security с приложением(вероятно с Spring Security), пока не хочется копать.
ищу быстрый способ перезапуска приложения. пока перезапускаю включением/отключением feature - servlet-3.1 в конфигурационном файле, что как-то не элегантно.

Pavel Samolysov комментирует...

Если приложение запущено на WLP, в свою очередь запущенном из эклипса, то попробуйте сделать Publish to the Server на виде Servers (CTRL + ALT + P).

ZeroSetup комментирует...

@Pavel Samolysov, у меня не на локальной машине сервер, поэтому этот способ не работат. Если делать из дебаггера "Terminate & relaunch",
то сервер останавливается и все.

Получил первые результаты по скорости, сравнивал выборку из In-Memory BD и отдачу через Spring RESTful Web Service, после "прогрева" где-то сотней запросов получил среднее минимальное время выдачи JSON.

Тестировал:
WAS Liberty Profile V8.5.5.9 (включено только feature servlet-3.1) на IBM J9 VM, version pxa6480sr2fp10-20160108_01 (SR2 FP10)
Apache Tomcat (8.0.27) на Oracle JVM 1.8.0_77-b03
OS: Linux x86-64
CPU: Intel Xeon E5420 @ 2.50GHz
Память JVM для обоих серверов никак не настраивалась, то есть по умолчанию.

Результаты для JSON 9.5 Kb:
WAS Liberty Profile - 23 мс
Apache Tomcat - 12 мс

Хмм, может на большем объеме данных будет по другому, JSON 867Kb:

WAS Liberty Profile - 330 мс
Apache Tomcat - 95 мс

Что-то WLP медленне работает. Что-то делаю не так?

Pavel Samolysov комментирует...

Опубликуйте где-нибудь если не сложно приложение, на котором мерили и код бенчмарка. Посмотрим.

ZeroSetup комментирует...

@Pavel Samolysov, мерял на приложении нашего предприятия, опубликовать поэтому не могу. если руки дойдут - запилю похожее простое приложение протестирую и выложу код.

ZeroSetup комментирует...

@Pavel Samolysov, сделал тест, вот исходники:
https://github.com/zesetup/dojo-spring-billet

в папке "src/test/webload-test" план тестирования для инструмента "Apache Jmeter".

У меня следующий результат по отдаче 104Kb JSON, среднему времени обработки 500 запросов от 5 пользователей:
1. WAS Liberty 8.5.5.8/wlp-1.0.11.cl50820151201-1942 on IBM J9 VM pwa6480sr2fp10-20160108_01 (SR2 FP10) - 40 мс
2. Apache Tomcat/8.0.26 on Oracle 1.8.0_74-b02 64-Bit Server VM - 26 мс

ZeroSetup комментирует...

Несколько дней поработал с WAS Liberty Profile в качестве сервера при разработке. Впечатления следующие.
Несмотря на интеграцию с Eclipse IDE, удобнее и безглючнее скачать WLP самостоятельно и установить, а потом зацепить из Eclipse.
Создавать сервер тоже лучше руками, а не через Eclipse:
bin/server create dev

Для перегрузки методов на-горячую(Hot Code Replace) нужно запускать его в режиме debug.

В случае, если сервер не локальный, то из Eclipse нужно делать "Debug Configuration" -> "Remote Java Application", проблема с тем, что после останова нужно заново вручную запускать решается вечным циклом в bash, например:
while 1; do bin/server debug dev clean; done

Удобная штука для deployment это папка dropin, в нее можно залинковать папку Eclipse куда он кладет скомпилированные классы и отключив "updateTrigger" в "Application Monitoring" и пользоваться "Hot Code Replace".

Вообщем, нормально, учитывая что памяти он кушает поменьше, чем Apache Tomcat. Скорость еще потестиуем.

Pavel Samolysov комментирует...

Ох, какой содержательный фидбек!!!

По поводу скорости, собрал ваш пример, убрал логирование и особенно System.out, потому что Томкат выводит это на консоль, а Либерти - в файл console.log, увеличил число итераций до 10 000, получилось Tomcat - 17 мс., Liberty - 23-26 (на Windows). Хочу попрофайлить и разобраться почему да как.

Unknown комментирует...

Павел, не подскажешь, чисто случайно в последней версии WAS'а не появилась ли возможность создавать не jdbc источники данных? Хочется, чтобы по аналогии с jdbc'шными источниками в консоли администрирования можно было указать все настройки подключения для MongoDB (любой другой вашей любимой NoSQL DB), в том числе, чтобы в них подставлялись credentials, хранящиеся в j2c auth data и т.д.
Гуглится информация, как это происходит в либерти профайле, например, вот в этом видео https://www.youtube.com/watch?v=xTc9oZxS8Do, но там все настройки подключения это обычный xml, от которой очень хотелось бы отказаться при деплое на полноценный сервер. Но нигде в интерфейсе я похожих настроек найти не могу, не подскажешь, они есть там?

Pavel Samolysov комментирует...

К сожалению по этому вопросу ничего не могу подсказать. Да, в Liberty есть feature - mongodb, но в Full Profile'е мне такое не известно.

Если говорить вообще о NoSQL, то знаю, что на z/OS можно дружить в IMS по JDBC или через WOLA, но, догадываюсь, что вы имели ввиду другие NoSQL :)

Unknown комментирует...

Павел, есть у меня еще одна хотелка к серверу приложений, может быть подскажешь, вдруг есть что-нибудь подходящее в WAS9. В общем иногда так случается, что есть в системе некий бэкэнд, который иногда начинает притормаживать. Обращения к этому бэкэнду идут из сервлетов (обычных таких классических синхронных), ну и как следствие тред пул сервлет контейнера очень быстро истощается, что в свою очередь приводит к тому, что отваливаются все страницы, даже те, которые не требуют работы с проблемным бэкэндом. В связи с этим очень хочется иметь несколько тред пулов сервлет контейнера и настраивать соответствие сервлетов и пулов.

ЗЫ: есть очень похожий вопрос на SO - http://stackoverflow.com/questions/26230646/multiple-web-container-thread-pools-in-websphere-is-it-possible, но там речь о 8ке, может в WAS9 что-то изменилось в лучшую сторону? предложенные в ответе варианты, а так же вариант автора вопроса, к сожалению выглядят не очень красивыми и хочется, чтобы сервер все таки умел подобное из коробки (хотя вариант автора вопроса мне больше всего нравится)

Pavel Samolysov комментирует...

Я точно знаю, что, например, в Oracle WebLogic Server есть способ назначить конкретному сервлету свой менеджер работ (WorkManager), однако при этом потоки будут все равно захватываться из общего пула, просто часть потоков будет "застолблена" за конкретным сервлетом.

Поговорил с коллегами из Европы, в WebSphere Application Server нет похожего механизма. Присоединяюсь к совету на SO: разделить приложение на части и разнести их или по разным контейнерам, а лучше - по разным серверам. Могу аргументировать тем, что аналогичная ситуация наблюдается не только с пулом потоков, но и с другими общими ресурсами JVM, например памятью: вы нигде не можете ограничить потребление памяти одним из набора приложений, запущенных на одной JVM. Если у вас разные части приложения обслуживают разные профили нагрузки (например пакетная обработка данных и транзакционная), то вам волей-неволей придется разносить их по разным JVM. Кажется, именно такой подход сейчас называют модным словом "микросервисы".

В принципе, Liberty Profile в этом случае - хорошее решение, т.к. он очень легкий и практически не привносит оверхеда по памяти, можно развернуть в одном образе операционной системы множество экземпляров данного сервера приложений.

Vladimir Kravets комментирует...

В моем случае подобное разделение это будет явный over design, пример с памятью понятен, но на мой взгляд это не совсем тоже самое. В прочем запилил на коленке реализацию на j.u.c.Semaphore + сервлет фильтры, свою задачу решил. Спасибо, за неравнодушие и проведенный инвестигейген.

CGen комментирует...

Добрый день!

Асинхронный сервлет не пробовали? Servlet 3.0 нужен.
@WebServlet(name = "Uploader", urlPatterns = {"/upload"}, asyncSupported = true)
Синхронный переделать на асинхронный совсем несложно. Примеров предостаточно. Возможно, что это даже проще, чем Semaphore.

ZeroSetup комментирует...

@Pavel Samolysov может причина, что у Tomcat лучше HTTP-сервер. Помню было сравнение Apache HTTP с Apache Tomcat и там, к удивлению, в тестах на отдаче статического содержимого выигрывал Tomcat.

Pavel Samolysov комментирует...

@ZeroSetup

Поэкспериментировал с вашим приложением.

Во-первых, убрал логирование в DAO и сервисе.

Во-вторых, убрал генерацию нового UUID'а в конструкторе без параметров Employee(). Данный конструктор каждый раз вызывается Hibernate'ом при загрузке объекта из базы данных и, соответственно, блокирует соседние потоки, т.к. внутри класс UUID использует класс SecureRandom, методы которого синхронизированы. В принципе, мне не понятно, зачем присваивать что-то полю employeeId, если затем это значение будет перезатерто считанным из базы данных.

На мейнфрейме бизнес-класса (т.е. маленьком мейнфрейме, одностворчатый "холодильник") IBM zBC12 на LPAR'е с 6-ю процессорами (4 CP, 2 zIIP), z/OS 2.1, WAS 8.5.5.4/Java 7.1 (похожие значения на WLP 9 beta/Java 8) для 5-ти клиентов получены следующие значения среднего времени отклика:

(min, avg, max) = (13.625, 14.295, 17.042), stdev = 0.854

Benchmark (port) (server) Mode Cnt Score Error Units
EmployeeBenchmark.message 14617 localhost avgt 50 14.295 + 0.423 ms/op

Узкое место, как оказалось, - Hibernate, конкретнее сказать пока не могу, глубоко не копал. Если выпилить Hibernate и реализовать DAO с использованием Spring JDBC, то работает в 5-6 раз быстрее:

Benchmark (port) (server) Mode Cnt Score Error Units
EmployeeBenchmark.message 14617 localhost avgt 50 3.179 + 0.178 ms/op

(min, avg, max) = (2.959, 3.179, 4.906), stdev = 0.360

Ну и уберем вообще все, что касается извлечения данных, оставим только то, что генерирует ответ (Spring MVC, Jackson, Application Server):

Benchmark (port) (server) Mode Cnt Score Error Units
EmployeeBenchmark.message 14617 localhost avgt 50 2.096 + 0.104 ms/op

(min, avg, max) = (1.979, 2.096, 3.174), stdev = 0.210

ZeroSetup комментирует...

@Pavel Samolysov
Ага, интересно
А можете протестировать скорость Apache Tomcat на этой машинке?
Мы ведь выясняем почему Spring+Hibernate быстрее на Tomcat, чем на WAS Liberty Profile.


Pavel Samolysov комментирует...

К сожалению, Tomcat не поддерживается на z/OS, а zLinux на таком количестве ядер у меня под рукой нет. Мой месседж, впрочем, был о том, что архитектура приложения зачастую больше влияет на производительность, нежели детали реализации/развертывания. Впрочем, думаю, если данные будут браться из реальной СУБД (постгрес/оракл/дб2), то разница не будет большой как между томкатом и либерти, так и между орм/jdbc, но это моя интуиция.

ZeroSetup комментирует...

@Pavel Samolysov
не понял, если там есть JVM, то и Tomcat должен бежать

вот, на AIX есть ibm-jdk, там работает Tomcat

Pavel Samolysov комментирует...

Если будет желание - подниму Apache Tomcat на z/OS, коллеги как-то заморачивались, правда не понимаю зачем.

Я вижу, вы продолжаете пилить ваше приложение. Только хотел вас пожурить за вызов load(...).size() в методе getTotalCount() в DAO, но вы уже исправили. Так же советую аннотировать методы getTotalCount(), load(), get(), getByLogin() в сервисе как @Transactional(readOnly = true). В таком случае Spring Framework будет изменять для Hibernate FlushMode на MANUAL, что позволяет избежать тяжелой (особенно на коллекции из over 600-т элементов) операции FLUSH для транзакций, не изменяющих данные. Так же некоторые СУБД умеют дополнительно оптимизировать READ-ONLY транзакции.

Посмотрите так же контроллер, методы createEmployee()/updateEmployee(). Если я правильно понял, вы выбираете запись из БД по логину и хотите убедиться, что не создадите дубль - вторую запись с таким же логином. Однако, т.к. выбираете вы запись для проверки и создаете новую в разных транзакциях, то при большой нагрузке, пока вы решаете создавать запись или нет, кто-то другой уже может создать свою запись с тем же логином. Я думаю, что такие проверки - это часть бизнес-логики и производится должны в сервисном слое, в рамках одной транзакции, либо пессимистически, либо оптимистически.

Pavel Samolysov комментирует...

@ZeroSetup, позвольте вопрос. Здесь в ряде последних комментариев я расскзал, как уменьшить время отклика вашего приложения в 2-3 (в рамках Хибернейт) или в 5-6 (при переходе на Spring JDBC) раз. В замен прошу развернуть приложение на продвигаемом мной продукте. Если бы вы принимали решение, такая сделка была бы для вас интересна?

ZeroSetup комментирует...

@Pavel Samolysov
спасибо за советы.
Пока тестирую WAS Libery Profile как сервер для разработки.

Вы имеете ввиду начать использовать в production?

Pavel Samolysov комментирует...

Да, именно продакшн имею ввиду.

ZeroSetup комментирует...

@Pavel Samolysov
Хм-м... А как убедить, често говоря, и меня тоже? Если бы у нас был JEE-стек, то есть довод.
У нас раньше был Oracle iAS 10g, переезд на Tomcat был облегчением. У нас несколько приложений, но не в JEE-стеке.

В разработке WAS LP все-таки медленнее, и обрабатывает и стартует он медленее Tomcat. Понравился Hot Code Replace, он как-то спокойнее работает, чем Spring Loaded и Hotswap Agent + DCEVM, те часто бомбят лог разными сообщениями.

Кроме того будут еще препятствия не-технического характера...

Если бы JEE-стек и решения принимал я, то да, сделка интересна.

И еще, как-то слабо продвигается WAS LP, на русскоязычных конференциях про него никто не упоминает.

На IBM Bluemix на нем нет бесплатного плана для разработчиков(есть на полном WAS-beta). А это было бы полезно для ознакомления. Вот, например, на openshift.com Red-Hat-а можно бесплатно запуститья на Jboss AS, EAS, Wildfly.

У IBM есть синдром OS/2, когда превосходящую конкурента ОС не стали нормально раскручивать.

Pavel Samolysov комментирует...

Действительно, есть у нас пробелы в работе. Надеюсь, что полученная от вас обратная связь поможет их устранению. Возможно ситуация вызвана тем, что наши специалиты предпочитают адресно общаться с разработчиками/администраторами у конкретных заказчиков, плюс на топовых конференциях тема JavaEE старается как-то замалчиваться (мои ощущения).

Если есть интерес к теме, то я постараюсь давать анонсы мероприятий, посвященных продукту, проходящих у нас в московском офисе.

Большое вам спасибо за общение.

Vladimir Kravets комментирует...

Кстати, в одном из относительно недавних подкастов разбора полетов участвовал Алексей Фёдоров (организатор всяческих российских Java конференций) и среди прочего поднимался вопрос, что на конференции хорошо представлена Oracle Java / OpenJDK etc и практически отсутствуют альтернативные Java вендоры, на что была реакция, что IBM не очень то открыт в этом плане. Так что думаю, если есть возможность и желание выйти на конференцию с хорошими докладами про WAS LP, J9 VM и т.д., то это стоит сделать, т.к. судя по всему интерес к этому есть, как со стороны сообщества, так и со стороны организаторов конференции. Павел, что думаете по этому поводу?

Pavel Samolysov комментирует...

Я общался с ребятами из питерской JUG, поделился контактами архитекторов J9. Проблема наверное в том, чтобы пригласить их в Россию, даже визу нашу получить не так просто, хотя и возможно конечно, локальных же специалистов уровня того же Алексея Шипилева у нас нет. А может быть со стороны сообщества интерес и есть, а организаторам это не надо.

По поводу хорошо и интересно рассказать про WLP, то это дело, здесь думаю сфокуссироваться на опыте внедрения в продуктив и вопросах, которые могут возникнуть, а не просто "мы скейлимся до 10000 серверов в кластере". Как считаете, такая тема могла бы быть интересна?


Vladimir Kravets комментирует...

На счет визы я думаю все решаемо, тем более, если посмотреть состав спикеров JPoint, то там хватает зарубежных докладчиков. По поводу того, что со стороны организаторов есть некий интерес, то послушай минут 5 с http://razbor-poletov.com/2016/05/episode-109.html начиная с 2:09.

По поводу WLP, то конечно интересен опыт использования в продакшене, а не просто маркетинг на тему того, как в лабораторных условиях можно что то красивое соорудить.

Pavel Samolysov комментирует...

Все-таки IBM это что ни говори бренд и очень приятно быть приобщенным к такой уважаемой компании. Владимир, большое спасибо за ссылку, интересно было послушать.

Ваш покорный слуга отметился в 99-м (разбирают мой бенчмарк) и 76-м (Виктор заставил вспомнить молодость и OSGi) выпусках подкаста.

ZeroSetup комментирует...

@Pavel Samolysov
Вы написали, что проверка на уникальность логина должна быть в сервис-слое.
Но это бизнес-логика, как Вы упоминули. Должна ли она тогда быть в объекте модели?

Вообще, по вашему мнению, куда стараться сконцентрировать бизнес-логику.

Я под впечателением книги Эрика Эванса "Domain Driven Design" решаю, что по максмалке нужно в модель, если никак не получается, то в сервисы.

ZeroSetup комментирует...

Другое дело, что проверку на уникальность логина не сделаешь в модели, там нельзя подцепить сервис. Да и все-таки, нелогично, что сам пользователь проверял это, тогда уж некий UserManager.class, что вообщем-то приводит нас к сервису UserService.class.

Pavel Samolysov комментирует...

Споры на тему Rich- vs Anemic Domain Model наверное никогда не прекратятся. Я высказал свое мнение в заметке Несколько слов в защиту шаблона "Анемичная модель предметной области" (Anemic Domain Model).

ZeroSetup комментирует...

@Pavel Samolysov
Есть новости про будущее Java EE?
Какие планы у голубого гиганта?

Pavel Samolysov комментирует...

@ZeroSetup рад снова Вас слышать в моем блоге.

Есть информация, что Oracle озвучит свое видение будущего платформы на очередной JavaOne в сентябре. Из новостей - IBM выпустила WebSphere Application Server 9, теперь не только Liberty, но и Traditional WAS являются JavaEE 7 совместимыми. Oracle тоже не осталась в долгу и анонсировала WebLogic Server 12.2.1.1, но какие именно там изменения я по понятным причинам не разбирался.

Nikita NN комментирует...

c glassfish все ок, поддерживаемая версия http://www.payara.fish/
есть микро вариант http://www.payara.fish/payara_micro для быстрого разворачивания и если не нужен весь ЕЕ функционал

Отправить комментарий

Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!