Запросы Python против производительности PyCurl

Как библиотека запросов может сравниться с характеристикой PyCurl?

Я понимаю, что Requests - это оболочка python для urllib, тогда как PyCurl - это оболочка python для libcurl, которая является родной, поэтому PyCurl должен получать лучшую производительность, но не уверен, насколько.

Я не могу найти сравнительные тесты.

Ответы

Ответ 1

Я написал вам полный тест, используя тривиальное приложение Flask, поддерживаемое gUnicorn/meinheld + nginx (для производительности и HTTPS), и посмотреть, сколько времени потребуется, чтобы завершить 10 000 запросов. Тесты выполняются в AWS на пару выгруженных экземпляров c4.large, а экземпляр сервера не ограничен ЦП.

TL; Резюме DR:, если вы много работаете, используйте PyCurl, иначе используйте запросы. PyCurl заканчивает небольшие запросы 2x-3x так же быстро, как запросы, пока вы не достигли предела пропускной способности с большими запросами (около 520 Мбит или 65 МБ/с здесь) и использует от 3х до 10 раз меньше мощности ЦП. Эти цифры сравнивают случаи, когда поведение пула соединений одинаково; По умолчанию PyCurl использует пулы соединений и кеши DNS, где запросов нет, поэтому наивная реализация будет в 10 раз медленнее.

Комбинированные диаграммы-RPS Время процессора по размеру запроса подробно

Просто HTTP-пропускная способность Просто HTTP RPS

Обратите внимание, что графики с двойным логом используются только для приведенного ниже графика, из-за используемых порядков Пропускная способность HTTP и HTTPS HTTP и HTTPS RPS

  • pycurl занимает около 73 CPU-микросекунд, чтобы выдать запрос при повторном использовании соединения
  • требуется 526 CPU-microseconds для запроса запроса при повторном использовании соединения
  • pycurl занимает около 165 CPU-микросекунд, чтобы открыть новое соединение и выдать запрос (без повторного использования соединения) или ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
  • требует около 1078 CPU-микросекунд, чтобы открыть новое соединение и выдать запрос (без повторного использования соединения) или ~ 552 микросекунды для открытия

Полные результаты приведены в ссылке, а также методология тестирования и конфигурация системы.

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

Ответ 2

Прежде всего requests построен поверх библиотеки urllib3, библиотеки stdlib urllib или urllib2 не используются вообще.

Нет смысла сравнивать requests с pycurl по производительности. pycurl может использовать C-код для работы, но, как и все сетевое программирование, скорость выполнения зависит в значительной степени от сети, которая отделяет ваш компьютер от целевого сервера. Более того, целевой сервер может медленно реагировать.

В конце концов, requests имеет гораздо более дружественный API для работы, и вы обнаружите, что будете более продуктивными с использованием этого более дружественного API.

Ответ 3

Фокусировка по размеру -

  • На моем Mac Book Air с 8 ГБ оперативной памяти и SSD объемом 512 ГБ для 100 МБ файла, поступающего со скоростью 3 килобайта в секунду (из Интернета и Wi-Fi), получают функцию pycurl, curl и библиотеки запросов (независимо от того, из чанкинга или потоковой передачи) почти одинаковы.

  • На меньшем четырехъядерном ядре Intel Linux с 4 ГБ оперативной памяти, над локальным хостом (из Apache в том же окне), для 1GB файл, curl и pycurl в 2,5 раза быстрее, чем библиотека запросов. А для запросов chunking и streaming вместе дают 10% -ный прирост (размеры блоков выше 50000).

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