Здравствуйте, Sharov, Вы писали:
vsb>>Ну в итоге всё упирается в память. Никаких проблем обслуживать миллион соединений на хорошем сервере я не вижу, если аккуратно всё написать.
S>От операционки все же:
S>
S>... которая в свою очередь ограничена железом. Т.е. своими усилиями аккуратно не получиться. Необходимо S>совместное взаимодействие.
Дескриптор это 4-байтовое целое, физическое ограничение — миллиарды. Можно искусственно его ограничить, как это обычно делается, чтобы сошедшая с ума программа не положила всю ОС, но это всё настраивается, если такая нужда возникнет.
Здесь скорее вопрос в алгоритмах TCP-стека, достаточно ли они хороши и масштабируются на такое количество потоков. Но по идее всё должно быть нормально, Linux в хайлоаде используется не первый год.
vsb>Дескриптор это 4-байтовое целое, физическое ограничение — миллиарды. Можно искусственно его ограничить, как это обычно делается, чтобы сошедшая с ума программа не положила всю ОС, но это всё настраивается, если такая нужда возникнет.
vsb>Здесь скорее вопрос в алгоритмах TCP-стека, достаточно ли они хороши и масштабируются на такое количество потоков. Но по идее всё должно быть нормально, Linux в хайлоаде используется не первый год.
Не спорю, а какой до селе придел соединений на одну машину? Миллион все-таки крутова-то.
А на линупс я бы не смотрел, поскольку он используется по известным причинам.
А вот серверная венда интересна в этом плане. Думаю у нее планка повыше будет, но она и подороже.
Здравствуйте, Sharov, Вы писали:
S>А на линупс я бы не смотрел, поскольку он используется по известным причинам. S>А вот серверная венда интересна в этом плане. Думаю у нее планка повыше будет, но она и подороже.
ROTFL.
Здравствуйте, Ikemefula, Вы писали:
>>>Практичный это язык который хотя бы в десятке массовых. А язык который появился вчера и у него только местечковое применение это экзотика.
vsb>>node и современный JS появился совсем недавно.
I>Ну да, 15 лет это копейки.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Sharov, Вы писали:
vsb>>>Ну в итоге всё упирается в память. Никаких проблем обслуживать миллион соединений на хорошем сервере я не вижу, если аккуратно всё написать.
S>>От операционки все же:
S>>
S>>... которая в свою очередь ограничена железом. Т.е. своими усилиями аккуратно не получиться. Необходимо S>>совместное взаимодействие.
vsb>Дескриптор это 4-байтовое целое, физическое ограничение — миллиарды.
Это чушь. Путь задаётся строкой , но почему то длина пути MAX_PATH в виндовс всего 260 символов.
Пример понятен ?
С дескрипторами тоже самое — физическое ограничение это какая то константа, которая завязана на особенности ввода вывода или управления памятью еще в ДОС 4.0
>Можно искусственно его ограничить, как это обычно делается, чтобы сошедшая с ума программа не положила всю ОС, но это всё настраивается, если такая нужда возникнет.
Ну настрой MAX_PATH, а то мне мало 260 символов.
vsb>Здесь скорее вопрос в алгоритмах TCP-стека, достаточно ли они хороши и масштабируются на такое количество потоков. Но по идее всё должно быть нормально, Linux в хайлоаде используется не первый год.
Здравствуйте, vsb, Вы писали:
vsb>>>node и современный JS появился совсем недавно.
I>>Ну да, 15 лет это копейки.
vsb>node появился в 2009 году. go тоже.
node это просто фремворк. Он популярен в первую очередь потому, что основной язык это джаваскрипт, который сейчас знает почти каждый разработчик
Отсюда понятно, почему аудитория нода на порядки превышает аудиторию go
Здравствуйте, Sharov, Вы писали:
vsb>>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти. S>миллион соединений операционка не потянет...
Операционка как раз потянет. Сотни тысяч соединений на одном сервере делаются при желании.
Проблема в другом — если на миллионе соединений получать по одному пакету в минуту, то это уже окло 40 тысяч пакетов в секунду. Сетевой стек это ещё выдержит, но вот всё остальное уже загнётся совершенно точно.
Далее, минимальный размер очередей и обслуживающих структур для соединения в Линуксе — это окло 4Кб. Плюс ещё 4-8Кб транзиентных данных. Для миллиона соединений это около 4Гб и 4-8Гб транзиентных. На таких объёмах уже будут происходить вторичные эффекты из-за промахов в кэше, так как внутренние структуры сети не оптимизированы под такой абьюз.
Тем не менее, миллион соединений достижим в лабораторных условиях.
Здравствуйте, Ikemefula, Вы писали:
I>Лапшу из колбеков можно устранить многими путями I>1. промисы I>2. новый стандарт, промисы заменить на короутины и тд I>3. язык навроде Coffee или Typescript
В Питоне используют gevent и не занимаются фигнёй. Stackfull coroutines — наше фсьо.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
S>>А на линупс я бы не смотрел, поскольку он используется по известным причинам. S>>А вот серверная венда интересна в этом плане. Думаю у нее планка повыше будет, но она и подороже.
C>Ровно наоборот ситуация.
Угу, сглупил. Когда написал комментарий, тут же подумал, что не прав.
Поскольку венду в силу понятных причин для хайлода никто использовать не будет, то там на эти вещи
видимо слегка подзабили.
C>Проблема в другом — если на миллионе соединений получать по одному пакету в минуту, то это уже окло 40 тысяч пакетов в секунду. Сетевой стек это ещё выдержит, но вот всё остальное уже загнётся совершенно точно.
Все остальное это что?
C>На таких объёмах уже будут происходить вторичные эффекты из-за промахов в кэше, так как внутренние структуры сети не оптимизированы под такой абьюз.
Что понимается под внутренней структурой сети? Не очень понятна связь промахов в кэше с их неоптимизированностью.
Я не хайлоад-программист, если что, потому могу спросить странную вещь.
C>Тем не менее, миллион соединений достижим в лабораторных условиях.
Здравствуйте, Cyberax, Вы писали:
I>>Лапшу из колбеков можно устранить многими путями I>>1. промисы I>>2. новый стандарт, промисы заменить на короутины и тд I>>3. язык навроде Coffee или Typescript C>В Питоне используют gevent и не занимаются фигнёй. Stackfull coroutines — наше фсьо.
В node.js тоже есть stackfull короутины. Насколько я понял, ТС сам не знает, где ему нужен джаваскрипт, не то в браузере, не то на сервере.
Здравствуйте, Sharov, Вы писали:
C>>Проблема в другом — если на миллионе соединений получать по одному пакету в минуту, то это уже окло 40 тысяч пакетов в секунду. Сетевой стек это ещё выдержит, но вот всё остальное уже загнётся совершенно точно. S>Все остальное это что?
Обработчики, которые будут с пакетами делать что-нибудь полезное.
C>>На таких объёмах уже будут происходить вторичные эффекты из-за промахов в кэше, так как внутренние структуры сети не оптимизированы под такой абьюз. S>Что понимается под внутренней структурой сети? Не очень понятна связь промахов в кэше с их неоптимизированностью.
Под сетевые соединения в ядре выделяются объекты, которые отслеживают их состояние (sk_buff и связанные с ним). Там используются структуры, которые плохо масштабируются для больших объёмов, так что процессор будет при обращении к этим структурам вынужден постоянно прыгать по всей RAM.
C>>Тем не менее, миллион соединений достижим в лабораторных условиях. S>Сначала сделайте хотя бы в лабораторных условиях.
Делали 250k. До миллиона можно было бы довести, но не было смысла.
Здравствуйте, Cyberax, Вы писали:
C>>>На таких объёмах уже будут происходить вторичные эффекты из-за промахов в кэше, так как внутренние структуры сети не оптимизированы под такой абьюз. S>>Что понимается под внутренней структурой сети? Не очень понятна связь промахов в кэше с их неоптимизированностью. C>Под сетевые соединения в ядре выделяются объекты, которые отслеживают их состояние (sk_buff и связанные с ним). Там используются структуры, которые плохо масштабируются для больших объёмов, так что процессор будет при обращении к этим структурам вынужден постоянно прыгать по всей RAM.
Значит все-таки в ограничения или недостатки реализации ОС уперлись?
S>>Сначала сделайте хотя бы в лабораторных условиях. C>Делали 250k. До миллиона можно было бы довести, но не было смысла.
Здравствуйте, Sharov, Вы писали:
C>>Тем не менее, миллион соединений достижим в лабораторных условиях. S>Сначала сделайте хотя бы в лабораторных условиях.
Итоги эксперимента:
"Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек."
Автор приводит подробные инструкции по повторению эксперимента, так что можно все проверить самому.
Здравствуйте, Sharov, Вы писали:
C>>Под сетевые соединения в ядре выделяются объекты, которые отслеживают их состояние (sk_buff и связанные с ним). Там используются структуры, которые плохо масштабируются для больших объёмов, так что процессор будет при обращении к этим структурам вынужден постоянно прыгать по всей RAM. S>Значит все-таки в ограничения или недостатки реализации ОС уперлись?
Это скорее просто ограничения, связанные с целевым примененим. Делать миллион соединений просто не имеет никакого смысла.
S>>>Сначала сделайте хотя бы в лабораторных условиях. C>>Делали 250k. До миллиона можно было бы довести, но не было смысла. S>А где можно почитать?
Мы это для себя делали — тупо брали libuv и запускали на тестовом стенде.
