Здравствуйте, alex_public, Вы писали:

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




_>Ну если говорить про Node.js, то его однопоточность является вовсе не следствием приверженности асинхронного ввода-вывода, а скорее следствием принципиальной однопоточностью JS-движка V8 — там как бы изначально особо выбора не было. Хотя в итоге библиотечка libuv (второй основной компонент node.js, помимо v8, как раз отвечающий за асинхронный вывод-вывод) получилась очень не плохая и используется во многих других проектах.

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

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

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

Еще вариант — вебсокеты, вот там действительно можно получить вагон одновременных соединений, но эти вещи как раз в любом фреймворке организованы как event loop и там это действительно имеет смысл.

_>Удобство конечно же лучше у синхронного кода. Хотя использование сопрограмм (aync/await и т.п., если они доступны в языке) приводит внешний вид асинхронного кода к подобию синхронного (хотя внутри там на самом деле происходят довольно сложные процессы, но про них необязательно знать начинающим).

Не такие уж и сложные на необходимом прикладному программисту уровне абстракции. Понимать что такое промисы и как работает event loop все равно нужно.

Здравствуйте, alex_public, Вы писали:

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




_>Ну если говорить про Node.js, то его однопоточность является вовсе не следствием приверженности асинхронного ввода-вывода, а скорее следствием принципиальной однопоточностью JS-движка V8 — там как бы изначально особо выбора не было. Хотя в итоге библиотечка libuv (второй основной компонент node.js, помимо v8, как раз отвечающий за асинхронный вывод-вывод) получилась очень не плохая и используется во многих других проектах.

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

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

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

Еще вариант — вебсокеты, вот там действительно можно получить вагон одновременных соединений, но эти вещи как раз в любом фреймворке организованы как event loop и там это действительно имеет смысл.

_>Удобство конечно же лучше у синхронного кода. Хотя использование сопрограмм (aync/await и т.п., если они доступны в языке) приводит внешний вид асинхронного кода к подобию синхронного (хотя внутри там на самом деле происходят довольно сложные процессы, но про них необязательно знать начинающим).

Не такие уж и сложные на необходимом прикладному программисту уровне абстракции. Понимать что такое промисы и как работает event loop все равно нужно.