А если большой request body?

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

А если большой request body?

У тебя чанк на чтение из сокета не должен быть обязательно того же размера, что и http ответ / чанк, хватит по 32 байтика читать и переключать сокет для чтения

А если большой request body?

чанками будет буфера наполняться, если переливать из A -> B это все про IO, вот если пойдет бизнес логика, то в один уже поток будет тесновато пролазить.

чанками будет буфера наполняться, если переливать из A -> B это все про IO, вот если пойдет бизнес логика, то в один уже поток будет тесновато пролазить.

Ну тут речь скорее именно про треды для http, а не про треды для приложения в целом

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

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

Если есть директ буффер на io драйвер, то вообще нет проблем

у netty offheap буферы (если не ошибаюсь)

у netty offheap буферы (если не ошибаюсь)

Оффхип и директ - это немного разное, нетти умеет в директ буфферы, но на зарплату не поспорю, нужно сорцы смотреть

offheap direct ) и то и то

offheap direct ) и то и то

Ну так да)

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

aeron очень круто устроен в этом плане, у него все буфферы в shm, драйвер сам по себе нативный и через shm общается с клиентом на jvm

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

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

aeron очень круто устроен в этом плане, у него все буфферы в shm, драйвер сам по себе нативный и через shm общается с клиентом на jvm

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

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

Исключительно в сендбоксе, в прод не потащили, но может быть к этому вернемся Вообще akka artery использовали в одной компании, может @rockjam застал и может поделиться впечатлениями

не, ты что-то путаешь, мне кажется

Мне просто непонятно, какую магическую цифреку вписывать в качестве количества тредов

подбирать над, я не знаю что у тебя там за реквесты

2хCore =) классика

обычно класива cpu_count + 1

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

можешь через affinity прибить к конкретным ядрам)

можешь через affinity прибить к конкретным ядрам)

JVM же вроде не поддерживает affinity, или это можно на уровне ОС сделать?

https://github.com/OpenHFT/Java-Thread-Affinity

через jni можно все)

у них даже дока есть

https://netty.io/wiki/thread-affinity.html

Чем Скала отличается от Хаскеля? (кроме синтаксиса)

в ней есть ООП, она не ленивая

успакойся

ну и потроха JVM торчат по-всякому

в ней есть ООП, она не ленивая

ну ООП оно и в Питоне ООП, а ещё?

ну и потроха JVM торчат по-всякому

это хорошо?

это хорошо?

Да, легко в энтерпрайзе использовать. Все Java библиотеки совместимы out of the box.

разделение на хорошо и плохо - иллюзорно и субъективно

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

ну ООП оно и в Питоне ООП, а ещё?

В питоне ООП?

В питоне ООП?

__superOOP :D

В питоне ООП?

да

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

ну это мы ещё посмотрим

да

Питон - устаревший язык. Может и не умрёт, а останется для простых вещей, займёт нишу бейсика.

ну это мы ещё посмотрим

Мы - это кто? Хаскель программисты?

Мы - это кто? Хаскель программисты?

я и мой обпитоненый мозг

Питон - устаревший язык. Может и не умрёт, а останется для простых вещей, займёт нишу бейсика.

сплюнь, это руби устаревший

пятничный взрыв

Чем Скала отличается от Хаскеля? (кроме синтаксиса)

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

сплюнь, это руби устаревший

Руби, кстати, посовременее Питона будет, по-слухам. Но, говорят, в тупик зашёл и потерял комьюнити.

ну и потроха JVM торчат по-всякому

Можно даже сказать потроха джавы

Т.к. шакалка всё-таки делалась, чтобы очень хорошо интегрироваться с жавакодом

угу, спасибо за поправку, Олег

Руби, кстати, посовременее Питона будет, по-слухам. Но, говорят, в тупик зашёл и потерял комьюнити.

Ты что, бусурманин? Совсем осупостатился?

Руби, кстати, посовременее Питона будет, по-слухам. Но, говорят, в тупик зашёл и потерял комьюнити.

по слухам только

Кстати, тут про Graalvm говорили... Вроде есть планы встроить в sbt-native-packager. Будем строить нативные приложения! https://github.com/sbt/sbt-native-packager/issues/1123

https://blog.playframework.com/play-on-graal/

WOW

WOOOOW

Чем Скала отличается от Хаскеля? (кроме синтаксиса)

интересно а чем плюсы от жавы отличаются (кроме синтаксиса)

интересно а чем плюсы от жавы отличаются (кроме синтаксиса)

на плюсы агрится Торвальдс, а на жаву - Дейкстра

я даже запишу это

интересно а чем плюсы от жавы отличаются (кроме синтаксиса)

например питон от плюсов отличается тем что питон не strong type

например питон от плюсов отличается тем что питон не strong type

я думал ты там начнешь заливать интерпретируемый не интерпретируемый

Чото такое строгая типизация?

или рантаймом

ERROR: S client not available

например питон от плюсов отличается тем что питон не strong type

картинка_с_клоуном_плюс_все_её_обсуждение.жпг

Питон сильно типизированій = strong type

скалисты сильно атипизированы

Питон сильно типизированій = strong type

питон динамический

Скала тоже

оч динамично можно писать код

питон динамический

Я не говорил обратного.

например питон от плюсов отличается тем что питон не strong type

Нет, питон strongly, dynamically typed

повер программенг слышали о таком?

вот тип я могу задать переменную a = "aaa" а потом a = 4 ?

Скала тоже

.

Ты нас в питоне решил проверить или что?

мы не петонесты

мы гоферы

не тот чат Рустем

вот тип я могу задать переменную a = "aaa" а потом a = 4 ?

в скале так можно?

var a: Any = "aaa" a = 4

в скале нельзя шейдить, а в путоне можно

var a: Any = "aaa" a = 4

Стрёмно, но классно

а haskell может юзать GraalVM?

Рустем хватит набрасывать короче

а haskell может юзать GraalVM?

конечно может

спп 17й может

мы гоферы

давайте поговорим про гоф

давайте поговорим про гоф

@kotlin_lang тут ответят на все твои вопросы, я не шучу.

Котлин…

а haskell может юзать GraalVM?

можно https://eta-lang.org

ага, на реддите в комментах нашел на него ссылку

такой же вопрос кто-то задал