Комментарии 16
Ну если уж внесли в список php + socket, то почему нет python + urllib2?
0
Коли уж Вы тестируете по 50 запросов, может имеет смысл использовать асинхронный вариант работы? И почему Вы не рассматривали вариант с использованием stream-функций?
0
Зачем в php каждый раз создавать и уничтожать инстанс curl?
Такой вариант отработает быстрее.
$t = 'http://www.2ip.ru/'; //target
$ch = curl_init();
for($i=0; $i < 50; $i++)
{
curl_setopt($ch, CURLOPT_URL, $t);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLINFO_HEADER_OUT, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0');
curl_setopt($ch, CURLOPT_ENCODING, 'utf-8');
curl_setopt($ch, CURLOPT_TIMEOUT, 200);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
$data = curl_exec($ch);
}
curl_close($ch);
Такой вариант отработает быстрее.
0
подразумевалось что в работающей системе не будет таких циклов, а будут атомарные запросы.
Будет работать быстрее — да, Вы правы. Но не быстрее чес с сокетами.
Будет работать быстрее — да, Вы правы. Но не быстрее чес с сокетами.
0
логично, что отработает быстрее, потому что будет через одно соединение грузить и без лишних SYN и FIN на открытие и закрытие, но тут весь подход к тестам неправильный
0
То есть получается, что установление сетевого соединения с другим сервером + посылка запроса + выполнение удалённого скрипта + получение ответа, всё это выполняется в разы быстрее, чем пожирает обёртка над всем этим?
+3
Запрос идет к домену. Часть времени уходит на dns резолвинг. По умолчанию php curl кэширует dns весьма глобально (даже если курл_инит делается каждый раз), да и остальные могут себя по разному в этом плане вести. Разница может быть здесь зарыта и не проявлять себя на разных доменах, при обращении по ИП или исправляться парой настроек.
Интересно было бы увидеть аналогичный тест с обращением напрямую по IP или с заведомо включенным/отключенным днс кэшем.
Интересно было бы увидеть аналогичный тест с обращением напрямую по IP или с заведомо включенным/отключенным днс кэшем.
+1
Для реального теста такой подход не пойдёт, — вероятно что многое пойдёт из кэша после первых запросов и сложно в этом случае предсказать откуда данные пришли.
Если хотите что-то доказать — включайте сниффер и смотрите какие данные и откуда идут на самом деле и какие запросы проходят, а также сколько данных передаётся и какие промежутки времени.
Такие тесты как здесь без учёта названных параметров недостаточны для уверенного высказывания!
Если хотите что-то доказать — включайте сниффер и смотрите какие данные и откуда идут на самом деле и какие запросы проходят, а также сколько данных передаётся и какие промежутки времени.
Такие тесты как здесь без учёта названных параметров недостаточны для уверенного высказывания!
0
Сами запросы не идентичны.
0
а чем не устроил стандартный time?
"$testdir/timer1" "php $testdir/testCurl.php"
-- vs --
time "php $testdir/testCurl.php"
0
Не совсем понятно почему сокеты настолько лучше, должны быть лишь совсем чуть-чуть при корректных тестах
Разница между различными обертками curl незначительна и наверняка будет сильно меньше сетевых задержек и прочей фиги, которую придется решать через curl_multi
Разница между различными обертками curl незначительна и наверняка будет сильно меньше сетевых задержек и прочей фиги, которую придется решать через curl_multi
0
Почему не использовать сокеты на python?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Изменить настройки темы
Сравнение производительности: curl, php curl, php socket, python pycurl