LINUX.ORG.RU

[java][nio vs multithreading]что быстрее?

 


0

0
Давно не тыкался в яву, но раньше везде утверждалось, что nio-сервер будет всегда быстрее, чем многопоточный. Решил поискать, что думает интернет по этому поводу. Статей мало, тесты есть, но за 2004 год. Там утверждают, что nio сливает по 20% на линуксе с 2.6.х ядрами за счет NPTL.

Никто из здешних обывателей не мерил, что быстрее? Стоит выбор, система в дальнейшем должна будет обрабатывать очень много, вот и не знаю, что взять. Когда-то давно копался в apache mina, но может оно того и не стоит?..

★★★★★
Можно уточнить задачу? Я что-то не понимаю, как пересекаются NIO и многопоточность?
JFreeM ★★★☆
()

если писать так что на каждое соединение создается новый поток то ты сольешь даже операционке на пыхе запущеной в эмуляторе под вистой на атоме.

wfrr ★★☆
()
Ответ на: комментарий от wfrr
да ну? то-то томкат держит 10000 concurrent сессий не напрягаясь на 1G памяти? А он создает поток на каждый коннект
JFreeM ★★★☆
()
Ответ на: комментарий от JFreeM
Ты разницу между коннектом и сессией видишь?
Legioner ★★★★★
()
Ответ на: комментарий от JFreeM

да ну? то-то томкат держит 10000 concurrent сессий не напрягаясь на 1G памяти? А он создает поток на каждый коннект

Ключевое слово скорее всего 'создается'. Вполне возможно, что он держит пул потоков. Ну и то, что он гоняет не напрягаясь 10к потоков на Linux-е - как-то сомнительно.

bibi
()
Ответ на: комментарий от bibi
>Ну и то, что он гоняет не напрягаясь 10к потоков на Linux-е - как-то сомнительно.
по-моему, ты путаешь поток и процесс. Потоки джавы не видны наружу операционке.

>Ты разницу между коннектом и сессией видишь?

я вижу. Написал нарочно, чтобы было яснее. Имелись в виду именно коннекты. Сессия в плане "сессия обмена данными", не тот Session

>Вполне возможно, что он держит пул потоков

конечно, пул. По моим исследованиям выходило, что 150 потоков вполне способны обеспечить 10000 клиентов. Если респонс формируется сравнительно быстро.
JFreeM ★★★☆
()
Ответ на: комментарий от JFreeM

по-моему, ты путаешь поток и процесс. Потоки джавы не видны наружу операционке.

Ну в таком случае да, вполне возможно. Я, ммм.. мягко говоря :), не силен в жаве. Я её видел то всего пару раз. Да и то лет 10ть назад, когда она была ещё популярна.

bibi
()
Ответ на: комментарий от JFreeM

Ну так, откуда тогда непонятки? )

Features

The NIO APIs include the following features:

Buffers for data of primitive types

Character-set encoders and decoders

A pattern-matching facility based on Perl-style regular expressions

Channels, a new primitive I/O abstraction

A file interface that supports locks and memory mapping

A multiplexed, non-blocking I/O facility for writing scalable servers

http://java.sun.com/j2se/1.4.2/docs/guide/nio/

stave ★★★★★
() автор топика
В L2J путём серии экспериментов, народ пришёл однозначно к NIO. При чём с многопоточностью. Через NIO получается пакет и формируется тред для обработки этого пакета. В результате - тысячи коннектов, но не так уж много одновременно обрабатываемых тредов и во время их исполнения коннекты не держутся.
KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73
Может я давно смотрел в ту сторону, но L2J имхо не лучший пример производительности. Сколько там клиентов держится, меньше 5 тысяч? Кстати в одной из статей упоминается, что нити начинают отлично себя показывать именно на толстом канале больше 100 мбит/сек. Просто мне надо _очень много_ клиентов держать.
stave ★★★★★
() автор топика
Ответ на: комментарий от stave
>Может я давно смотрел в ту сторону, но L2J имхо не лучший пример производительности. Сколько там клиентов держится, меньше 5 тысяч?

Ну да, обычно на фришных серверах не больше нескольких тысяч человек играет.

>Просто мне надо _очень много_ клиентов держать.


Может быть тогда в сторону Эрланга посмотреть? :) Он десятки тысяч коннектов на достаточно слабом железе держит. Для этого и разрабатывался...
KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73
>народ пришёл однозначно к NIO. При чём с многопоточностью.
вот это мне и было непонятно, собственно. Как наличие NIO исключает многопоточность? Почему вопрос стоит "или ... или"?. Одним NIO в любом случае не обойтись, потоков будет много. А уж при многопоточности использовать NIO надо - оно в любом случае быстрее обычного IO. Ибо "platform dependent"
JFreeM ★★★☆
()
Ответ на: комментарий от JFreeM
>Как наличие NIO исключает многопоточность? Почему вопрос стоит "или ... или"?

Ну сокеты в NIO неблокирующие, это основное их отличие от стаффа из java.net.*

Absurd ★★★
()
Ответ на: комментарий от JFreeM
я кидал ссылку сверху. при использовании NIO нет смысла городить по 150 нитей. максимальная производительность показал вариант 1 поток * 1 ядро процессора. дальше будет ухудшение производительности. а пул нитей с блокируемыми сокетами по нити на клиента обогнал все варианты с NIO.
stave ★★★★★
() автор топика
Ответ на: комментарий от KRoN73
>Ну да, обычно на фришных серверах не больше нескольких тысяч человек играет.

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

>Может быть тогда в сторону Эрланга посмотреть? :) Он десятки тысяч коннектов на достаточно слабом железе держит. Для этого и разрабатывался...

Кстати да :) Я сам и забыл про него. Хотя интересно с явой закончить, надо тесты писать...

stave ★★★★★
() автор топика
Ответ на: комментарий от stave
Вы заставили меня задуматься. Судя по всему, я ошибался.
То количество потоков которое я называл - это количество потоков обработки реквестов. А именно количество потоков принимающих коннекшены
- 2. Дока томката говорит что

acceptorThreadCount

(int)The number of threads to be used to accept connections. Increase this value on a multi CPU machine, although you would never really need more than 2.

Получается, что ассептят коннекшены два потока и потом по потоку на каждый коннекшн для обработки.

Ага, теперь имеет смысл пройти по ссылке и посмотреть что они там намеряли.
JFreeM ★★★☆
()
Ответ на: комментарий от theos
Connector'ы afaik так и работают - на конечных автоматах.
Вобщем, я бы посоветовал NIO + количество потоков по 1 на процессор. Потому что как было сказано по ссылке выще, jvm имеет ограничение на 16к потоков, а тебе надо держать намного больше насколько я понял.
JFreeM ★★★☆
()
Ответ на: комментарий от JFreeM
>Потому что как было сказано по ссылке выще, jvm имеет ограничение на 16к потоков, а тебе надо держать намного больше насколько я понял.

Угу. Похоже придется держаться стандартов проектирования.

stave ★★★★★
() автор топика
Ответ на: комментарий от theos
>"Многопоточность для тех, кто не осилил автоматное программирование" (Цэ)

чтобы на это ответили из стана эрланга?.. ;)

stave ★★★★★
() автор топика
Ответ на: комментарий от theos
> Многопоточность для тех, кто не осилил автоматное программирование

Ололо! Больше велосипедов, хороших и разных! :D

vasily_pupkin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.