Soteric
из-за того, что процессор будет проводить основную часть времени на переключении между потоками

будет ли это грузить процессор?
в вышеприведенном примере пробовал ставить разные таймауты - все равно падает скорость.

Я не уверен, будет ли это отображено как нагрузка на процессоре

DHT
будет ли это грузить процессор?

Не настолько, чтобы это стало узким местом.
Узкое место у вас - сеть (не библиотека!) и обслуживание потоков Питоном.

Lexander
Узкое место у вас - сеть (не библиотека!) и обслуживание потоков Питоном.

Спасибо вам всем за помощь! Теперь хоть знаю в какую сторону копать.
Но что понимается под

Узкое место у вас - сеть

?

Подразумевается не ваш локальный сетевой интерфейс, а интернет.
Скорость получаемых данных равна наименьшей скорости на одном из участков сети между вашим сервером и удаленным.
Для части узлов из вашего списка она составляет секунды и даже десятки секунд.
Все это время Питон “присматривает” за вашими потоками.

проблема в том, что даже если создать новый поток в случае такого долгого ожидания одним из потоков, то прироста скорости нет. Да и таймауты должны были бы по идее решить эту проблему.

Таймауты никак не решают проблему низкой скорости получения данных от удаленного сервера.

> Вот этого бы совсем не хотелось. Т.к. именно для httplib2 написал уже очень много чего хорошего: куки менеджер, multipart/form-data и другое.

Попробуйте асинхронный Grab::Spider (http://grablib.org), там есть все эти плюки типа кук, форм и т.д., а работать будет быстро т.к. на базе асинхронного pycurl

lorien
Я тоже хотел было посоветовать ваш ФМ, но потом автор написал, что у него уже куча обвеса сделано под httplib2.

Впрочем, DHT, я бы хотя бы посмотрел grab на паре тестовых примеров.
Все равно вам для реальной работы нужно переписывать код, почему бы не глянуть.
А там уже решите, использовать или нет.

lorien
Хочу добавить, все таки перед использованием любой высокоуровневого ФМ, хорошо бы разобраться в основах.
Кто с индусами работал, поймет :)