Curl vs Socket (сокеты)

[KillDead]

Интересно, какие например функции он не включает?

Я скорее про то, что сокеты могут выполнить множество функций- как например чтение сообщений аськи, которые не может курл.

Я вот о том и говорю –*что это кирпичики. Что сокеты перспективней начать учить и можно без curl'а обойтись.

Хм, в таком случае лучше учить\использовать не пхп а c++. Перспективней же

Вот замеры скорости разных технологий:

• Curl: 5.39667105675
• file_get_contents: 7.99799394608
• Sockets: 2.99629592896
• MultiCurl: 0.736907958984

Встречал еще один такой тест, а также пробовал на хостинге: сURL всегда получается в 2 раза медленнее сокетов.
*** скрытое содержание ***

вово, в реальных тестах курл всегда проигрывает по скорости сокетам, иначе и быть не могло. Но всётаки разница не такая уж и большая получается в конечном счёте- ну скрипт будет парсить не 2 часа а 3-3.5, но время написания этой программы будут быстрее.

 

[saen]

Я скорее про то, что сокеты могут выполнить множество функций- как например чтение сообщений аськи, которые не может курл.


Хм, в таком случае лучше учить\использовать не пхп а c++. Перспективней же


вово, в реальных тестах курл всегда проигрывает по скорости курлу, иначе и быть не могло. Но всётаки разница не такая уж и большая получается в конечном счёте- ну скрипт будет парсить не 2 часа а 3-3.5, но время написания этой программы будут быстрее.

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

 

[KillDead]

курл всегда проигрывает по скорости курлу?
по поводу разницы по времени с тобой не соглашусь: существует ряд задач, где скорость критична и является узким местом, и каждая выигранная секунда на вес золота.

)) поправился.
Не, когда действительно требуется максимально высокая скорость - тогда действительно нужно парится насчёт скорости. Просто часто люди ударяется в крайности- "если учить юрзать прогу\класс - то только самую перспективную и быструю" недай бог она окажется на 5% медленее аналога- тогда люди проклинают её и всех её пользователей считают лохами) Ну или готовы убить за count ptint - они ведь медленнее?)) Не, конечно я не пропагандирую совсем не думать о скорости и кодидь как хочется- просто надо прикидывать, действительно выгода в несколько секунд необходима.

Вот пример: есть граббер новостей для дле. я заточил его под массовый граббинг - на вход список сайтов, на выходе новости с них. В процессе замерил скорость- оказалось оооочень медленная. Неделю пытался оптимизировать. Забил. Написал аналог не с 0 а с 30%. Это ещё неделя. Прирост скорости составил раза в 2-3.
И вот такой вопрос- тем, кто просто парсит новости 1 раз в день по штук 20-100 за 5 минут действительно хочется потратить 2 недели на кодинг и тратить 2 минуты на парсинг?

Скажи мне, ты работал с асинхронными неблокирующими сокетами?

нет, не работал. ТОлько смотрел как вообще они функционируют, но знаю, то, что обычно в идеальных условиях и в примерах написанных обычно на сайты гугл и яшу- всё классно и просто. С ними какая нибуть особенная печаль?)

 

[saen]

они работают быстрее чем мультикурл

 

[jabjab]

сокеты перспективней начать учить и можно без curl'а обойтись.

Ну так вы сразу за ассемблер садитесь, тогда можно и без php обойтись

Curl, впрочем, как и многие другие высокоуровневые библиотеки придумали в первую очередь не для новичков, мол, они не умеют, пусть будет проще, а для экономии времени. Пока вы будете изобретать велосипеды с отправкой файлов и обработку gzip-ответов с нуля на сокетах, другой человек сделает это за 5 минут при помощи curl. Использование низкоуровневых решений, вне зависимости от языка, необходимо только при острой в них необходимости (в вашем случае, если основная задача скрипта будет скачиванием-отправкой данных и скорость будет критична), во всех остальных случаях это не только увеличивает время разработки, но и дает дополнительную возможность ошибиться где-нибудь в коде. Излишняя оптимизация это тоже вредно