LINUX.ORG.RU

Java SE 6 Performance White Paper


0

0

Представлен сравнительный обзор показателей производительности и улучшений в масштабируемости Java стандартной версии 6 (Update 2) в сравнении с предыдущей версией платформы Java 5.0.

Java SE 6 включает несколько новых функций и усовершенствований для повышения производительности во многих частях платформы. Улучшения включают:

  • синхронизованные оптимизации выполнения, оптимизации производительности компилятора;
  • новый параллельный уплотняющий сборщик мусора (Parallel Compaction Collector);
  • более эргономичный параллельный низколатентный сборщик мусора (Concurrent Low Pause Collector);
  • ускорение запуска приложений.
Сравнение современной версии Java SE 6 Update 2 ведётся с предыдущей версией платформы -- Java SE 5 FCS.
Так, например, производительность операций ввода-вывода Java 6 в два раза выше, чем у Java 5.0; производительность корпоративных систем по тесту SPECjbb2005 Benchmark возросла на 70%; производительность Java в популярном тесте VolanoMark Benchmark выросла более чем на 40%; скорость запуска приложений увеличилась на 15-20%.

Также приводятся ссылки на материалы, посвящённые отдельным оптимизациям и тестам. В частности, интерес представляет отимизация сборки мусора и уменьшения потребления памяти в отдельной статье "Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning":
http://java.sun.com/javase/technologi...

Другие ссылки приведены по ходу обзора и в его конце.

>>> Подробности

Ответ на: комментарий от dimag

It’s hard to draw a conclusion because the results don’t speak just one language.
But a few things can be said without regretting:

    * ICC is faster than GCC in every benchmark. This is not really new information and will surprise almost no one I guess.
    * Judging from the worst case performance ICC is also the “safest” choice. In its slowest benchmark it was 1.6% behind the fastest contender.
    * Things are not as clear in the java world, but let’s try a ranking: Bea’s weakest point is the NBody benchmark where it’s 22% percent slower than the fastest JDK. Overall fannkuch was the weakest benchmark with a lag of 30% in comparison to ICC. In all other benchmarks it performed better than SUN’s or IBM’s JDKs. The lead in fannkuch to the other JVMs is impressive, so I’d call JRockit the fastest JVM for those benchmarks.
    * The early JDK 7 build 20 is a step in the right direction. It’s performance is better than JDK 6 in every(!) benchmark, even by 26% for NBody and 14% for fannkuch.
    * Saying that C is generally several times faster than java is - according to those benchmarks - simply wrong. If you’re allowed to choose the fastest JVM the worst case for java was 30%. In other benchmarks Sun and JRockit were even able to beat ICC. Not by much but I guess it’s nevertheless just very remarkable that it’s possible to beat ICC. Another interesting figure is that Bea was less than 14% slower than GCC in the worst case (nbody) and was in two cases faster than GCC.
    * Saying that Java is faster than C can also be pretty wrong, especially if you have to stick with one JVM. The worst case in these benchmarks were 30% slower for JRockit to 2.44 times slower for Sun’s JDK 6U2.

dimag
()
Ответ на: комментарий от gaa

> "Вопрос такой: а память, зажранная каждым java-процессом для ОС как выглядит? Как занятая. Хотя в большинстве случаев из-за сборщика мусора и прочих прибамбасов управляемой памяти реально используется не более половины её. Но системе об этом жабка сказать не может, потому при большом количестве таких приложений(именно потому я и говорил про единственный процесс в системе), система будет свопиться, и в своп могут попасть в т.ч. и используемые данные а не только неиспользуемая, но не неосвобождённая требуха. Вот это мне не нравится."

Понятно. Вообще, эта тема выходит далеко за рамки ЛОРа. В .NET для этого случая есть костыль в виде Application Domains (несколько разделенных приложений внутри одного процесса). Были попытки сделать нечто подобное и для Java. Возможно, что некоторые из них реализованы.

> _Как_ мусорщик узнавал о том, что запустилось прожорливое приложение? Не может он этого прямым безкостыльным способом узнать. (анализ вывода /usr/bin/free я считаю костыльным методом, т.к. он не определяет факта наличия "прожорливого" процесса)

Честно говоря, мне трудно отвечать за разработчиков GC.. но могу предположить, что они просто оценивают количество доступной в системе памяти, как виртуальной, так и физической.

dave ★★★★★
()
Ответ на: Реальные тесты! от dimag

>http://www.stefankrause.net/wp/?p=6

А исходники его Mandelbrot, NBody, Spectralnorm, Fannkuch доступны? Хотелось бы самому у себя 1.5 vs 6.0 vs 7.0b померять. И к тому же тут http://no-gritzko-here.livejournal.com/3725.html тоже сравнение с C есть. Так кто же быстрее? Может быть действительно для J2EE критичнее работа GC, чем просто голое быстродействие из-за специфики работы с тормозными базами данных? А для программ а-ля Mathematica/MathCad можно и на C перемножение матриц переписать?

Мне все равно есть с чем сравнивать, у меня на винде любая программа на J26.0u3 запускается быстрее, чем Catalist Control Center на .NET Framework 2.0. Скоро, я подозреваю, Catalyst Control Center перепишут на Silverlight :-) :->

>А если мне нужна быстрая технология _сегодня_, а не теоретическая возможность, что когда-нибудь её ускорят? Выход один: использовать другую технологию ;)

>Напоминаю, что вменяемым выходом оказалось отказаться от java-утилиты.

Да ради б--а. Мы все рады за тебя, пиши на своем Brainfuck-е и сиди дальше в своей тумбочке. Там тебе тепло и спокойно. Cobol тоже до сих пор живет. И C живет. И пользуйся другой технологией раз ты все уже для себя решил.

anonymous
()
Ответ на: Реальные тесты! от dimag

Да и к тому же имхо в реальных приложениях основное время работы занимают наверняка не криптоалгоритмы и циклы от 1 до 1000, а создание иерархий объектов, вызовы цепочек методов, освобождение памяти, параллельное исполнение тредов. Ведь не зря говорят, что JBoss и BEA серверы выдают трейсы с чуть ли не сотнями уровнями вложенности. Так работают приложения реального мира и ничего с этим не сделать, а микробенчмарки для 1 процессора по сложению чисел от 1 до 100 на 4 ядерном сервере ничего не доказывают

anonymous
()
Ответ на: комментарий от r

>Нет просто СУБД - боттлнек. Очень давно уже производительность JEE серверов упирается в производительность DBMS. Потому на серверах в энтерпрайзе жаба и доминирует - все равно быстрый мускуль будет тормозить так что никакая жаба не страшна.

Что интересно, это довод против применения Java, так как если сервер простаивает, ожидая БД, то не проще ли сделать это всё на скриптовом языке и сэкономить на поддержке?

Это происходт в криво спроектированных приложениях, когда бизнес логика переносится в БД особбенно если группа DBA получает сликом много влияния в корпорации.

Нормально спроектированное приложение распределяет нагрузку равномерно по всем уровням.

Хотя я, лично не возражаю. Больше таких "ентерпрайз разработчиков", больше работы для нас, контракторов, по приведению этого в работоспособное состояние.

NonHuman ★★★
()
Ответ на: комментарий от tailgunner

>В таких задачах работает в основном "родной" код СУБД и сетевого стека, разве нет?

садитесь, два!

anonymous
()
Ответ на: комментарий от tailgunner

>В таких задачах работает в основном "родной" код СУБД и сетевого стека, разве нет?

садитесь, два!

anonymous
()
Ответ на: комментарий от anonymous

>> В таких задачах работает в основном "родной" код СУБД и сетевого стека, разве нет?

> садитесь, два!

Сорви покровы, мудрейший - как оно на самом деле? o_O

tailgunner ★★★★★
()
Ответ на: комментарий от NonHuman

>Что интересно, это довод против применения Java, так как если сервер простаивает, ожидая БД, то не проще ли сделать это всё на скриптовом языке и сэкономить на поддержке?

Батенька, на скриптовом языке "просто так" приложение в пару-тройку миллионов строк кода не переписать.

anonymous
()
Ответ на: комментарий от NonHuman

>Это происходт в криво спроектированных приложениях, когда бизнес логика переносится в БД особбенно если группа DBA получает сликом много влияния в корпорации.

Для лобомотов-нон-хьюманов - это практически единственно верный путь проектирования больших систем у которых определено понятие "время отклика" и оно меньше ну скажем часа.
А то что лобомоты пишут прогноз погоды на завтра который считается неделю - мы и так знаем :)

anonymous
()
Ответ на: комментарий от anonymous

>Батенька, на скриптовом языке "просто так" приложение в пару-тройку миллионов строк кода не переписать.

Ну да тут помошник нужен. А лучше - два. Отдела. И саппорт в индусии.

Java -> Python (or Ruby) mens at first shrink your source code size by factor 100 ....

anonymous
()
Ответ на: комментарий от anonymous

Я писал написать а не переписать уже существующее приложение.

NonHuman ★★★
()
Ответ на: комментарий от NonHuman

>Чем больше, вот таки анонов будет строить риложения, тем больше спрос на контракторов.
>И это хорошо. :)
>NonHuman

Ты там дрочишь что ли? До чего дошел прогресс - раньше фотки пользовали - теперь ЛОР с жабатопиком 8-о
Вот такие вот они - нон-хуман контракторы на которых большой спрос :)

anonymous
()
Ответ на: комментарий от anonymous

>А то что лобомоты пишут прогноз погоды на завтра который считается неделю - мы и так знаем :)

Интересно было бы посмотреть на прогнозер погоды в виде хранимых процедур.

ЗЫ: я работал в области прогнозирования погоды. Там люди кластеры строят для решения систем диф. уравнений движения атмосферных масс.

anonymous
()
Ответ на: комментарий от anonymous

>Java -> Python (or Ruby) mens at first shrink your source code size by factor 100 ....

Не смешите мои тапочки, пожалуйста.

Ну и для начала мне нужно: 1. Монитор распределенных транзакций (должна же всего пара строк на Руби быть, да?) 2. Аналог Oracle Coherence (еще пара десятков строк). 3. Hibernate, InteliRuby IDEA ну и Eclipse - это пара вечерков на Питоне.

anonymous
()
Ответ на: комментарий от anonymous

>>А то что лобомоты пишут прогноз погоды на завтра который считается неделю - мы и так знаем :)

>Интересно было бы посмотреть на прогнозер погоды в виде хранимых процедур.

Да пожалуй я бы и сам опупел увидев такое :) Но я то не о том вещал!

>ЗЫ: я работал в области прогнозирования погоды. Там люди кластеры строят для решения систем диф. уравнений движения атмосферных масс.

И мне пришлось коснуться. Внимание вопрос! Что на тех кластерах? Java? А, ну вот то то и оно ...

HPC - это люди которых ужасные сишные указатели и кровожадные плюсовые деструкторы никогда не пугали. Но и в рациональности им тоже не откажешь - когда _оно_ посчитано _его_ чем только не рисуют :) Хоть питоном хоть жабой ...

anonymous
()
Ответ на: комментарий от anonymous

Анону уже ничего возразить, так начал своими фантазиями делиться.
Жаль бедолагу. :(

NonHuman ★★★
()
Ответ на: комментарий от anonymous

> Ну и для начала мне нужно: 1. Монитор распределенных транзакций 2. Аналог Oracle Coherence . 3. Hibernate, InteliRuby IDEA ну и Eclipse

анонимус привык к костылям и требует, чтобы их портировали на все возможные платформы?

gaa ★★
()
Ответ на: комментарий от gaa

>анонимус привык к костылям и требует, чтобы их портировали на все возможные платформы?

Ну если ты считаешь распределенные транзакции "костылями" - то с тобой разговор короткий. Из одного слова: RTFM.

Точно так же - поищи на досуге что такое Oracle Coherence. И потом попытайся понять почему за него платят большие бабки.

Я участвовал в двух больших проектах (сотни тысяч LOC) на Питоне. Честно говоря, какого-то изменения в производительности труда не заметил. Если на Java мне приходится писать громоздкий код во многих местах, то в Питоне мне приходится писать тест-кейсы на каждый чих.

Ну и статической проверки типов тоже жутко не хватает - после IDEA с ее автоматическими рефакторингами автозамена в ViM кажется убогим уродцем.

anonymous
()
Ответ на: комментарий от anonymous

>И мне пришлось коснуться. Внимание вопрос! Что на тех кластерах? Java? А, ну вот то то и оно ... Кстати, использовали и Java. Хотя в основном Фортран был с MPI.

>HPC - это люди которых ужасные сишные указатели и кровожадные плюсовые деструкторы никогда не пугали. Но и в рациональности им тоже не откажешь - когда _оно_ посчитано _его_ чем только не рисуют :) Хоть питоном хоть жабой ... HPC тоже разный бывает. Если нужно быстро что-то просчитать для какого-нибудь исследования - то и Java вполне используют. Так как время написания существенно превышает время работы.

Если нужно что-то для каждодневных рассчетов - то иногда оптимизируют на С++/Fortran. Но не всегда, кстати.

anonymous
()
Ответ на: комментарий от anonymous

>> анонимус привык к костылям и требует, чтобы их портировали на все возможные платформы?

> Ну если ты считаешь распределенные транзакции "костылями" - то с тобой разговор короткий. Из одного слова: RTFM.

Не считаю, просто наквотил лишнего :)

> Точно так же - поищи на досуге что такое Oracle Coherence. И потом попытайся понять почему за него платят большие бабки.

Поискал. Действительно, для не-java написать нечто "JCache-compliant" сложно :)

А оракел никогда не стеснялся драть "большие бабки" за свои продукты.

> Я участвовал в двух больших проектах (сотни тысяч LOC) на Питоне. Честно говоря, какого-то изменения в производительности труда не заметил. Если на Java мне приходится писать громоздкий код во многих местах, то в Питоне мне приходится писать тест-кейсы на каждый чих.

Ну да, unitary tests убивают все преимущества скриптовых языков при разработке. Зато потом в результирующий код их(тесты) включать не надо.

gaa ★★
()
Ответ на: комментарий от gaa

>Поискал. Действительно, для не-java написать нечто "JCache-compliant" сложно :) Так не в имени дело, а в функциональности. Coherence - это распределенный транзакционный кэш (нет, не надо мне показывать на memcached, он и десятой доли возможностей Coherence не имеет; самое главное, memcached - не транзакционный). Причем он дьявольски быстрый - мы его используем как распределенную между 20 хостами in-memory базу для кэширования данных.

>А оракел никогда не стеснялся драть "большие бабки" за свои продукты. До этого Coherence разрабатывался небольшой компанией Tangasol - Оракул купил ее в этом году весной.

>Ну да, unitary tests убивают все преимущества скриптовых языков при разработке. Зато потом в результирующий код их(тесты) включать не надо. Какая разница-то? Мне на размеры "результирующего кода" абсолютно плевать. Да и скомпилированая и сжатый с помощью pack200 Java байт-код будет занимать меньше места, чем скриптовой код (проверено).

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

anonymous
()
Ответ на: комментарий от anonymous

>>Ну да, unitary tests убивают все преимущества скриптовых языков при разработке. Зато потом в результирующий код их(тесты) включать не надо.

> Какая разница-то? Мне на размеры "результирующего кода" абсолютно плевать. Да и скомпилированая и сжатый с помощью pack200 Java байт-код будет занимать меньше места, чем скриптовой код (проверено).

А в скорости совсем никакой разницы нет?

> Главное, что никакой волшебной серебряной пули скриптовые языки не дают. В небольших проектах - может быть их динамичность и дает плюсы. В больших и средних - уже начинают проявляться их недостатки.

Жава развращает, начинают на ней создавать огромные проекты. Попросту не верю, что проект нельзя поделить на мелкие части, чтобы он не был огромным.

gaa ★★
()
Ответ на: комментарий от gaa

> unitary tests убивают все преимущества скриптовых языков

Судя по тому, что ты неправильно пишешь название ("unit tests"), ты ими и не пользуешься.

tailgunner ★★★★★
()
Ответ на: комментарий от NonHuman

>>Нет просто СУБД - боттлнек. Очень давно уже производительность JEE серверов упирается в производительность DBMS. Потому на серверах в энтерпрайзе жаба и доминирует - все равно быстрый мускуль будет тормозить так что никакая жаба не страшна.
>Что интересно, это довод против применения Java, так как если сервер простаивает, ожидая БД, то не проще ли сделать это всё на скриптовом языке и сэкономить на поддержке?

Точно раз быдло жаба торррррррмозит. Возьмем лучше еще более торррррммммммозную вещь скрипты.

>Это происходт в криво спроектированных приложениях, когда бизнес логика переносится в БД особбенно если группа DBA получает сликом много влияния в корпорации.
Точно к черту обработку данных на сервере ДБ, мы лучше будет гонять гига и гигабайты по сети, че ей простаивать. В натуре. Мы же крутые, витая пара пусть послужит спиралью накала, пусть греет воздух, а то блин холодно ваще и из окна дует.

ilnurathome
()
Ответ на: комментарий от tailgunner

>> unitary tests убивают все преимущества скриптовых языков

> Судя по тому, что ты неправильно пишешь название ("unit tests"), ты ими и не пользуешься.

Судя по различию в написании, в Вашей фирме они называются не так как в нашей :) Помнится, ньюкамером я просидел месяц в тестописательстве, въезжая в продукт.

gaa ★★
()
Ответ на: комментарий от gaa

> Судя по различию в написании, в Вашей фирме они называются не так как в нашей :)

PyUnit и CppUnit, ничего необычного.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> Судя по различию в написании, в Вашей фирме они называются не так как в нашей :)

> PyUnit и CppUnit, ничего необычного.

угу, а для tcl?

gaa ★★
()
Ответ на: комментарий от gaa

>>> Судя по различию в написании, в Вашей фирме они называются не так как в нашей :)

>> PyUnit и CppUnit, ничего необычного.

> угу, а для tcl?

Тиклем не пользуемс, да и в топике речь шла о Яве(JUnit)/Питоне(PyUnit)/Руби(хзчто), но никак не о Тикле. А что, в нем unit testing называется unitary testing?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Тиклем не пользуемс, да и в топике речь шла о Яве(JUnit)/Питоне(PyUnit)/Руби(хзчто), но никак не о Тикле. А что, в нем unit testing называется unitary testing?

Ну что за придирки? В том проекте пользовался тикль, соответственно для него Junit и PyUnit ну никак подойти не могут. А уж кто назвал тесты для той софтины "unitary tests"(а я это собезьянничал), мне неизвестно.

gaa ★★
()
Ответ на: комментарий от gaa

>А в скорости совсем никакой разницы нет?

Ну как сказать. Разница есть - Java быстрее скриптов, это факт. Быстрее Java тут только C++ может быть, но на нем писать серверные приложения - это надо быть врагом самому себе (у меня 10 лет опыта программирования на С++, если интересно).

>Жава развращает, начинают на ней создавать огромные проекты. Попросту не верю, что проект нельзя поделить на мелкие части, чтобы он не был огромным.

Ну поделил (у меня почти все проекты сильно модульные). Дальше-то что? От перестановки мест слагаемых сумма не меняется. Т.е. писать и отлаживать придется все равно то же количество кода, да еще и интерфейсы между модулями рисовать надо будет.

В общем, попробуйте реальный enterprise-проект написать, где требуются ГАРАНТИИ целостности данных. Это весьма сильно отличается от написания движка блогов, где пропавший пост или недоступность сервера является мелкой неприятностью, а не авралом. Сразу спесь спадет про недоязыки типа Java или C#.

anonymous
()
Ответ на: комментарий от anonymous

>> А в скорости совсем никакой разницы нет?

> Ну как сказать. Разница есть - Java быстрее скриптов, это факт.

Возможно. Но учитывая неторопливость доступа к базе и сети, можно разницей пренебречь. Вы ж не пишете на Java числодробилки!

> (у меня 10 лет опыта программирования на С++, если интересно).

...сказал анонимус ;)

>> Жава развращает, начинают на ней создавать огромные проекты. Попросту не верю, что проект нельзя поделить на мелкие части, чтобы он не был огромным.

> Ну поделил (у меня почти все проекты сильно модульные). Дальше-то что? От перестановки мест слагаемых сумма не меняется.

Значит не так поделено. Кстати, из фразы "ну поделил" следует, что Вы - архитектор приложения?

> Т.е. писать и отлаживать придется все равно то же количество кода, да еще и интерфейсы между модулями рисовать надо будет.

Нет, если использовать для каждого модуля подходящий язык, а не один и тот же повсюду.

> В общем, попробуйте реальный enterprise-проект написать, где требуются ГАРАНТИИ целостности данных.

Гарантия целостности - она не в технологиях, а в головах программистов. Вон у нас продукт(находящийся в разработке) валится через раз и теряет те самые данные, хоть и написан с использованием анонимусоугодной Java EE.

P.S. Кстати, меня слегка утруждает говорить со стенкой^W анонимом, так что предлагаю Вам зарегистрироваться.

gaa ★★
()
Ответ на: комментарий от ilnurathome

>ilnurathome >Точно раз быдло жаба торррррррмозит. Возьмем лучше еще более торррррммммммозную вещь скрипты.
Тормозит ilnurathome а не Java. Где я писал, что Java тормозит? Комлекс непоноценности? Тяжёлое детство дереянные сандали?

>ilnurathome >Точно к черту обработку данных на сервере ДБ, мы лучше будет гонять гига и гигабайты по сети, че ей простаивать. В натуре. Мы же крутые, витая пара пусть послужит спиралью накала, пусть греет воздух, а то блин холодно ваще и из окна дует.
Просто пи..ец какой-то. Где я писал что БД не нужна? Расскажи мне "ilnurathome", что легче поддерживать 100mb Java кода или 30mb SQL скриптов?
Где же ты видел Datacenter с котором сервера витой парой соединены?
Видел я приложения полностью написанные на SQL. Одно совсем недавно: MSSQL+sqlXml+Xslt. Вся бизнес логика в SQL. Триггеров хватило бы на 1000 нормальных приложений. Оно не пережило ухода главного разработчика. При попетке изменений всё рассыпалолсь.
Разработка стоила порядка $10 млн b 2 года. Выбросили практически всё, кроме Business Requirements.

NonHuman ★★★
()
Ответ на: комментарий от anonymous

Меня просто потряс пафос:
anon>Ну и для начала мне нужно: 1. Монитор распределенных транзакций

Зачем ва распределённые транзакции, если у вас и один сервер простаивает в ожидании результатов из БД?

Но, если на то пошло, байдингов для CORBA и COM хватает для любого скриптового языка(для bash не видел).

NonHuman ★★★
()
Ответ на: комментарий от anonymous

Ну и чем отличается гаратия цлостности на Java/.Net от Perl?
:))))))))))))))))))))))))))))))))))))))))))))))))))))

NonHuman ★★★
()
Ответ на: комментарий от gaa

>Жава развращает, начинают на ней создавать огромные проекты. Попросту не верю, что проект нельзя поделить на мелкие части, чтобы он не был огромным.

C развращает, начинают на нем создавать огромные проекты. Попросту НЕ ВЕРЮ, что linux kernel нельзя поделить на мелкие части, чтобы он не был монолитным и огромным.

anonymous
()
Ответ на: комментарий от anonymous

> Попросту НЕ ВЕРЮ, что linux kernel нельзя поделить на мелкие части, чтобы он не был монолитным и огромным

Правильно не веришь... он на самом деле состоит из многих мелких, автономных частей :D

tailgunner ★★★★★
()
Ответ на: комментарий от NonHuman

>Зачем ва распределённые транзакции, если у вас и один сервер простаивает в ожидании результатов из БД?

Батенька, "распределенные транзации" - это не транзакции, распределенные на кластер компьютеров, а транзакции, захватывающие несколько транзакционных источников. Распределенные транзакции требуют двухфазного (или трехфазного) коммита.

В общем, читать сюда: http://en.wikipedia.org/wiki/Two-phase_commit

anonymous
()
Ответ на: комментарий от gaa

>Возможно. Но учитывая неторопливость доступа к базе и сети, можно разницей пренебречь. Вы ж не пишете на Java числодробилки!

Можно, я не спорю. Нужно просто заранее писать все масштабируемо.

>> (у меня 10 лет опыта программирования на С++, если интересно). >...сказал анонимус ;) Мой ник на RSDN - Cyberax. Почта: Alex.Besogonov_на_gmail_точка_com

>Значит не так поделено. Кстати, из фразы "ну поделил" следует, что Вы - архитектор приложения?

Ага. Точнее, я второй архитектор приложения :) Сначала я занимался разбором и рефакторингом того, что сделал первый архитектор.

>Нет, если использовать для каждого модуля подходящий язык, а не один и тот же повсюду.

Фантастика. DSL в паре мест помог бы, но поддерживать мессиво из систем на разных языках - нет, спасибо. Естественно, я не считаю всяких мелких поддерживающих утиллит, скриптов сборки и прочей мелочевки.

>Гарантия целостности - она не в технологиях, а в головах программистов. Вон у нас продукт(находящийся в разработке) валится через раз и теряет те самые данные, хоть и написан с использованием анонимусоугодной Java EE.

Вот стандартная задача для меня: записать данные в базу, кэш и отослать оповещение через JMS. Без распределенных транзакций ее сделать гарантировано правильно невозможно. На JEE я эту задачу сделаю даже не напрягаясь.

На Python/Ruby - придется искать монитор транзакций (из нормальных подключаемых я знаю только MS DTC), искать как к нему подключать источники данных и так далее.

>P.S. Кстати, меня слегка утруждает говорить со стенкой^W анонимом, так что предлагаю Вам зарегистрироваться.

Нет, я на LORе регистрироваться не хочу. Я сюда чисто для отдыха прихожу флеймить. Для более серьезных флеймов есть RSDN...

anonymous
()
Ответ на: комментарий от anonymous

Анонимус, архитектор распределённого j2ee-приложения на базе оракловских технологий, читатель rsdn, любитель огромных приложений-комбайнов в рамках одного языка и технологии...

В общем, советую Вам начинать читать матан, а то уже скоро сессия, обидно будет вылететь из ВУЗа на первом курсе :)

gaa ★★
()
Ответ на: комментарий от gaa

>Анонимус, архитектор распределённого j2ee-приложения на базе оракловских технологий, читатель rsdn, любитель огромных приложений-комбайнов в рамках одного языка и технологии...

Кто сказал, что "на базе оракловых технологий"? Это, видимо, какой-то другой Аноним был.

И я уже давно не в университете :)

anonymous
()
Ответ на: комментарий от anonymous

Сынуля, читал бы хоть, то на что ччылки приводишь:
two-phase commit protocol is a distributed algorithm that lets all nodes in a distributed system agree to commit a transaction. The protocol results in either all nodes committing the transaction or aborting, even in the case of network failures or node failures. However, the protocol will not handle more than one random site failure at a time

NonHuman ★★★
()
Ответ на: комментарий от NonHuman

> Где я писал, что Java тормозит? Комлекс непоноценности? Тяжёлое детство дереянные сандали?
Так это чьи слова были ?
>>Нет просто СУБД - боттлнек. Очень давно уже производительность JEE серверов упирается в производительность DBMS. Потому на серверах в энтерпрайзе жаба и доминирует - все равно быстрый мускуль будет тормозить так что никакая жаба не страшна.
>Что интересно, это довод против применения Java, так как если сервер простаивает, ожидая БД, то не проще ли сделать это всё на скриптовом языке и сэкономить на поддержке? Заменить _java_ на _скрипты_.

>витой парой соединены
Это был стеб. Соедини их хоть чем угодно, все равно.

>легче поддерживать 100mb Java кода или 30mb SQL скриптов?
А ты разве не вкурсе что из sql можно и java методы вызывать и 'C' методы. (Хотя про mssql незнаю, в oracle можно)
От тригеров тебе все равно никуда недеться если хочешь уберечь базу от ошибок в так сказать "прикладном" ПО.

Я отнюдь не говорю, что надо отказаться например от сервера приложений, он все равно нужен, но многие манипуляции с базой можно выполнять и на сервере БД, чем гонять большой объем данных кудато еще.

ilnurathome
()
Ответ на: комментарий от NonHuman

>two-phase commit protocol is a distributed algorithm that lets all nodes in a distributed system agree to commit a transaction.

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

Двухфазный коммит может "handle more than one random site failure at a time" (с помощью транзакционных логов), но разрешение такой проблемы часто требует вмешательства человека.

anonymous
()
Ответ на: комментарий от ilnurathome

>А ты разве не вкурсе что из sql можно и java методы вызывать и 'C' методы. (Хотя про mssql незнаю, в oracle можно)

Ага, и получать еще и мессиво кода на С.

Без триггеров вполне можно жить. _Единственное_ применение триггеров, которое я одобряю - это обеспечение дополнительной целостности, не выражающейся через констрейнты.

anonymous
()
Ответ на: комментарий от anonymous

>Ага, и получать еще и мессиво кода на С.
Ага и обработывать большие массивы данных скриптами. Как предложил NonHuman. Вместо обработки их в слое j2ee

Нет уж пусть лучше или БД этим занимается или сервер приложений, чем отдавать обработку скриптам. Опять же в зависимости от данных.

ilnurathome
()
Ответ на: комментарий от ilnurathome

Мэн, толи я русский начал забывать, толи ты обкурился. Где в цитате говорится про то, что Java тормозит?

Ты можешь просто ответить на поставленный вопрос а не разводить демагогию?
Что легче поддерживать 100mb Java кода или 30mb SQL скриптов?
Мои симпатии на стороне Java.

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

>Я отнюдь не говорю, что надо отказаться например от сервера приложений, он все равно нужен, но многие манипуляции с базой можно выполнять и на сервере БД, чем гонять большой объем данных кудато еще
Это спор, по типу - сам придумал аргументы, сам их опровергаю. Случайно не представительница слабого пола?

NonHuman ★★★
()
Ответ на: комментарий от ilnurathome

>ilnurathome>Ага и обработывать большие массивы данных скриптами. Как предложил NonHuman. Вместо обработки их в слое j2ee

Это наглый пиздёж. Научись читать прежде чем юродствовать на форуме.

NonHuman ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.