Написал простенькую програмку: одна программа конектится (создаёт сокет к другой программе), и по циклу отправляет байт за байтом, затем стролько же байт читает из сокета. Вторая программа на ServerSocket читает байт и этот же байт отправляет обратно. Всё максимально тупо.

1-я программа в цикле:

у второй программы цикл аналогичен.

Всякие там TRY{...} я опустил.

Запустил я обе программы, пропускная способность локалхоста оказалась всего-то 20бк\с(в среднем) в одну сторону. При этом ЦП грузится на полную. Получается что Ждава через 127.0.0.1 не способна передавать большие объемы. Тот же Диалоб - примерно 5-6 кб\с. Про 100 Мбит-ю сетевую карточку вообще молчу.(примерно 12Мб\с - почти в 300 раз) А если бы я ещё и обрабатывал информацию, тогда бы вообще ниже диалапа бы было....

Ну не должно же быть такого.
В чем дело?

а) Локалхост работает очень медленно, отсюда и все тормаза. Проверить на реальной сети не имею возможности.

б) Используемый мной цикл не оптимален. Как его переписать, чтобы было больше?

в) Классы Socket-ServerSocket - не оптимальны, они сами сильно тормрозят. В таком случае что использовать?

Где предел пропускной способности (ну скажем качаем файл с одного компа на другой) для программ на Java? Как "разогнать такие программы?"

как считаешь? формулу.

ты забываешь заголовки, которые передаются вместе с каждым твоим байтом , каждый по ~20 байт ..

Добавлено @ 22:27
в общем отправляй за один раз не один байт , а например 100 Кбайт, скорость значительно возрастёт.

Это сообщение отредактировал(а) v2v - 2.6.2008, 22:28

всмысле 100 мегабит в секудну(ну по сетке же большие файл просто летают) - это примерно 12 мегабайт в секунду. Если Вы про это. т.е примерно 12 000 000 байт в секунду. делим 12 000 000\ 20 000 = 600, а если учитывать поток в обе стороны (20 кб в одну сторону и 20 кб возвращается), то будет где-то 300 раз. Здесь ошибка раза в 2 - 4 погоды не делает. Всё равно очень много. 1 гиг качается по сети примерно 1 минуту. или 17 метров в секунду. через Мою Джава-программу этот гига-файл будет идти 50000 секунд = 833 минуты - 14 часов. Разница в скорости огромная.

Добавлено через 4 минуты и 24 секунды
А как сразу отправить не один байт?

ведь в Оутстринг запись идёт побайтно, то что потом многие эти байты в один пакет собираются - это другое дело. я и так байт-массив кидаю.

byte[] a....

Это сообщение отредактировал(а) Lisus - 2.6.2008, 22:34

как тебе ответить на вопрос, если ты даже не показал с какими типами данных работаешь?!

разбирайся

http://exampledepot.com/egs/java.net/WriteTextToSocket.html
http://exampledepot.com/egs/java.net/ReadFromSocket.html

Типы данных?

яж вроде код даже вылажил
os и is - это outputStream и InputStream, которые получаются из Socket.
Чтоже ещё вас интересует Уважаемый?

Отправлять по 1 байту через tcp/ip крайне неэффективно, потому что данные передаются пакетами, у каждого пакета есть хедер и т.д. Поэтому скорость надо мерить интегрально, т.е. послать весь обьем данных в одну сторону. Сокетная имплементация отправит его пакетами оптимального размера. Надо учитывать также, что поскольку и клиент и сервер на одном компьютере, то это будет медленнее, чем на разных, соединенных в локальную сеть.  

Короче: высокие гипотезы относительно java, socket, localhost и пр. сомнительны.

PS Пока сочинял, v2v уже все сказал.

Это сообщение отредактировал(а) COVD - 2.6.2008, 23:17

да я и сам понимаю, только как это сделать? ведь outputstream принимает только байты?
Т.е. мне в любом случае придётся разбивать блок данных на байты, чтобы переслать через OutputStream?

Или я не прав?

Мне кажется, вы неправильно интерпретируете результаты теста. В вашем тесте вы измеряете очевидно не скорость передачи данных вообще, а скорость передачи коротких сообщений примерно 50 символов на пакет. Максимальный же размер пакета примерно 1500 байт. Вы же отправляете свою строку и переключаетесь на прием. Сокет вынужден отослать это короткое сообщение, он не имеет возможности обьединить несколько коротких сообщений в один пакет, чтобы снизить накладные расходы. Он бы мог так делать если бы вы слали данные не переключаясь постоянно на прием-передачу. 

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

Или просто посмотреть в Диспетчере задач загрузку процессора и сети 
Уверен, что проц будет 100% (или 50% если он двуядерный), а сеть ~1%.

Пишем:



Читаем:

да проц на всю грузиться.

А сеть? Локал хост же там не отображается, т.е. на показатель не влияет.

Бонифаций
Я почему-то уверен, что DataInputStream и PrintStream - это надстройка над стримами, эти надстройки просто форматируют данные и переправляют их с помощью тех же read() write(), они просто форматируют, значит выигрыша в скорости не будет

Добавлено через 5 минут и 11 секунд
Ладно, теперь переделал клиент так, чтобы чтение и запись были ассинхронны.  В 2 потоках. Мерием скорость и получаем где-то 30кб\секунду. Но это тоже мало.

Lisus, ты видимо не понял что тебе толкуют ....

Возможно, ткните меня мордой в нужную строчку

Lisus, читай и пиши данные большими порциями 16 и более килобайт. И не читай по одному байту, читай сразу серию байт в буфер.

А кто знает, какими именно порциями читать выгоднее всего? Есть ли тут какая-то логика?