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 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.