Пишу поискового бота, который запрашивает 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мс? Но видимо, здесь никто такое не тестил, буду сам разбираться сейчас.
