Можно ли на Java-е писать быстрые веб-приложения? [Re: А посовет]
Хорошая производительность результатаИМХО говорить о производительности при работе с явой — наивность.
Можно сколько угодно говорить о том, что плохо написаны всякие одноглазики (2500+ серверов, пипец... но факт остаётся фактом: даже тормознутый ПХП кажется реактивным самолётом на фоне явы.
>даже тормознутый ПХП кажется реактивным самолётом на фоне явы.
На это вспоминается новость про то, как на Java написали парсер викитекста, тормознее уже имеющегося, написанного на PHP: http://www.opennet.ru/opennews/art.shtml?num=30435.
это ты про то, что разобрать грамматику и построить AST медленнее, чем просто пройтись про тексту и преобразовать его в html?
ну напиши аналог этого явовского парсера на пхп и посмотрим, что в итоге будет работать медленнее.
ну напиши аналог этого явовского парсера на пхп и посмотрим, что в итоге будет работать медленнее.
самописные парсеры на пхп пишут только конченные идиоты.
если уж что-то надо эдакое, то писать уже надо на си (как модуль к пхп или сторонняя прога)
если уж что-то надо эдакое, то писать уже надо на си (как модуль к пхп или сторонняя прога)
т.е. пхп оказывается реактивным, когда из него выкидываешь весь пхп-шный код и переписываешь его как модуль на C?
А вот на яве уже так нельзя. 
У нас же нет цели что-то написать на языке. Есть цель сделать чтобы работало, а вот тут у явы, прямо скажем, не быстро и прожорливо.
У нас же нет цели что-то написать на языке. Есть цель сделать чтобы работало, а вот тут у явы, прямо скажем, не быстро и прожорливо.
>А вот на яве уже так нельзя.
это что, религия запрещает что-ли?
>У нас же нет цели что-то написать на языке.
если хочется сравнить быстродействие программы, написанной на языке, то есть
>Есть цель сделать чтобы работало, а вот тут у явы, прямо скажем, не быстро и прожорливо.
продолжай жить в своем выдуманном мире.
это что, религия запрещает что-ли?
>У нас же нет цели что-то написать на языке.
если хочется сравнить быстродействие программы, написанной на языке, то есть
>Есть цель сделать чтобы работало, а вот тут у явы, прямо скажем, не быстро и прожорливо.
продолжай жить в своем выдуманном мире.
если хочется сравнить быстродействие программы, написанной на языке, то естьсадитесь, двойка.
Не бывает быстродействия программ. Бывает произодительность системы в целом, её и надо измерять. А также отказоустойчивость, надёжность и пр.
Понаделали тестов подсчёта факториалов и сейчас с умным видом что-то утверждают про "всего в полтора раза медленнее".
Пианист, давно хотел спросить, как ты прокомментируешь вот эту новость? Понадобилась производительность, и вдруг выбрали решение на Java, как так?
http://habrahabr.ru/blogs/search_engines/105710/
http://habrahabr.ru/blogs/search_engines/105710/
Поскольку Twitter любит open source, то в качестве начальной точки решения выбрали поисковую библиотеку Apache Lucene, написанную на Java.
Почему ты не допускаешь самое простое объяснение?
Далеко не всегда и далеко не везде люди принимают решения исходя из здравого смысла. Разницу между мнением авторитета и авторитетом мнения чувствуешь?
Да и разве хорошо там у твитера с поиском, коли твиты более 7 дней не живут?
да, твиттер тормозит достаточно сильно (по сравнению с фейсбуком, скажем так что все логично как раз!
Они взяли готовое решение, сильно его допилили, купив компанию из 6 человек, которая раньше занималась именно допиливанием люцены. А готовых автономных решений для fts всего 2: lucene (теперь solr) и sphinx. Возможно, взяли первое, что подошло.
Собственно, поиск в твитере работает, а значит всё хорошо. А сколько серверов у них там стоит — не так и важно, в общем-то.
Собственно, поиск в твитере работает, а значит всё хорошо. А сколько серверов у них там стоит — не так и важно, в общем-то.
сапрыкин с горбачевым пытались на афише сделать прямую твиттер-трансляцию евровидения и вот, что из этого вышло:
0.22 ВНИМАНИЕ! Твиттер сказал нам с Юрием, что мы превысили допустимый лимит апдейтов и чтобы мы попробовали через несколько часов. Но через несколько часов уже все закончится. Попробую пописать комментарии непосредственно к посту. Простите, что такой реприманд неожиданный — недотестировали систему. АГ
>Не бывает быстродействия программ. Бывает произодительность системы в целом, её и надо измерять. А также отказоустойчивость, надёжность и пр.
пока видны только слова, где написанный тобой быстрый, отказоустойчивый, надёжный и прочая и прочая форум на C?
пока видны только слова, где написанный тобой быстрый, отказоустойчивый, надёжный и прочая и прочая форум на C?
(Устало...)
Зачем писать форум? Этот вполне себе работает, рекламу убрали же.
Зачем писать форум? Этот вполне себе работает, рекламу убрали же.
... купив компанию из 6 человек, ...почему они не купили Пианиста? И остальных “высоконагруженных” ребят с форумлокала?
Недостаточно серьезный проект для него, думаю
почему они не купили Пианиста?
Не бывает быстродействия программ. Бывает произодительность системы в целом, её и надо измерять. А также отказоустойчивость, надёжность и пр.Ты пока не сильно дальше от тех, которые с умным видом, ушел.
Понаделали тестов подсчёта факториалов и сейчас с умным видом что-то утверждают про "всего в полтора раза медленнее".
Не видел ни одного твоего примера, мол вот тут вот джава безнадежно тормозит, а вот тут вот такую же задачу написали на си/асме/питоне/хаскеле/? и получили бонус в пицот попугаев.
Можем сразу и пиписьками померяться, чего уж. Я вот тебе могу навскидку привести пару ссылок - раз, два.
Пока есть только одно место, где я могу согласиться, что джава - тормоз. Это когда у вас риалтаймовые требования к обработке запросов <10мс. Тогда у вас начнутся проблемы с гц, которые действительно замучаешься твикать. Такие продакшен требования очень редки.
Все остальные проблемы решаются прямыми руками и думающей головой.
Но, конечно, ругать джаву в определенных кругах модно. Это что-то сродни ненависти к майкрософту. Поэтому, конечно, вы ругайте джаву и гордитесь своим ххх.
Но пока вы будете писать свой высокопроизводительный c++ application server и дебажить его в валгринде, я напишу то же самое с той же производительностью не изобретая велосипед, а потом пойду что-нибудь новое почитаю. Например про быстрое онлайн построение суффиксных деревьев.
Пока есть только одно место, где я могу согласиться, что джава - тормоз. Это когда у вас риалтаймовые требования к обработке запросов <10мс.Чувак, ты как всегда пишешь по существу. Респект.
JRockit тоже не катит для риалтаймовых приложений? Или ты его и имел в виду?
> Чувак, ты как всегда пишешь по существу. Респект.
Сенкс =)
> JRockit тоже не катит для риалтаймовых приложений? Или ты его и имел в виду?
Афаик, сейчас JRockIt не имеет серьезных преимуществ по производительности перед сановской веткой. Но с ним я дела не имел, так что наверняка утверждать не могу.
А в JDK7, как я понимаю, разницы между ними не будет вовсе, разве что в платной версии JRockIt будут некие энтерпрайзи фичи, не имеющие отношения к базовой производительности jvm.
Мой пост выше, вообще говоря, применим к любому garbage-collected языку, ибо человечество пока не придумало полностью concurrent алгоритм для сборки мусора. Это значит, что иногда виртуальная машина будет полностью приостанавливать все юзертреды на некоторое время для сбора мусора. Афаик, лучшее, что сейчас есть - это mostly-concurrent gc.
Вкратце, там фишка в том, что для minor gc cycle юзертреды не стопятся. В major gc cycle юзертреды стопятся только в двух критичных этапах, остальное время сборка происходит в concurrent режиме. Более того, этому GC можно задать параметр, мол в major cycle старайся не делать паузы чаще чем столько-то, не делать их дольше чем столько-то. Оно тогда, пока хватает памяти, не будет вылезать за эти ограничения.
Однако, очевидно, если его зажать слишком сильно, то оно перестанет справляться со сборкой мусора. И когда память кончится, будет запущен честный major gc cycle с долгой остановкой всех тредов и игнорированием заданных временных рамок.
Соответственно, если вы наступили на такие грабли - то надо идти профайлить код, смотреть что за объекты у вас создаются при обработке запроса. Большая вероятность того, что вы сможете очень существенно ограничить создание новых объектов, по максимуму используя примитивные типы на стеке, мьютабл объекты, отказываясь от джава коллекшенов, итд - короче, юзать все то, что не триггерит создания множества новых объектов.
Если и это не помогает - то тут уже пора придумывать distributed схему с каким-нибудь round robin'ом, чтобы живые запросы шли гарантированно на jvm с достаточным кол-вом памяти, а в бекграунде принудительно пускать gc.
Но это уже ювелирная работа. Возможно проще и наверняка надежнее будет тупо переписать все на какой-нибудь си.
Сенкс =)
> JRockit тоже не катит для риалтаймовых приложений? Или ты его и имел в виду?
Афаик, сейчас JRockIt не имеет серьезных преимуществ по производительности перед сановской веткой. Но с ним я дела не имел, так что наверняка утверждать не могу.
А в JDK7, как я понимаю, разницы между ними не будет вовсе, разве что в платной версии JRockIt будут некие энтерпрайзи фичи, не имеющие отношения к базовой производительности jvm.
Мой пост выше, вообще говоря, применим к любому garbage-collected языку, ибо человечество пока не придумало полностью concurrent алгоритм для сборки мусора. Это значит, что иногда виртуальная машина будет полностью приостанавливать все юзертреды на некоторое время для сбора мусора. Афаик, лучшее, что сейчас есть - это mostly-concurrent gc.
Вкратце, там фишка в том, что для minor gc cycle юзертреды не стопятся. В major gc cycle юзертреды стопятся только в двух критичных этапах, остальное время сборка происходит в concurrent режиме. Более того, этому GC можно задать параметр, мол в major cycle старайся не делать паузы чаще чем столько-то, не делать их дольше чем столько-то. Оно тогда, пока хватает памяти, не будет вылезать за эти ограничения.
Однако, очевидно, если его зажать слишком сильно, то оно перестанет справляться со сборкой мусора. И когда память кончится, будет запущен честный major gc cycle с долгой остановкой всех тредов и игнорированием заданных временных рамок.
Соответственно, если вы наступили на такие грабли - то надо идти профайлить код, смотреть что за объекты у вас создаются при обработке запроса. Большая вероятность того, что вы сможете очень существенно ограничить создание новых объектов, по максимуму используя примитивные типы на стеке, мьютабл объекты, отказываясь от джава коллекшенов, итд - короче, юзать все то, что не триггерит создания множества новых объектов.
Если и это не помогает - то тут уже пора придумывать distributed схему с каким-нибудь round robin'ом, чтобы живые запросы шли гарантированно на jvm с достаточным кол-вом памяти, а в бекграунде принудительно пускать gc.
Но это уже ювелирная работа. Возможно проще и наверняка надежнее будет тупо переписать все на какой-нибудь си.
ибо человечество пока не придумало полностью concurrent алгоритм для сборки мусораА что ты думаешь про http://www.azulsystems.com/zing/pgc? Нам мужик читал лекцию по их технологиям, очень интересная идея и вроде бы даже технически возможная.
Ты знаешь, я не в теме. Надо почитать пейпер на досуге, спасибо за ссылку.
Так если с ходу, то подозреваю, что магии там нету, и они просто затрейдоффили предсказуемость засчет увеличения гарантируемого респонс тайма.
Еще мне на самом деле очень интересно, что они там в G1 натворили - никак не наткнусь на какой-нибудь вменяемый пейпер. Может ты знаешь?
//add
Так если с ходу, то подозреваю, что магии там нету, и они просто затрейдоффили предсказуемость засчет увеличения гарантируемого респонс тайма.
Еще мне на самом деле очень интересно, что они там в G1 натворили - никак не наткнусь на какой-нибудь вменяемый пейпер. Может ты знаешь?
//add
Судя по этому, их гарантии начинаются от 40мс, что в общем-то довольно много.
predictable and consistent response times (averages ~1.5 ms, 40 ms peaks)
Судя по этому, их гарантии начинаются от 40мс, что в общем-то довольно много.Фишка в том, что у них эти гарантии вообще есть. Стандартный JVM может легко встрять в relocation на минуту, а у них такого 100% не будет, потому что они вообще не делают stop the world.
Ява — достаточно дорогой в эксплуатации язык, дороже только будет C# какой-нибудь. Это видно хотя бы из требований явы к ресурсам, нужны дорогие мощные сервера.Ява намного дешевле пых-пыха. Ява вообще самый оптимизированный из интерпретируемых.
Ни одна CMS никогда не даст полного спектра необходимой для самостоятельного сайта функциональности. Соответственно возникает вопрос о дописывании CMS и модулей для неё. В таком случае понятен выбор явы для тех, кто сам пишет на яве.
Высоконагруженные сайты можно писать на компилируемых языках, и там даже есть подходящие библиотеки. Только на них оказывается удобнее писать старомодные сайты, которые странички, а не веб приложения. Сначала я думал, что это от убогости библиотек для компилируемых языков, а потом понял, что убогость эта продиктована практичностью: как правило к компилируемым языкам обращаются в ситуациях острой нехватки ресурсов, соответственно и библиотеки требуются легковесные.
Угу, я понял. Видишь, у инкрементального цмса мягкие гарантии же тоже есть. То есть потенциально вполне можно получить ситуацию без долгих пауз, зажавшись посильнее чем 40 мс и в итоге де-факто переплюнув pgc.
Еще надо смотреть какой у этого pgc дьюти сайкл - одно только среднее время плохой показатель.
В общем надо смотреть-гонять, так это все конечно гадания на кофейной гуще.
Единственное, что мне не нравится, это то, что товарищи по ссылке имеют наглость завялять в названии "pauseless". Нехорошо с их стороны в контексте нашего обсуждения ;-)
Еще можно призвать в тред botWi, и попросить его поделиться экспириенсом. Если я правильно помню, ему в свое время нужно было <10мс. Правда, их проект в итоге решили перевести на си.
Еще надо смотреть какой у этого pgc дьюти сайкл - одно только среднее время плохой показатель.
В общем надо смотреть-гонять, так это все конечно гадания на кофейной гуще.
Единственное, что мне не нравится, это то, что товарищи по ссылке имеют наглость завялять в названии "pauseless". Нехорошо с их стороны в контексте нашего обсуждения ;-)
Еще можно призвать в тред botWi, и попросить его поделиться экспириенсом. Если я правильно помню, ему в свое время нужно было <10мс. Правда, их проект в итоге решили перевести на си.
Судя по этому, их гарантии начинаются от 40мс, что в общем-то довольно много.Я несколько не понял, а на каких таких операционках он запускается, чтобы они риалтайм гарантировали? Винда, линукс, бсд и солярис такого не умеют.
Дело в том, что при сегодняшних частотах и технологиях, нужда в той реалтаймовости, о которой говоришь ты, возникает на интервалах совсем других порядков (наносекунды).
Ну то есть ситуация, когда проц в перываниях будет думать 40мс, мягко говоря, маловероятна. Поэтому на интервалах типа милисекунды, можно пренебречь интерраптами, и говорить о "реалтаймовости", даже если у нас не true real-time os.
Ну то есть ситуация, когда проц в перываниях будет думать 40мс, мягко говоря, маловероятна. Поэтому на интервалах типа милисекунды, можно пренебречь интерраптами, и говорить о "реалтаймовости", даже если у нас не true real-time os.
могу прокомментировать, что афаик это не совсем так
я слышал от Ната Прайса, кажется, что его эксперименты по low latency java утыкались в производительность скедулера из ядра линукса, а не в гц джавы
я слышал от Ната Прайса, кажется, что его эксперименты по low latency java утыкались в производительность скедулера из ядра линукса, а не в гц джавы
gwt же
мона и просто на сервлетах
мона и просто на сервлетах
пока видны только слова, где написанный тобой быстрый, отказоустойчивый, надёжный и прочая и прочая форум на C?А почему на С? На интерпретируемом языке проще.
Ява намного дешевле пых-пыха. Ява вообще самый оптимизированный из интерпретируемых.Ну ерунду же говоришь. Просто вообще не в теме цен на железо?
Ты вот хоть понимаешь, что с явой даже шареные хостинги не делают? Это о чём говорит?
ПХП самый дешевый язык программирования по совокупной стоимости. Это подтверждает практика.
Только на них оказывается удобнее писать старомодные сайты, которые странички, а не веб приложения. Сначала я думал, что это от убогости библиотек для компилируемых языков, а потом понял, что убогость эта продиктована практичностью: как правило к компилируемым языкам обращаются в ситуациях острой нехватки ресурсов, соответственно и библиотеки требуются легковесные.диагноз, дальше можно не продолжать.
Наверное в зависимости от сложности логики приложения, всёже.
Оставить комментарий
Werdna
А откуда желание именно явы?CMS в большинстве случаев используются для быстрого и недорогого создания типичных сайтов. Сайты со средним и большим бюджетом делаются уже не на основе каких-то CMS, и поэтому пишутся с нуля.
Ява — достаточно дорогой в эксплуатации язык, дороже только будет C# какой-нибудь. Это видно хотя бы из требований явы к ресурсам, нужны дорогие мощные сервера. При таких тратах уже как-то нецелесообразно использовать какие-либо CMS.