>>Я вот в свое время задался таким вопросом - результаты неутешительны, больше 80 потоков просто не имеет смысла ставить, прироста практически нет…

есть, 200 потоков практически не грузят сервак. можно параллельно копии запускать, они уже лучше нагружают, но синхронизировать копии неудобно.

o7412369815963
В некоторых задачах и 80 много, например математические вычисления на 1-м потоке будут быстрее отрабатывать чем на 80-и

Согласен. Я говорил о сетевых client-side приложениях.

Игнат
есть, 200 потоков практически не грузят сервак. можно параллельно копии запускать, они уже лучше нагружают, но синхронизировать копии неудобно.

Используйте Stackless и запускайте мириады потоков….

Практика показывает что количество потоков далеко не всегда играет решающую роль.
Дайте конкретную задачу, которую вы решаете, в данный момент - это гадание на кофейной гуще.

P.S. Вместо 60 потоков можно запустить 600 копий Python, они нагрузят сервак сильнее… Да и что за цель такая - загрузить сервак О_о

Можно при желании запустить и несколько тысяч потоков, если уменьшить каждому размер стека:
Только это напоминает историю из мультфильма “Жадный богач” про 7 шапок.

Игнат, вы так и не ответили. Зачем 200 потоков? Зачем?
Какую задачу они решают?

Каждый поток работает с сетью посредством urllib
Накапливает информацию, хранит, отправляет.

1 поток - один работающий объект. Иного не дано.
Соответственно, увеличение числа потоков - увеличивает производительность.

а к чему именно это приводит, можно попроще? потоку выделяется меньше памяти? не чревато ли это вылетом потока при нехватке этой самой памяти?

я к сожалению не знаком со stackless
если вы знакомы, ответьте пожалуйста на вопрос - сильно ли код микропотоков стеклесс отличается от потоков Concurrent?
и что мне даст переход на него?

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

> 1 поток - один работающий объект. Иного не дано
Ты не прав :-). (В смысле, если речь строго про системные потоки.)

..bw

Игнат
1 поток - один работающий объект. Иного не дано.
Соответственно, увеличение числа потоков - увеличивает производительность.

Это редкостный бред. Охрененная логика. Я не буду вдаваться в объяснения механизма, сударь отличается редкостным умом и сообразительностью, умом и сообразительностью…
Вам еще раз надо пересмотреть архитектуру. Сделать пул потоков и очередь задач. А не по потоку на задачу. При этом Вы минимизируете количество потоков до 1-2 на физическое ядро.

возьми pycurl и потыкай в его асинхронный интерфейс

Игнат
Судя по описанию вашей задачи узким местом будет не кол-во потоков, а система ввода/вывода (в данном случае: сеть и дисковая подсистема).
Не мешало бы сделать несколько тестов и определить оптимальное число потоков.
Без параметров сервера/кластера, где все это крутится мы может только пальцем в небо тыкать на предмет оптимального кол-ва потоков.

ЗЫ
И не забывайте, что переключение между потоками тоже отнимает процессорное время.

ЗЫ2
При проблемах с сетью можете поиметь огроменное кол-во зависших потоков. По крайней мере, в пределах таймаута.
Потому все таки рекомендую послушать советы в этой ветке, не смотря на тон, каким они были высказаны.
В любом случае, вы от этого только выиграете.

я когда то писал парсер и брутер для форумов, по потокам могу сказать следующие: тестировал на разных компьютерах и интернетах форум www.vbulletin.com/forum/forum.php -парсинг за минимальное время был при 15 потоках, брут при 5. Больше 50-ти потоков становились вообще не управляемые, больше 100 -зависал скрипт (в убунте и виндовсе)