LINUX.ORG.RU

requests не чистит свою память. Уже мартышка бьёт дисками в голове.

 ,


0

2

Попробуйте запустить программу:

from requests import request

urls = [ "1047883",
         "1044004",
         "572033",
         "839458" ]

for url in urls:
    resp = request(method='GET', url="https://www.kinopoisk.ru/film/{}/".format(url), headers={'Connection':'close'})
    with open("ololo_{}.html".format(url), 'w') as f:
        f.write(resp.text)

У вас первый файл будет нормальным, остальные три с капчей.

Окей. Теперь запустите это:

from requests import request

urls = [ "1047883",
         "1044004",
         "572033",
         "839458" ]


resp = request(method='GET', url="https://www.kinopoisk.ru/film/{}/".format(urls[int(sys.argv[1])]), headers={'Connection':'close'})
with open("ololo_{}.html".format(url), 'w') as f:
    f.write(resp.text)

Вот так:

for i in $(seq 0 3); do python3 shiza.py $i; done

Все 4 результата будут без капчи.

Ту же самую проблему я наблюдаю с некоторыми серверами выдающими JSON ответы. В первом случае все ответы имеют одинаковую структуру, во втором рандомную.

Я использовал рандомные заголовки и хорошие прокси через опсосов. И все равно пофиг, сервер видит мои запросы requests как от одной программы.

Ответ на: комментарий от pawnhearts
s = requests.session()
s.keep_alive = False

Не помогает даже при использовании многопоточности. Притом вызываю это естественно заново внутри потока, а не копирую адрес объекта, я даже специально атрибуты проверял, есть они или нет.

steemandlinux ★★★★★ ()
Последнее исправление: steemandlinux (всего исправлений: 1)

Чудеса, эта хрен пропала теперь... Похоже совпало с реакцией защиты.

Но тогда почему она проявляется при использовании прокси.

steemandlinux ★★★★★ ()
Последнее исправление: steemandlinux (всего исправлений: 1)
{'https': 'socks5://37.203.246.6:50181'}
{"ip":"94.25.168.152"}
/film/1047883/
('Однажды в Голливуде', 'Once Upon a Time in Hollywood', '2019', 'драма,комедия')
{"ip":"176.59.41.183"}
/film/1044004/
{"ip":"94.25.168.152"}
/film/572033/
{"ip":"94.25.170.249"}
/film/839458/
{"ip":"213.87.145.3"}
/film/1044280/
{"ip":"213.87.145.3"}
/film/462305/
{"ip":"91.193.177.18"}
/film/843066/
{"ip":"31.173.85.49"}
/film/688656/
{"ip":"91.193.177.18"}
/film/645065/
{"ip":"83.220.236.242"}
/film/420454/
{"ip":"31.173.85.49"}
/film/893148/

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

steemandlinux ★★★★★ ()
Ответ на: комментарий от KillTheCat

Тоже самое. У меня целый год с одной программой это творится. Разные потоки, разные прокси, в каждом потоке своя сессия. Несколько дней работает, порядок параметров JSON один и тот же приходит. Достаточно перезапустить программу, порядок меняется. Я всё что можно проверял, адрес session объекта, wireshark, mitmproxy, ничего подозрительного, на каждый HTTP OK открывается новый source port.

steemandlinux ★★★★★ ()
Последнее исправление: steemandlinux (всего исправлений: 1)
Ответ на: комментарий от steemandlinux

У меня такого ни разу не было с api, хотя я и не смотрю что там в json. А яндекс уж очень ботов не любит, может на один запрос с ип впски капчу выдать.

У вас первый файл будет нормальным, остальные три с капчей.

Запустил 5 раз, дома все ок на vps одна капча.

KillTheCat ★★★★★ ()
Ответ на: комментарий от KillTheCat

Я через прокси пускаю один и тот же код. В одном случае цикл внутри питона, другой через шелл. В первом случае, первая ссылка открывается, дальше идут капчи. Во втором спокойно ссылки открываются. Несколько раз проверял и по разному, но результат один и тот же.

Вот еще один сервис, запросы от разных потоков и сессий.

Порядок до перезапуска:

{'hash_fluctuation_wait': 5000, 'warning_start_duration': 20000, 'warning_start_attempts': 3, 'duration_foreground': 300000, 'hash_duration': 0.5, 'status': 1, 'duration_wait': 3600}
{'hash_fluctuation_wait': 5000, 'warning_start_duration': 20000, 'warning_start_attempts': 3, 'duration_foreground': 300000, 'hash_duration': 0.5, 'status': 1, 'duration_wait': 3600}

После перезапуска:

{'warning_start_duration': 20000, 'status': 1, 'warning_start_attempts': 3, 'duration_foreground': 300000, 'hash_fluctuation_wait': 5000, 'hash_duration': 0.5, 'duration_wait': 3600}
{'warning_start_duration': 20000, 'status': 1, 'warning_start_attempts': 3, 'duration_foreground': 300000, 'hash_fluctuation_wait': 5000, 'hash_duration': 0.5, 'duration_wait': 3600}

У меня уже из-за таких приколов уже обезьянка с тарелками завелась.

steemandlinux ★★★★★ ()

Попробуй на Golang тоже самое сделать и результаты в студию

NetSurf ()
Ответ на: комментарий от KillTheCat

Вот через шелл:

for i in $(seq 0 4); do python3 films.py $i; done
{"ip":"176.59.36.70"}
/film/1047883/
('Однажды в Голливуде', 'Once Upon a Time in Hollywood', '2019', 'драма,комедия')
{"ip":"176.59.36.207"}
/film/1044004/
('Ведьмак (сериал 2019 – ...)', '(сериал 2019 – ...)', '2019', 'фэнтези,боевик,драма,приключения')
{"ip":"83.220.237.245"}
/film/572033/
{"ip":"31.173.86.66"}
/film/839458/
{"ip":"94.25.170.221"}
/film/1044280/
('Стражи Галактики. Часть\xa03', 'Guardians of the Galaxy Vol.\xa03', '2020', 'фантастика,боевик,приключения')

А ровно тот же самый код:

requests не чистит свою память. Уже мартышка бьёт дисками в голове. (комментарий)

steemandlinux ★★★★★ ()
Ответ на: комментарий от KillTheCat

Он получал один порядок, а потом response отдавал другой? Ну тогда понятно, у меня python 3.5 на том сервере.

steemandlinux ★★★★★ ()
Последнее исправление: steemandlinux (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.