Какой самый быстрый способ проверить статус веб-страницы?

Я пытаюсь проверить статус веб-страницы с помощью Python. Я сделал таймеры для тестирования, но ничто не дает ничего лучше другого. Худшее и лучшее различаются всего на 20%. Мне действительно нужен только код ответа, а не исходный HTML. Я буду обрабатывать 3 кода ответа: 200, 403, 404.

Метод 1 принадлежит мне, но другие были найдены здесь: Проверка наличия веб-сайта вверх через Python

Метод 1. Сейчас я использую Mechanize, чтобы открыть URL-адрес с попыткой и исключением. Если это 200, он пройдет нормально, но если это 403/404, он запустит except. Это работает нормально, но не очень быстро. Средняя скорость 0.00276

Метод 2. Используя urllib, я получаю примерно то же время, что и python. Средняя скорость 0,00227. Вот код для этого, это всего лишь один лайнер.

print urllib.urlopen("http://www.stackoverflow.com").getcode()

Метод 3: я думаю, что этот метод httplib будет самым быстрым, но он проверяет только домены, он не проверяет отдельные страницы домена, поэтому в моем случае он не работал. Код для этого:

conn = httplib.HTTPConnection("www.python.org")
conn.request("HEAD", "/")
r1 = conn.getresponse()
print r1.status, r1.reason

Метод 4. В этом методе используется request.head, а его средняя скорость составляет 0,00246. Код такой:

r = requests.head("http://www.stackoverflow.com")
print r

Кто-нибудь знает более эффективный способ проверки статуса веб-страницы в python?


person User    schedule 09.01.2014    source источник
comment
Что вы имеете в виду под скоростью, так как в ней средняя скорость составляет 0,00246? Сколько времени нужно, чтобы получить страницу? Какие единицы?   -  person stephenbez    schedule 10.01.2014
comment
Почему 2 миллисекунды «не очень быстро»?   -  person yuvi    schedule 10.01.2014
comment
Какая у вас цель? любой выигрыш, который вы получите от одного метода по сравнению с другим, будет тривиальным по сравнению с сетевым временем   -  person norlesh    schedule 10.01.2014
comment
Каждый метод будет отправлять один и тот же глагол (HEAD) с использованием протокола HTTP, и поскольку он в основном подразумевает только открытие сокета и отправку HEAD / (очень мало байтов), чтобы также получить очень мало байтов, время выполнения существенно зависит от вашей сетевой задержки. Я сомневаюсь, что вы можете улучшить что-нибудь на стороне Python.   -  person Raphaël Braud    schedule 10.01.2014
comment
FWIW, вы также можете передать любой путь, который вам нравится, в запросе в # 3. Но +1 к комментарию @ RaphaelBraud.   -  person tripleee    schedule 10.01.2014
comment
Спасибо тем, кто ответил на вопрос выше. +1. Для других, которые пытаются изменить мой интерес к сетевому времени, скорость загрузки моего сервера составляет 1 ГБ / с.   -  person User    schedule 10.01.2014
comment
Скорость загрузки - это только часть уравнения. Настоящая проблема - это задержка. Даже с локальным кешем DNS и прокси-сервером HTTP вы не можете уменьшить количество циклов TCP (и эти методы могут фактически замаскировать проблемы, которые вы, вероятно, хотите обнаружить); вероятно, вы не сможете улучшить то, что у вас уже есть, до такой степени, что разница будет значительной (т.е. стоит затраченных усилий). Если вам нужно сделать это в большом масштабе, выполняйте несколько заданий параллельно. Если нет, то почему вы вообще беспокоитесь о скорости?   -  person tripleee    schedule 10.01.2014
comment
Я делаю это в масштабе 200 тыс. URL-адресов в день, но хочу увеличить в 10 раз больше. Выяснилось, что большая задержка - это на самом деле MySQL, а не запрос страницы.   -  person User    schedule 10.01.2014
comment
Что вы подразумеваете под самым быстрым, что бы вы ни использовали в основном, чтобы открыть сокет-соединение с сервером. Так что это не имеет значения только для получения ответа.   -  person Abhishek    schedule 13.01.2014


Ответы (1)


Три библиотеки, которые вы упомянули, довольно хорошо охватывают все возможные варианты. Requests.py может быть кандидатом №4.

Обратите внимание, что Mechanize оборачивает URLLib2, в то время как Requests использует URLLib3.

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

Тем не менее, если это ваша цель, то, вероятно, это лучшее направление.

person Dwight Gunning    schedule 12.01.2014