Java Futures vs Goroutines

Пишу поискового бота, который запрашивает URL и забирает контент по этому URL'у для дальнейшей обработки. Процессор поддерживает возможность запуска ботов в несколько потоков, но здесь возникает вопрос, что будет быстрее — java threads или green threads (или легкие потоки, как в go).

Предположим я использую HttpClient для получения контента по определенному URL'у. Думаю, есть смысл создать Future задачи и замапить их на 100-200 (цифры от балды) java threads, через тот же thread pool. Тем самым, HttpClient будет работать в java threads запрашивая и получая контент по URL'у. С учетом пингов, примерно в 100мс, на эту работу может уйти до 600мс.

Если я правильно понял, то благодаря неблокируемому IO, поток с кодом HttpClient будет засыпать как минимум на 100мс, благодаря чему эти 100-200 потоков будут шустро отрабатывать, засыпая при ожидании данных, а затем просыпаясь для их приема.

И конечно, будет отдельный поток, который в бесконечном цикле обходит Future и проверяет, какие данные приняты и отправлять их в другой поток для обработки.

Правильно ли я разобрался? Может есть смысл для этого использовать Go c routines, заместо java с threads, будет ли это быстрее? Или на java можно сделать как-то хитрее?

UPDATE
Пинги могут быть и в 1000мс, а значит нужно создавать потоков чем больше, тем лучше, т.е. чтобы каждый поток держал соединение. А если юзать тредовый пул, скажем нитей на 100, то при 3000 ботах, будет работать медленно. Т.е. после освобождения нити, новый бот её захватит и заснет на 1000мс из-за IO, а очередь будет из 30 ботов на одну нить. А так, если каждому боту поток или хотя бы 2-3 бота в очередь на поток, то будет шустрее.

Вот только вопрос, какие пределы, скажем для какого-нибудь простого Core 2 Duo процессора? Какая будет разница в производительности, если юзать легкие нити go или делать тяжелые в java? 10 000 java потоков vs 10 000 goroutines c IO в 100-1000мс? Но видимо, здесь никто такое не тестил, буду сам разбираться сейчас.
  • Вопрос задан
  • 4501 просмотр
Пригласить эксперта
Ответы на вопрос 3
@bald2b
А почему вы думаете, что треды явы настолько тяжелые? HttpClient сам по себе тяжелый наверно для задач просто скачивания :)
Я бы на вашем месте вместо извращений с go написал свой простой скачиватель контента вместо HttpClient, выхлопа будет больше. Насчет количества потоков Java — каждый поток занимает по умолчанию 2 Мб памяти при создании (можно уменьшить ключом JVM -Xss), вот и думайте сколько можно запустить
Ответ написан
Beholder
@Beholder
Самое медленное будет — сеть, а не потоки.
Ответ написан
@physics
При решении подобной задачи, я бы обратил внимание на Akka (пример на хабре habrahabr.ru/post/125717/). Каждую таску с запросом оборачивал бы в класс актера. Можно было бы и самостоятельно заморачиваться многопоточностью, но тогда следовало бы иметь ввиду необходимость пулов потоков и т.д и т.п.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы