Как библиотека запросов может сравниться с характеристикой PyCurl?
Я понимаю, что Requests - это оболочка python для urllib, тогда как PyCurl - это оболочка python для libcurl, которая является родной, поэтому PyCurl должен получать лучшую производительность, но не уверен, насколько.
Я не могу найти сравнительные тесты.
Я написал вам полный тест, используя тривиальное приложение Flask, поддерживаемое gUnicorn/meinheld + nginx (для производительности и HTTPS), и посмотреть, сколько времени потребуется, чтобы завершить 10 000 запросов. Тесты выполняются в AWS на пару выгруженных экземпляров c4.large, а экземпляр сервера не ограничен ЦП.
TL; Резюме DR:, если вы много работаете, используйте PyCurl, иначе используйте запросы. PyCurl заканчивает небольшие запросы 2x-3x так же быстро, как запросы, пока вы не достигли предела пропускной способности с большими запросами (около 520 Мбит или 65 МБ/с здесь) и использует от 3х до 10 раз меньше мощности ЦП. Эти цифры сравнивают случаи, когда поведение пула соединений одинаково; По умолчанию PyCurl использует пулы соединений и кеши DNS, где запросов нет, поэтому наивная реализация будет в 10 раз медленнее.
Обратите внимание, что графики с двойным логом используются только для приведенного ниже графика, из-за используемых порядков
Полные результаты приведены в ссылке, а также методология тестирования и конфигурация системы.
Предостережения:, хотя я приложил все усилия, чтобы гарантировать, что результаты собираются научным способом, они проверяют только один тип системы и одну операционную систему, а также ограниченную часть производительности и особенно параметры HTTPS.
Прежде всего requests построен поверх библиотеки urllib3, библиотеки stdlib urllib или urllib2 не используются вообще.
Нет смысла сравнивать requests с pycurl по производительности. pycurl может использовать C-код для работы, но, как и все сетевое программирование, скорость выполнения зависит в значительной степени от сети, которая отделяет ваш компьютер от целевого сервера. Более того, целевой сервер может медленно реагировать.
В конце концов, requests имеет гораздо более дружественный API для работы, и вы обнаружите, что будете более продуктивными с использованием этого более дружественного API.
Фокусировка по размеру -
На моем 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, но не так, как приложение, которое я создаю, не будет закрывать клиент и сервер.