Комментарии 24
Поправьте код (используйте тег pre или какой-нибудь раскрашиватель кода) — это же python, а без отступов вообще не читается.
Основная прелесть этого кусочка кода в том, что все запросы на получение страниц с помощью вызова urllib2.urlopen выполняются параллельно.
Вообще-то gevent однопоточный, а grennlets — это не native threads — это всего лишь одна из техник асинхронного программирования (наряду с callbacks). Они дают псевдомногопоточность, так же как и tasklets в Stackless. Они выполняются не параллельно. Асинхронные вызовы все равно будут отправляться по очереди, а не в один момент времени, так же как и обработка ответов будет по очереди.
Не вижу противоречия между отквоченым и комментарием. Причем тут потоки? Запросы будут исполняться параллельно, т.е. следующий стартует не после завершения предыдущего, а во время ожидания его результата. Асинхронно=параллельно.
Потоки тут неэффективны, на них затрачиваются лишние ресурсы, а они все время спят, ожидая ввода-вывода и результатов запроса. Яркий пример — шустрый и легкий nginx.
Потоки тут неэффективны, на них затрачиваются лишние ресурсы, а они все время спят, ожидая ввода-вывода и результатов запроса. Яркий пример — шустрый и легкий nginx.
А я юзал threading.Thread run, join для таких целей.
Думал, gevent — это хттп-сервер для питон.
Думал, gevent — это хттп-сервер для питон.
А я юзал threading.Thread run, join для таких целей.
Думал, gevent — это хттп-сервер для питон.
Думал, gevent — это хттп-сервер для питон.
>следующий стартует не после завершения предыдущего
А я и не утверждал обратное. Я говорил о самом запросе и разборе ответа, а не о ожидании ответа. Т.е. скажем, мы послали первый запрос, затем послали второй и т.д., а потом собираем по очереди ответы. Мы не можем в один и тот же момент времени послать 2 запроса. Мы можем послать второй запрос не дожидаясь ответа первого, но НЕ одновременно с ним.
>Асинхронно=параллельно
Не во всех случаях. Вот смотрите, пока будет парсится http-response одного запроса разве можно в это время сделать другой? Нет! Эта операция заблокирует поток. Я понимаю что на очень-очень короткое время, но все же за это время мы ничего другого сделать не сможем, поэтому тут слово параллельно не очень хорошо подходит.
А я и не утверждал обратное. Я говорил о самом запросе и разборе ответа, а не о ожидании ответа. Т.е. скажем, мы послали первый запрос, затем послали второй и т.д., а потом собираем по очереди ответы. Мы не можем в один и тот же момент времени послать 2 запроса. Мы можем послать второй запрос не дожидаясь ответа первого, но НЕ одновременно с ним.
>Асинхронно=параллельно
Не во всех случаях. Вот смотрите, пока будет парсится http-response одного запроса разве можно в это время сделать другой? Нет! Эта операция заблокирует поток. Я понимаю что на очень-очень короткое время, но все же за это время мы ничего другого сделать не сможем, поэтому тут слово параллельно не очень хорошо подходит.
> Мы не можем в один и тот же момент времени послать 2 запроса. Мы можем послать второй запрос не дожидаясь ответа первого, но НЕ одновременно с ним.
в асинхронном режиме запрос посылается моментально
разбирать ответы было бы разумно в нескольких процессах через multiprocessing
или передавая их через mq в другое приложение
в асинхронном режиме запрос посылается моментально
разбирать ответы было бы разумно в нескольких процессах через multiprocessing
или передавая их через mq в другое приложение
Мы с вами не договорились о термине «параллельно». Вы ставите знак равенства со словом «многопоточно», я считаю это не совсем верным. По-моему параллельно — это «в одно и то же время».
Речь о полном цикле от посылки запроса до получения ответа, разве нет? Такие циклы идут параллельно. Т.е. когда идет один такой цикл, может идти и другой.
Если говорить о более мелких частях запроса, конкретно в это библиотеке не знаю, но в классической асинхронной программе парсинг http-response будет также идти одновременно, готовы 10 байтов того респонза (вытащены из сокета) — парсим их, а пока подходят байты другого респонза.
Либо вы хотите сказать параллельно — это «не отнимает процессорное времени у другого». Но и при таком толковании потоки не панацея — они также отнимают время друг у друга на одноядерном процессоре, да и на многоядерном блокировки неизбежны для синхронизации доступа к ресурсам. «Отнимание процессорного времени» здесь дешево, обработка запроса несоизмерима с тактами процессора.
Стоит также заметить, что по проводу данные идут не «мультитредно» а однопоточно, для «многозадачности» используется именно асинхронность, поэтому она естественна для сетевых приложений (правда здорово запутывает код).
Речь о полном цикле от посылки запроса до получения ответа, разве нет? Такие циклы идут параллельно. Т.е. когда идет один такой цикл, может идти и другой.
Если говорить о более мелких частях запроса, конкретно в это библиотеке не знаю, но в классической асинхронной программе парсинг http-response будет также идти одновременно, готовы 10 байтов того респонза (вытащены из сокета) — парсим их, а пока подходят байты другого респонза.
Либо вы хотите сказать параллельно — это «не отнимает процессорное времени у другого». Но и при таком толковании потоки не панацея — они также отнимают время друг у друга на одноядерном процессоре, да и на многоядерном блокировки неизбежны для синхронизации доступа к ресурсам. «Отнимание процессорного времени» здесь дешево, обработка запроса несоизмерима с тактами процессора.
Стоит также заметить, что по проводу данные идут не «мультитредно» а однопоточно, для «многозадачности» используется именно асинхронность, поэтому она естественна для сетевых приложений (правда здорово запутывает код).
>Вы ставите знак равенства со словом «многопоточно», я считаю это не совсем верным.
Где вы такое прочитали? O_o Параллельно для меня — э то значит в один и тот же момент времени, а не по очереди.
Где вы такое прочитали? O_o Параллельно для меня — э то значит в один и тот же момент времени, а не по очереди.
>Вы ставите знак равенства со словом «многопоточно», я считаю это не совсем верным.
Где вы такое прочитали? O_o Параллельно для меня — э то значит в один и тот же момент времени, а не по очереди.
>да и на многоядерном блокировки неизбежны для синхронизации доступа к ресурсам.
Все же скажем на 2-х ядерном процессоре возможно именно одновременное (параллельное в моем понимании) выполнение 2-х процессов.
Да, ладно вам. Я просто к слову придрался чуть-чуть, не обращайте внимания :-) Я вижу, что мы с вами одинаково это понимаем, только называем по-разному :-(
Где вы такое прочитали? O_o Параллельно для меня — э то значит в один и тот же момент времени, а не по очереди.
>да и на многоядерном блокировки неизбежны для синхронизации доступа к ресурсам.
Все же скажем на 2-х ядерном процессоре возможно именно одновременное (параллельное в моем понимании) выполнение 2-х процессов.
Да, ладно вам. Я просто к слову придрался чуть-чуть, не обращайте внимания :-) Я вижу, что мы с вами одинаково это понимаем, только называем по-разному :-(
>Стоит также заметить, что по проводу данные идут не «мультитредно» а однопоточно
Вот это отличное замечание. Но ведь мы имеем обычно множество вариантов того, как сигнал дойдет до получателя. В смысле, множество маршрутов. Или нет?
Вот это отличное замечание. Но ведь мы имеем обычно множество вариантов того, как сигнал дойдет до получателя. В смысле, множество маршрутов. Или нет?
Спасибо что рассказали о такой либе, у меня как раз есть небольшая программа делающая много сетевых запросов, сегодня же попробую в действии.
Если не секрет, а кто собирается менторить проекты со стороны gevent?
Охренеть, monkey.patch_all() и всё сетевое асинхронится. Реальная волшба :)
Потестил wsgi-сервер с отключенным spawn, быстрее tornado работает. Со включенным, чуточку медленнее последнего. Памяти сравнимо кушают.
В общем, рад несказанно, респектище :)
Потестил wsgi-сервер с отключенным spawn, быстрее tornado работает. Со включенным, чуточку медленнее последнего. Памяти сравнимо кушают.
В общем, рад несказанно, респектище :)
Nginx mod_wsgi предоставляет API к своему poll-интерфейсу, который можно использовать для реализации цикла gevent — только представьте — nginx как сервер асинхронных python-приложений.Не надо переоценивать роль энджиникса. Это распространенная ошибка, когда хотят в серверную логику запихать логику бэкэнда. Это может привести к сокетному голоданию и тогда наступит полный, сами понимаете что.
Надо бы попробовать libev прикрутить. Ещё быстрее будет)
Не факт, я давно не видел бенчмарков для актуальных версий libevent и libev.
Мы пробовали :-). Libev шустрее.
Интересно посмотреть на графики :-) вобщем, факты в студию.
дык а чего факты-то.
вон например www.pps.jussieu.fr/~kerneis/software/files/libev-vs-libevent/dat.t1.png.
давно ясно что libevent2 быстрее чем libevent1 и сравним с libev. Но libevent2 до сих пор в альфа-стадии и там много касяков (течёт по памяти => not production ready).
вон например www.pps.jussieu.fr/~kerneis/software/files/libev-vs-libevent/dat.t1.png.
давно ясно что libevent2 быстрее чем libevent1 и сравним с libev. Но libevent2 до сих пор в альфа-стадии и там много касяков (течёт по памяти => not production ready).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проекты Python в рамках Google Summer of Code — gevent