Комментарии 59
>> совершает какое либо дайствие?
Опечаточка))
Опечаточка))
gevent использует гринлеты. Против libevent ничего не имею, красивая штука. Но гринлеты — бууу. Stack slicing, лежащий в основе технологии, глюкав по определению. Слишком хакерская процедура. Не один раз наблюдал, как гринлеты и C Extensions входили в клинч. Упадет процесс или просто повиснет — дело случая.
Т.е. оно работает, но шаг влево-вправо приводит к неожиданным последствиям.
Т.е. оно работает, но шаг влево-вправо приводит к неожиданным последствиям.
И каково ваше предложение?
Мое предложение? Не понял вопроса.
Вы высказали критику в сторону гринлетов, а есть у вас предложение как «правильно» реализовать поставленную задачу?
Все еще не понимаю. Если речь идет о работе с сетью — то есть разные способы. Библиотек — дюжина.
А если конкретно о гринлетах — то никак не починишь. stackless делает переключение «правильно», но для этого нужно менять ceval. Т.е. stackless — это другой питон, а не библиотека для классического cpython.
А если конкретно о гринлетах — то никак не починишь. stackless делает переключение «правильно», но для этого нужно менять ceval. Т.е. stackless — это другой питон, а не библиотека для классического cpython.
У нас на gevent-wsgi-сервере крутится крупный проект. Уже около года. Обрабатывает порядка 200 запросов / сек. Там юзается lxml. Ничего подобного не замечал. Очень доволен gevent-ом.
lxml прокатит. Многие библиотеки работают — иначе бы о gevent вообще никто бы не говорил.
Беда случается, если вызывается callback. И если этот callback, скажем, работает со старым стеком, поврежденным stack slicing.
Это встречается нечасто, да и проявляться может не с первого раза. Зато уж если выползло — тушите свет. Доверие к Питону как к платформе резко падает, ломается просто непредсказуемо. Чуть-чуть подшаманив, можно восстановить работу. До следующего раза…
Очень неприятная ситуация. Корень зла — очень хакерский подход к подсовыванию стека для питоноввского фрейма. Оно работает. Время от времени.
Что касается gevent, то monkey-patching и покрытие тестами тоже доставляют.
Беда случается, если вызывается callback. И если этот callback, скажем, работает со старым стеком, поврежденным stack slicing.
Это встречается нечасто, да и проявляться может не с первого раза. Зато уж если выползло — тушите свет. Доверие к Питону как к платформе резко падает, ломается просто непредсказуемо. Чуть-чуть подшаманив, можно восстановить работу. До следующего раза…
Очень неприятная ситуация. Корень зла — очень хакерский подход к подсовыванию стека для питоноввского фрейма. Оно работает. Время от времени.
Что касается gevent, то monkey-patching и покрытие тестами тоже доставляют.
А где можно почитать про stack slicing? У меня что-то не нагуглилось.
Немножко пишут здесь: bitbucket.org/ambroff/greenlet/src/9e69243295dd/greenlet.c
Самое начало файла.
Да и вообще исходники стоит почитать. Их совсем немного.
Самое начало файла.
Да и вообще исходники стоит почитать. Их совсем немного.
НЛО прилетело и опубликовало эту надпись здесь
А выбор есть?
как костыль для веб-сокетов на ИЕ — флешу замены нет, но от фразы «а js не умеет работать с сокетами» меня слегка передернуло
dev.w3.org/html5/websockets/
dev.w3.org/html5/websockets/
А что это на картинке?
Как насчëт socket.io/? И тогда github.com/MrJoes/tornadio/
tornadio? А не проще перейти на node.js? Оно быстрее любого питона.
LOL. Жаль не все поймут эту шутку ;)
5 баллов, честное слово. :)
Перешел с socket.io-node на tornadio, т.к. такое решение проще интегрировать с не-реалтайм частью сайта, да и писать на питоне приятнее. У node.js тоже свои преимущества есть (главное — больше готовых асинхронных библиотеках), но в сумме преимущества чисто питоньего решения перевесили, ни разу не пожалел.
Пробовал торнадио. Пока еще, увы, слишком рано для продакшена.
а с какими трудностями столкнулись?
НЛО прилетело и опубликовало эту надпись здесь
Почему объемы кода должны быть обязательно меньше? Какой еще beaker.session, какие зависимости? И что не так с flashpolicy?
Интересно даже, в чем конкретно-то проблемы с tornadio. Мне-то просто показалось, что код там по делу, все работает, пользоваться удобно.
Интересно даже, в чем конкретно-то проблемы с tornadio. Мне-то просто показалось, что код там по делу, все работает, пользоваться удобно.
НЛО прилетело и опубликовало эту надпись здесь
1) Мы о разных библиотеках говорим: tornadio — это совсем не SocketTornad.IO.
2) flashpolicy-сервер — это не пример использования, а встроенная штука для того, чтобы из коробки иметь работающий flash-транспорт. В продакшне я для этого nginx настраиваю. К слушанию сокетов он не имеет ну никакого отношения, и отвечать xml он должен не на каждый запрос. Почему он написан так, как написан — судить не берусь, т.к. с flash знаком слабо. Как пользователя это меня не волнует, т.к. в продакшне эта штука не используется, а локально работает и есть не просит.
Примеры можно посмотреть в папке с примерами, очевидно) Например, вот чат: github.com/MrJoes/tornadio/blob/master/examples/chatroom/chatroom.py — куда уж проще?
2) flashpolicy-сервер — это не пример использования, а встроенная штука для того, чтобы из коробки иметь работающий flash-транспорт. В продакшне я для этого nginx настраиваю. К слушанию сокетов он не имеет ну никакого отношения, и отвечать xml он должен не на каждый запрос. Почему он написан так, как написан — судить не берусь, т.к. с flash знаком слабо. Как пользователя это меня не волнует, т.к. в продакшне эта штука не используется, а локально работает и есть не просит.
Примеры можно посмотреть в папке с примерами, очевидно) Например, вот чат: github.com/MrJoes/tornadio/blob/master/examples/chatroom/chatroom.py — куда уж проще?
tornadio как то упустил. Попробую, спасибо.
А почему Вы не попробовали напрямую работать с сокетами? Будет и быстро, и стабильно, и не слишком сложно (тут можно поспорить, но тем не менее, при грамотном подходе получится не сложнее фреймворка), и логику работы Вам легко будет подогнать под себя в случае чего.
А как предлагаете организовать сокеты на клиенте?
А с чем он, по-вашему, работает? Автор перечислил популярнейшие инструментарии для работы с неблокирующими сокетами.
Не писать же все заново!
Не писать же все заново!
Его задачей было сделать онлайн игру, причём время ответа от сервера критично. Вот я и интересуюсь, почему используются именно сторонние библиотеки, а не своя реализация асинхронного сервера, без лишних прослоек.
Может тогда ещё и на Си писать?
«Своя реализация» и всё равно будет прослойкой, только поддерживать её придётся самому.
Не стоит изобретать пылесос.
«Своя реализация» и всё равно будет прослойкой, только поддерживать её придётся самому.
Не стоит изобретать пылесос.
Стоит, если свой пылесос лучше справляется с нужной вам задачей, чем существующие решения. Если бы не было сподвижек в изобретении пылесосов, мы бы до сих пор заводили пылесосы на бензине из 19 века.
Угу… А если бы каждый изобретатель пылесоса начинал в высечения искры из камня и придумыванию колеса, то мы бы до технологий девятнадцатого века не добрались.
Я думаю, что в данном случае всё уже придумано. Автор показал нам три инструмента, и только если их не хватит, нужно будет начинать выдумывать что-то своё. А то правда, проект надо писать прямо сразу под конкретное железо на асме… Да и асм… Да и само железо…
Я думаю, что в данном случае всё уже придумано. Автор показал нам три инструмента, и только если их не хватит, нужно будет начинать выдумывать что-то своё. А то правда, проект надо писать прямо сразу под конкретное железо на асме… Да и асм… Да и само железо…
Кстати, а почему бы и нет? libev вроде не такой страшный. Конечно, нужно обладать опеделенными скилами, что бы писать на таком «остром как бритва» языке.
Gevent
— Не очень удобно.
Почему?
Не знаю, чем вам не понравились исходники торнады, там ведь всего ~10'000 строк, все написано с кучей комментариев и само по себе весьма pythonic.
Еще бы про клиента написали.
про клиент можно почитать тут.
Единственное что, используя такой способ, надо чтобы дополнительно висел сервер политик на 843 порту, либо эти самые политики раздавались на основном сервере. Например в пример сервера на twisted в dataReceived добавить:
Единственное что, используя такой способ, надо чтобы дополнительно висел сервер политик на 843 порту, либо эти самые политики раздавались на основном сервере. Например в пример сервера на twisted в dataReceived добавить:
file_policy="""<?xml version="1.0" encoding="UTF-8"?>\n
<cross-domain-policy xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:noNamespaceSchemaLocation='http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd'>\n
<allow-access-from domain="*" to-ports="*" secure="false" />\n
<site-control permitted-cross-domain-policies="master-only" />\n
</cross-domain-policy>\0"""
if line=='<policy-file-request/>\0':
self.transport.write(file_policy)
Сразу оговорюсь, что работал с ними очень и очень поверхностно, но впечатления такие:
Tornado — слишком тоненький, мало функций из коробки. И, насколько я знаю, нет поддержки пулов потоков (соединений с БД например)
Gevent — это очень не-мейнстрим и собрано на костылях и хаках со стеком и манкипатчингом
Twisted — весьма и весьма неплохо, но говорят что медленный
Думаю в случае возникновения необходимости держать постоянные соединения предпочту Erlang
Tornado — слишком тоненький, мало функций из коробки. И, насколько я знаю, нет поддержки пулов потоков (соединений с БД например)
Gevent — это очень не-мейнстрим и собрано на костылях и хаках со стеком и манкипатчингом
Twisted — весьма и весьма неплохо, но говорят что медленный
Думаю в случае возникновения необходимости держать постоянные соединения предпочту Erlang
Я в свое время написал библиотечку для NOC'а. Она легковесная и умещается в одном файле: lib/nbsocket.py. Можете попробовать. Для наших задач вполне хватает.
Облегчить сервер от ненужной работы, например отрисовки самой странички, используя вместо этого javascript шаблонизатор.
Практика показывает что это не всегда полезно. В вашем случае, если много одинаковых запросов с похожими данными, но разным представлением — смысл есть. У нас обычно много разносортных данных и опыт показал что для отрисовки на стороне клиента объем данных для темплейтинга растет намного быстрее чем объем уже отрисованных данных. Учитывая еще тот факт, что javascript шаблонизатор как правило медленее отрисовки на стороне сервера, я бы советал очень аккуратно подходить к такому приему.
Вообще, на своем опыте убедился что *очень* часто дешевле отрисовать HTML и вернуть клиенту, чем толкать все нужные для шаблона данные.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Асинхронный удар