Доброго времени суток.

Задача такая, многопоточная закачка файлов из интернета (один пото - один файл). Так вот собственно интересует как можно проверить максимальное кол-во потоков (соединений), которое можно установить не в ущерб производительности?

Понятие "ущерб производительности" весьма размыто. 

Максимально допустимое число открытых соединений зависит от настроек ОС.

Было время, писал я всякие парсеры на Java.  Обычно делал 300-600 потоков в зависимости от характеристик сервера. 

п.с. если выкачиваете текст, имейте ввиду, что stringBuilder рулит  ( избегайте использование "+" в потоках при получении текстовых данных с сокета )

Это сообщение отредактировал(а) Vasay - 21.6.2012, 01:33

Vasay, 


Спасибо. Под понятием "ущерб производительности" я имел ввиду тот придел до которго увеличение потоков будет приводить к увеличению скорости работы парсера. Т.е. как я понял все упирается в настройки ОС и ширину канала?

И в то, что Вы делаете внутри потока. Я не просто так написал про "+" и stringBuilder   

Теперь все ясно. Спасибо за помощь!

П.С. А пример парсера случайно не сохранился?   


Это сообщение отредактировал(а) CSharpProgrammer - 21.6.2012, 01:57

Выложить исходники я не могу, но готов ответить на конкретные вопросы. 

Основной вопрос это как организована работа потоков в таком приложении (т.е. как правильно организовать). К примеру на входе 100К ссылок. В данный момент у меня реализована следующая архитектура



И каждый поток берет у Producer свою порцию данных.

Так правильно? И какие варианты еще есть?

Когда я начинал писать парсерный движок, ThreadPoolExecutor вроде еще не было (или я просто о нем знал на тот момент  ). 

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

Потоки за новыми данными обращались к synchronized методу. 

Сохранение данных шло разными путями, в зависимости от того, чего хотел добиться.  В самом нагруженном случае, каждый поток обрабатывал данные,  и результат обработки сохранялся (дописывал) в файл через synchronized метод использовавший единый для всех потоков BufferedWriter. Формат файла был предназначен для быстрой загрузки в базу с помощью LOAD DATA INFILE - это был самый быстрый способ загрузить данные в MySQL с построением индексов (нужен был быстрый поиск по текстовым полям в таблицах со 100мл записей).

Не уверен что это оптимальный вариант (тем более на сегодняшний день) Но это работало и работало быстро. 100 мегабитный канал сервера забивал. 



Это сообщение отредактировал(а) Vasay - 21.6.2012, 03:40

Vasay, 

Спасибо за развернутый ответ. Тему можно закрывать.

Вообще, чтобы не завалить ОС,нужно использовать пул потоков. Сегодня защитил диплом на эту тему!!! 
Вот отличная статья: http://www.ibm.com/developerworks/ru/library/j-jtp0730/