Проблема с отправкой запросов POST с использованием запросов библиотеки

import requests
while True: 
    try:
        posting = requests.post(url,json = data,headers,timeout = 3.05)
    except requests.exceptions.ConnectionError as e: 
        continue
    # If a read_timeout error occurs, start from the beginning of the loop
    except requests.exceptions.ReadTimeout as e:  
        continue

ссылка на дополнительный код: несколько случайных запросов POST в Python Этот код использует библиотеку requests для бесконечного выполнения запросов POST. Я заметил, что когда попытка несколько раз терпит неудачу и цикл while запускается несколько раз, когда я, наконец, могу отправить запрос на публикацию, я обнаруживаю несколько записей со стороны сервера в одну и ту же секунду. Я одновременно писал в текстовый файл, и он показал только одну запись. Каждая запись составляет 5 чтений. Это проблема с самой библиотекой? Есть ли способ это исправить?! Какие бы условия я ни ставил, все равно не работает :/ ! Вы можете заметить, что чтение в 12:11:13 имеет 6 параметров в секунду, а в 12:14: 30 (после задержки должно быть каждые 10 секунд) это несколько записей в одну и ту же секунду!!! 3 записи, которые составляют 18 показаний за одну секунду, а не только 6!


python python-requests try-except
person Ahmed Al-haddad    schedule 07.07.2015    source источник
comment
Какова ожидаемая функциональность здесь?   -  person Sait    schedule 07.07.2015
comment
Предполагается, что код должен отправить запрос GET, а затем отправить его и повторить. Иногда из-за проблем с сетью запросы POST несколько раз терпят неудачу, поэтому я повторяю 2 раза, если они отправлены, или GET, и снова пытаюсь выполнить POST. Иногда при попытке POST, но терпит неудачу, после нескольких попыток он, наконец, POST, но разрывает набор записей вместо одной записи. Как показано на рисунке. На картинке показана серверная часть.   -  person Ahmed Al-haddad    schedule 07.07.2015
comment
Я думаю, нам нужно больше кода. Также, пожалуйста, исправьте отступы — они важны в Python! Наконец, не могли бы вы еще раз взглянуть на аргументы в вашем методе .post? Они довольно запутались.   -  person justinpawela    schedule 07.07.2015
comment
@user2194039 user2194039 Я немного поработаю над кодом, но что не так с моим .postметодом? Не могли бы вы показать мне, где ошибка с отступом? Код работает, за исключением того, что он дает мне неправильный результат.   -  person Ahmed Al-haddad    schedule 07.07.2015
comment
Я предполагаю, что все после while True: должно иметь отступ еще на один уровень. А в Python у вас должны быть все аргументы, не являющиеся ключевыми словами (например, url и headers), перед аргументами ключевых слов (например, json = data и timeout = 3.05). Но я действительно предполагаю, что вы имели в виду .post(url, data=json, headers=headers, timeout=3.05). В любом случае ваш код точно не будет работать так, как написано в вопросе.   -  person justinpawela    schedule 07.07.2015
comment
@user2194039 user2194039 Я только что попробовал data = json, но ничего не вышло. Я полагаю, что это похоже на то, чтобы закодировать его перед отправкой.   -  person Ahmed Al-haddad    schedule 07.07.2015
comment
Нет, придерживайтесь json=data, я просто перевернул его.   -  person justinpawela    schedule 07.07.2015
comment
Давайте продолжим обсуждение в чате.   -  person Ahmed Al-haddad    schedule 07.07.2015

Ответы (1)


arrow_upward
2
arrow_downward

Похоже, что сервер получает ваши запросы и действует на них, но не отвечает вовремя (3 секунды — это довольно низкий тайм-аут, операция скачка нагрузки / пейджинга может легко заставить сервер пропустить ее, если он не применяет специальные меры). я бы предложил

  • обрабатывать запросы асинхронно (например, порождать потоки; асинхронные запросы с запросами Python обсуждают способы сделать это с requests) и не использовать тайм-ауты (у TCP есть свои тайм-ауты, вместо этого пусть он выходит из строя).
  • повторно используйте соединение (я) (TCP имеет довольно много накладных расходов для соединения установление/нарушение) или вместо этого используйте UDP.
  • включите некоторые «подсказки» (идентификаторы, временные метки и т. д.), чтобы сервер не добавлял повторяющиеся записи. (Я бы назвал это обходным путем, поскольку реальная проблема заключается в том, что вы не уверены, был ли обработан ваш запрос.)

Со стороны сервера вы можете:

  • Ответьте как можно скорее и действуйте позже. Не позволяйте ожидающим действиям мешать ответам на дальнейшие запросы.
person ivan_pozdeev    schedule 07.07.2015
comment
Большое спасибо за ваш развернутый ответ. Я вчера воспользовался вашим советом по удалению тайм-аута и на удивление у меня осталась та же проблема, но в меньшем масштабе (всего две записи за один раз). Однако похоже, что эта проблема возникает только тогда, когда из моих наблюдений есть исключение readtimeout. Я все еще собираюсь использовать и тестировать асинхронные запросы в ближайшее время, но подумал о том, чтобы сообщить вам и посмотреть, есть ли у вас какой-либо вклад в отношении этого обновления. - person Ahmed Al-haddad; 08.07.2015
comment
1) Удалив timeout, вы только перестали мешать усилиям TCP по доставке (таким образом, естественно, улучшилась доставка). Ничто не застрахует вас от того, что сервер не ответит в течение любого периода времени, только вам решать, как долго пытаться, прежде чем в конечном итоге сдаться. 1.1) Если у вас есть доступ к серверу, вы можете диагностировать проблему с его стороны, чтобы узнать, почему так долго. 2) Две записи одновременно (а не одна) могут быть вызваны тем, что вы не используете асинхронный ввод-вывод: если ввод-вывод занимает достаточно много времени, ваша программа, возможно, пропустила время для следующей отправки и сразу перешла к следующему. один. - person ivan_pozdeev; 08.07.2015
comment
Я изучил асинхронные запросы и теперь понял, что вы имеете в виду. Я обнаружил, что проблема возникает в основном при ошибке тайм-аута чтения. В большинстве случаев он отправит POST-запрос, но ответа от сервера не будет, поэтому я отправлю его еще раз, а первый уже был отправлен. Это приводит к двум записям, когда сервер, наконец, отвечает, или больше, в зависимости от того, сколько раз я повторно отправляю запрос в течение одного и того же проблемного периода тайм-аута. Означает ли это, что использование keep-alive для повторного использования означает, что мне нужно создать сеанс как для GET, так и для POST, чтобы поддерживать одно и то же соединение? - person Ahmed Al-haddad; 09.07.2015
comment
По сути, я пытаюсь свести к минимуму количество записей, поскольку, похоже, у меня нет власти над сбоем сети и т. Д., Независимо от потерянных данных. Но так как тайм-аут чтения вызывает это, может быть, я могу что-то сделать? Разве использование keep-alive/Session() по-прежнему не разрешает несколько записей в одном и том же соединении?! Или есть способ проверить, установлено ли соединение без таймаута чтения, и тогда я могу отправить данные?! - person Ahmed Al-haddad; 09.07.2015