Я так думаю, что при многопоточном программировании блокирующие функции эффективнее, да и логика программы проще. А смысла вызывать не блокирующие функции вообще не вижу (я сейчас не о яве, а вообще).
Если ты можешь себе позволить на отдачу статического файла 4000 тредов, то действительно, блокирующие вызовы не так уж и страшны
Если вдруг ты не в курсе, то на каждый тред в jdk 8 запущеной на linux/x86_64 по умолчанию тратится мегабайт стека, т.е. 4 гигабайта памяти были потрачены даже без создания хотя бы одного объекта.
И люди потом говорят что джава много памяти жрет.
Для одного файла это эквивалентно к тому, что оно из памяти отдает, никакого ввода-вывода фактически и не будет, такие тесты не нужны, как и те кто их пишут.
Если вдруг ты не в курсе, то на каждый тред в jdk 8 запущеной на linux/x86_64 по умолчанию тратится мегабайт стека, т.е. 4 гигабайта памяти были потрачены даже без создания хотя бы одного объекта.
Память выделяется постранично. Даже если джава попросила мегабайт на стек, физическая память выделится только по мере её использования. Если стек небольшой (а у джавы на стеке обычно толком ничего и нет), то никакого мегабайта не будет потрачено.
Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Creator of http://computoser.com . Worked on Ericsson projects, Bulgarian e-government projects, large scale recruitment platforms, cloud navigation synchornization. Member of the jury of the International Olympiad in Linguistics and the Program committee of the North American Computational Linguistics Olympiad.
Чтоб злобный OOM-killer не пришел и не убил кого не надо)
Для этого надо программы настраивать нормально. В любой серверной программе выставляются лимиты на использование памяти. Грубо говоря у тебя на сервере 16 гигабайтов памяти — жаве ставишь 6 гигов, постгресу ставишь 4 гига на всякую муть и 6 гигов остаётся на файловые кеши. И никакой оом киллер не придёт никогда.
ты видел реальные стектрейсы из реальных проектов? твое предположение разбивается о суровую практику фреймворков, которые делают обертку над оберткой и обертками погоняют.
Ну вложенность больше 100 я не видел, например. Если каждый фрейм это 128 байтов, то вложенность в 100 уровней это 12.8 килобайтов. Совсем не мегабайт. Это раз.
Стектрейс из реальных проектов обычно в нескольких основных потоках работает. А тысячи других потоков скорее всего будут очень простыми с 1-3 уровнями вложенности. Это два.
Худей, тот чел может и не троль, возможно он просто не специалист или клинический рукожоп, хотя я в этом сомневаюсь. Но ты то сюда точно за едой пришёл, так что худей.
Ну, конечно, известный многим разработчик написал бенч, который задел джавского кодерка, который не может признать, что время его поделия ушло. Ты же, конечно же, бэтмэн с лора лучше напишешь. Уж в этом мало кто сомневается.
Serge Bureau replied on Sat, 2015/04/18 - 9:24am
Is it intended as a joke ?
Non blocking provides no benefit for single file call, it is when you have many that it does.
Your benchmark is meaningless, so please do not reach conclusion from it ???
Я не собираюсь ничего писать, т.к. в этом нет смысла.
Но поскольку аудитория сайта включает не только тролей и людей опытных, то я немного посчитаю: 120000/30=4000 внезапно число потоков на сервере, т.е. отдавай сервак по запросу на поток в секунду - всё замечательно. А теперь зайди на лоре в любую тему на несколько страниц, включи инспектор, кликни показать удалённые и посмотри как те же 40кб только не поднятые из файлика а динамически сформированные прилетают за 500-900мс (поскольку и 20 и 30 кб прилетают за то же время то очевидно дело не скорости рендеринга в хтмл).
Поскольку чел явно не в курсе что такое NIO, на что ему прозрачно намекнули, то я говорил исключительно о результатах которые он для IO получил.
ПС: мне как-то не приходилось иметь дело с нагрузкой для статики (для этого перед томкатом обычно ставят апачи и т.п.), но по прикидке на 4к потоках 120к запросов суммарно можно отработать секунд за 20, если конечно не поднимать более 10к-15к запросов/сек.
Яб тебе всётаки посоветовал-бы, перед тем как нести херню - почитай пж, что же такое оверкоммит и для чего он нужен.
Давай я тебе расскажу - оверкоммит никак не влияет на устройство связывания памяти - раз. Оверкоммит никакой жопой по умолчанию не «включен» - два. Оверкоммит никак не связан вообще с вашим о нём представлениями.
Нахрен ты уличаешь в чем-то пацана, если нихрена в теме не понимаешь?
Каждый раз, когда на ЛОРе (написанном на Джаве, ну да ладно) пытаются закопать Джаву, я смотрю, какие языки популярны в таких компаниях, как Amazon, Google, LinkedIn, Expedia и других, не говоря о финансовом секторе типа Дойче Банка, Bloomberg, Wells Fargo, ритейла типа Target, Walmart (WalmartLabs которых вообще на Clojure пишет). Конечно, Джава там не 100%, а 50-60%, и это правильно. Но про закапывание речи не идёт вообще. Есть конечно Facebook, Twitter, Instagram, где совсем не Джава, но и не Node.js
А к чему спор-то? Не нравится Джава? Ну не пиши. У Джавы есть недостатки, но с объективной точки зрения это точно не скорость её работы.
Именно. Я сейчас работаю в Новой Зеландии в крупной международной компании - тут полностью джава. Через дорогу у нас какая-то другая крупная компания - у них тоже джава. До этого работал в Citi Group - тоже джава. Маржинальная торговля, трейдинговые системы - джава.
Да, джава не идеальна, но она прекрасно справляется со своими задачами.
Только twitter все-таки много чего на джаве пишет, да и фэйсбук тоже пишет опенсурс всякий на джаве. Ту же кассандру они написали.
Я же и не спорю, что джава плоха во всех отношениях, у нее есть своя ниша, но я это все к тому, что пора прекращать ее везде пихать, когда есть более годные и новые инструменты.
Так всегда надо использовать правильные инструменты, и необязательно новые. Пока Джава вполне справляется с тем, где её используют перечисленные мной компании. Мир Джавы меняется весьма быстро и появляется много интересных технологий, Spring Boot, Hazelcast, Apache Storm, да много их.