А про GIL никто и не упомянул…

ZZZ
А про GIL никто и не упомянул…

А что именно следовало упомянуть?

А то, что нет смысла в таком количестве потоков.

Вот утверждение:

pasaranax
рекомендуют устанавливать количество потоков равным количеству ядер + 1

Для питона оно бессмысленно. Ибо GIL режет реальную многопоточность на корню. Тут надо процессы использовать.

Но тут есть ещё ожидание ввода-вывода. Если представить, что скорость обработки запроса гууглом стремится к бесконечности, то узким местом является канал связи. ИМХО, максимальную производительность можно достичь, если максимально загрузить канал. Т.е. не создавать новых потоков, пока некуда будет впихнуть новый запрос. Не знаю, как правильнее объяснить.

Хорошим решением было бы создать пулл нитей и подобрать количество нитей в нём.

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

P.S. И никакого time.sleep! Оно-то зачем??? Надо же получить максимальную производительность, а не “заставить работать”.

Добавленно:

Skyler
После запуска очереди потоков, первые задачи выполняются быстро, но вот последние несколько идут оооочень медленно.

Собственно, это похоже на ожидание отправки/получения пакетов через сеть.

ZZZ
Если представить, что скорость обработки запроса гууглом стремится к бесконечности,

хм… к нулю?

Ну по сравнению с latency сети.
Но могу и ошибаться.

ZZZ
Хм, но ведь кол-во потоков под 100 дает реально быструю производительность, задания выполняются быстро, исключая последние несколько. А в 3 потока вообще о производительности говорить нельзя.

Собственно, это похоже на ожидание отправки/получения пакетов через сеть.

Вот про это можно поподробней? Т.е. как бы перегружая канал выполнением большого кол-ва задач за короткое время, канал начинает “тупить”? А если применять задержки, не загружая его сильно?

Для начала запусти task manager и посмотри график загрузки процессора, сети. Скорее всего при работе через прокси под 100% они загружены не будут даже при 100 потоках. Скорее всего где-то ошибка или еще чего. В питоне я пока не особо силен - точно не скажу. Но на делфи моя программа работает в 250-300 потоков без проблем и, разумеется, выполняет свои задачи в минимум в раз 50 быстрее, чем если бы работала в 2-3 потока.

DHT
Но на делфи моя программа работает в 250-300 потоков без проблем

Вот именно это мне и надо :)

Сеть вообще практически не загружается. Идет только резкий скачок на первых секундах, и максимум, который я увидел на 2 сек - 267 кбит. В остальное время не больше 100кбит, а канал у меня на 800.

Процессор грузится всегда на ~50%(видно юзается только 1 процессор), и показывает потоков у проги - заданное_мною+2.
Мне кажется, что что-то с сетью. Типа какой-то блокировки временной или т.п.

И еще кое-что: в Мониторе Ресурсов отображаются текущие TCP-соединения. Так вот у некоторых из соединений программы появляются задержки в 300+ мс. Может ли это быть из-за тех прокси, которые находятся в другой стране, через которые я и открываю страницу?

Skyler
Процессор грузится всегда на ~50%

наверное в этом и проблема. а sleep не помог?

p.s. Я для чего sleep предлагаю попробовать, т.к., например, в делфи sleep служит также командой на то, что можно переключиться на следующий поток. А в программе моджет быть узкое место, в которое могут долбиться все потоки одновременно ожидая какого-либо дейтсвия и если говоря по просто между этим долблением не будет перерыва в потоке (sleep), то проц будет грузится под завязку даже при меньшем кол-ве потоков.

DHT
проц будет грузится под завязку даже при меньшем кол-ве потоков.

Ага, есть такое. При 2 потоках даже 50% :(
Sleep вставил сюда:
Но после этого вообще прога не пашет.