callback функция для curl

Статус
В этой теме нельзя размещать новые ответы.
а пассаж про - не только документов, не только тянуть - не совсем понятен. это все есстественно или я отстал от жизни и питон уже имеет свой JSдвижок для обработки сложных скриптов?
lol
Нормальное нагрузочное тестирование - это не долбёжка одного урла тысячу раз. Это нагрузка на все компоненты web-системы: отдача динамического и статического контента, download/upload данных и их обработка на сервере, использование web-сервисов (если таковые имеются).
Реплика про JS вообще не в тему, поскольку JS никакого отношения к нагрузочному тестированию web-приложений не имеет :D

Разумеется это можно сделать и на PHP, правда писать придётся больше.

А теперь то, с чем PHP не справится:
Собираем данные в обычном режиме.
Мне не надо тупо собирать - мне надо их параллельно обрабатывать. И если не понятно, чем в данном случае помогает поддержка многопоточности на уровне ЯП, то разговаривать дальше вобщем-то не о чем.

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

PHP_Master написал(а):
Всё написанное было бы верно, если бы мне нужно было грузить от одного юзера.
Но такое тестирование никому не интересно.
Пример - надо сэмулировать 100 непрерывных online-юзеров в течение 30 минут.
Для этого я беру список урлов (не только документов, но и картинки, js, css, архивы и т.д.) и запускаю 100 ботов (потоков) по нему.
Каждый бот ведёт свою стату, умеет парсить ответ на нахождение заданного признака, может не только тянуть данные, но и заливать, умеет работать с SOAP (и всё это элементарно настраивается и может выполняться одновременно). А ведь для каждого бота список урлов можно и перемешать, для чистоты эксперимента.
Ты знаешь простой способ сделать это на PHP? Я - не знаю.
в этом и проблема - что ты не знаешь и доказываешь. решение - оно как всегда элементарное, и если бы ты юзал мультикурл то знал бы, что мультикурл работает с массивом хендлов и настройки каждого хендла могут меняться независимо и в любой момент, а это означает что каждый поток может иметь независимый УРЛ, свою сессию и любые настройки выставляемые через сетопт, и после каждого выполнения это все может меняться.

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

ПЫХа имеет богатый арсенал инструментов для решения очень многих задач, и вовсе не обязательно каждый раз учить НОВЫЙ язык, хотя такие советчики найдутся на любом форуме, но это в корни неправильно - хороший специалист должен уметь решать проблемы имеющимся у него инструментарием, а не бежать каждый раз при виде нового шурупа за новой отверткой в магазин, лишь потому что ей на 20% легче откручивать один шуруп из 100, в общем то это и отличает практика от теоретика.

дискуссию в этой ветке прекращаю, думаю те кому нужно поняли суть и сделают правильный выбор.
 
bla-bla-bla и ничего конкретного кроме "ты лох с кучей свободного времени и ничего не умеешь".

Честно, я люблю PHP и он мне нравится. И multi_curl я юзаю, правда когда мне надо только сграбить контент. Если его при этом ещё необходимо обрабатывать, то PHP, как ни прискорбно, сливает.
Для особо непонятливых поторяю - не быстро тупо слить 100к страниц, а потом думать "**я, как мне их теперь пошурику распарсить", а делать это одновременно.
Можете плеваться и усираться доказывая обратное, но в итоге PHP с этой задачей справится медленнее, и не только Python'a.

ПЫХа имеет богатый арсенал инструментов для решения очень многих задач, и вовсе не обязательно каждый раз учить НОВЫЙ язык, хотя такие советчики найдутся на любом форуме, но это в корни неправильно - хороший специалист должен уметь решать проблемы имеющимся у него инструментарием, а не бежать каждый раз при виде нового шурупа за новой отверткой в магазин, лишь потому что ей на 20% легче откручивать один шуруп из 100, в общем то это и отличает практика от теоретика.
Хороший специалист должен владеть несколькими инструментами.
И использовать тот, который лучше подходит для решения конкретной задачи.
Возможно логика "Под рукой есть молоток, значит буду шурупы забивать, а не закручивать" и имеет право на существование, но она явно не вписывается в моё понятие термина "хороший специалист".

Действительно, PHP имеет богатый функционал и я с этим не спорю. На PHP можно написать практически всё что угодно - есть web- и smtp-серверы написанные на PHP, есть масса других примеров. Вопрос только в том как это работает и насколько быстро в сравнении с реализациями на других языках.

дискуссию в этой ветке прекращаю, думаю те кому нужно поняли суть и сделают правильный выбор.
Меня всегда поражала "быдлячесть" именно PHPшников - стоит только указать на недостатки этого языка, тут такое начинается...
Прям секта какая-то :D
 
ну на такое сложно не ответить
PHP_Master написал(а):
bla-bla-bla и ничего конкретного кроме "ты лох с кучей свободного времени и ничего не умеешь".
ты ведь предлагаешь подучить новый язык, когда человек столкнулся с такой проблемой - я предлагаю просто решение этой проблемы на текущем языке, на это как ты понимаешь нужно меньше свободного времени - о чем собственно и речь.
PHP_Master написал(а):
Честно, я люблю PHP и он мне нравится. И multi_curl я юзаю, правда когда мне надо только сграбить контент. Если его при этом ещё необходимо обрабатывать, то PHP, как ни прискорбно, сливает.
Для особо непонятливых поторяю - не быстро тупо слить 100к страниц, а потом думать "**я, как мне их теперь пошурику распарсить", а делать это одновременно.
с пониманием все прекрасно, я уже писал ни раз, что во первых одновременно 100К страниц тебе никакой веб сервер не отдаст, скаченные паги будут приходить постепенно, и остановок не будет тк работают процессы курловой либы и если не извращаться хитроумным парсингом то этого хватит чтобы поспевал один процесс, если нет то форкуются процессы и через пайп форкнутым процессам отдаются данные для парсинга, что делается также очень просто - несмотря на отличный от питона синтаксис. где тут будет медленнее - чем на питоне, мне не ясно. и уж точно что все это что я описал - определенно легче чем учить новый язык. это все что я хочу доказать - не до усрачки, но еще счастье попытаю.
PHP_Master написал(а):
Хороший специалист должен владеть несколькими инструментами.
И использовать тот, который лучше подходит для решения конкретной задачи.
Возможно логика "Под рукой есть молоток, значит буду шурупы забивать, а не закручивать" и имеет право на существование, но она явно не вписывается в моё понятие термина "хороший специалист".
согласись что и то и другое - скриптовые языки, и что оба они обладают очень близким друг к другу функцоиналом, поэтому сравнения молотка и отвертки не в кассу, и если человек знает только ПХП и у него есть задача которую нужно решить, то исходить нужно из того что у него есть? а именно отвертка с лейблом ПХП, и если он решает эту задачу - то он хороший спец, если он начниает тебя парить что счас подучу питончик и забацаю, то он нафик не нужен такой спец.
PHP_Master написал(а):
Меня всегда поражала "быдлячесть" именно PHPшников - стоит только указать на недостатки этого языка, тут такое начинается...
Прям секта какая-то :D
особо важного на пыхе уже давно не пишу, PHP в свой ник тоже не ставлю, и тут я отстаиваю не сам язык, который меня особо никогда не привлекал, а подход к решению проблемы - если при каждой сложности кидаться изучать новый язык, то добром это не закончится, а если учесть что в этом случае разница между языками вобще минимальна, то такие советы для новичков ни что иное как ЗЛО.
 
ты ведь предлагаешь подучить новый язык, когда человек столкнулся с такой проблемой - я предлагаю просто решение этой проблемы на текущем языке, на это как ты понимаешь нужно меньше свободного времени - о чем собственно и речь.
Если внимательно прочитать мои сообщения, а не только то, что хочется видеть, то несложно заметить, что я предлагал и multi_curl. А питон я советую если хочется нормальной многопоточности без танцев с бубном.

во первых одновременно 100К страниц тебе никакой веб сервер не отдаст
Где-то идёт речь что парсится только с одного сервера?

согласись что и то и другое - скриптовые языки, и что оба они обладают очень близким друг к другу функцоиналом, поэтому сравнения молотка и отвертки не в кассу
BMW и Лада тоже являются легковыми автомобилями, только ездят по разному - и по скорости и по комфорту.

если при каждой сложности кидаться изучать новый язык, то добром это не закончится, а если учесть что в этом случае разница между языками вобще минимальна, то такие советы для новичков ни что иное как ЗЛО
Если учиться программированию, а не языку, то разница между любыми языками минимальна (не учитывая функциональное программирование).
И уж никогда не думал, что освоение чего-то нового и расширение собственных навыков и кругозора - это "ЗЛО".

PHP - очень простой и удобный ЯП, но не стоит забывать, что он создавался конкретно под web (с чем замечательно справляется) и решать на нём все задачи не совсем разумно.
Теория - это конечно же очень красиво. Можно долго спорить, а можно написать парсер на любом многопоточном скриптовом языке и сравнить его с парсером на PHP + multi_curl, и сравнение будет не в пользу последнего. Я такое сравнение проводил, желание писать серьёзные парсеры на PHP у меня отпало.

Резюме: PHP+multi_curl - это частичное решение проблемы низкой производительности. Если хочется реально многопоточной работы (и не только в парсинге), стоит смотреть в сторону других ЯП. Как минимум от изучения дополнительного языка, глупее не станете.
 
пхп, питон, перл...
что лучше для потоков...
Ребята поверьте никогда !!!! никогда не сравнится интерпритируемый язык (список выше) с нормальным полноценным та же с++ например...
и если идет реч о скорости и супер большого количества потоков то эта димогогия вообще не в тему!!!!!!!
тогда если охото побыстрому своять нужно брать QT4 и на нем писать...
это только если хотите побстрому написать,а правельнее все самому гы... тотже libcurl под себя переточить.... куда пкрасивее будет.
 
Ребята поверьте никогда !!!! никогда не сравнится интерпритируемый язык (список выше) с нормальным полноценным та же с++ например...
Кто бы мог подумать :D
С этим никто и не спорит.
Только у скомпилированных бинарников есть проблемы с переносимостью на разные платформы, да и на хостинге тебе никто не даст запускать бинарник или компилировать его из сорцов.
 
пхп, питон, перл...
что лучше для потоков...
Ребята поверьте никогда !!!! никогда не сравнится интерпритируемый язык (список выше) с нормальным полноценным та же с++ например...

Напишешь на "полноценном, нормальном языке" ПО для VDS (CPU 200, RAM 220) для граббинга страниц, со скоростью 20к страниц в минуту? Напишешь - признаю, что пых в этом сосёт.

ЗЫ: интерпрЕтация.
 
Наверное никто не думал о том что для серьезныйх проэктов нужен серьезный железяк.. насколько я понял человеку нужно оочень много страниц спарсить а про vds или просто шаред хостинг никто не упоминал...
Это раз
А второе человек спрашивает на чем луше сделать и как...
ЗЫ причем тут хостинги о них речи и небыло
2Jeurey зачем изобретать велосипед??? :)
 
2Jeurey зачем изобретать велосипед???
Скрытый текст, требуется (100 сообщение(ий), у вас 2651:(
Для просмотра ссылки Войди или Зарегистрируйся
парсинг - это ещё и разбор страниц, а не только их загрузка :D
Парсер должен быть не только быстрым, но и удобным. А по части удобства интерпретаторы выигрывают у компиляторов.
Клиенты - особи весьма вредные :D
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху