Comments 33
Спасибо за труд! Интересно было бы увидеть пример реализации сервиса в GAE с использованием subj. В тексте ссылка не работает. Может быть стоило сделать ссылки на оригинал, пока не перевели?
Посмотрел оригинал — оказывается там никакой ссылки нет, просто нужно смотреть пример (вероятно с документацией их идёт целый комплект).
Спасибо, вики автоматом внутреннею ссылку создала, сделал линк на github.
Сначала была мысль сделать перевод inline комментариев в демках, но для этого желательно воротить отдельный git и морочиться его актуальностью, чтобы никто случайно не стал брать код сервера оттуда.
Сейчас мне кажется лучше оформить демки в виде поэтапных туториалов с комментариями.
Сначала была мысль сделать перевод inline комментариев в демках, но для этого желательно воротить отдельный git и морочиться его актуальностью, чтобы никто случайно не стал брать код сервера оттуда.
Сейчас мне кажется лучше оформить демки в виде поэтапных туториалов с комментариями.
Tornado в GAE? O_o
Мне кажется вы не поняли что такое tornado, либо не поняли что такое GAE.
Мне кажется вы не поняли что такое tornado, либо не поняли что такое GAE.
Что насчёт поддержки? Его дальше пилять разработчики или как выложили год назад версию так и лежит?
UFO just landed and posted this here
На пальцах: классическая блокирующая схема, это когда к серверу пришел запрос сервер должен его отработать и выплюнуть ответ.
В неблокирующей схеме можно спокойно открыть соединение, повесить передачу данных по нему на событие, и в ожидании данных по тому или иному соединению приложение продолжает заниматься своими делами или обслуживать другие соединения, пока возникшее событие не затребует передачи управления для его обработки.
Пассивно висящее соединения почти ничего не требует для своего обслуживания и поэтому их может быть очень много.
В неблокирующей схеме можно спокойно открыть соединение, повесить передачу данных по нему на событие, и в ожидании данных по тому или иному соединению приложение продолжает заниматься своими делами или обслуживать другие соединения, пока возникшее событие не затребует передачи управления для его обработки.
Пассивно висящее соединения почти ничего не требует для своего обслуживания и поэтому их может быть очень много.
UFO just landed and posted this here
Он не только может быть, но и настоятельно рекомендуется к продакшену.
В мане описан тест производительности, плюс его бурное обсуждение на хабре:
habrahabr.ru/blogs/python/69346/
Правда суть бурности сводится к тому, что часть людей не прочитала о методике тестирования, а часть не дочитала до конца. Поэтому тред абсолютно неинформативный.
Плюс там сравниваются именно продакшен решения. Я просто советую прочесть раздел мана о производительности.
Тестировать на hello world имхо некорректно, лучше взять какой ни будь маленький чатик или бложек, чтобы еще с БД работал, вот тогда архитектура может показать чудеса, а не четырехкратное превосходство, сейчас объясню почему:
Обычно веб-приложение сохраняет стейт в базе данных и кукисах, то есть ему нужно постоянно работать с БД, на практике нагрузка на сервера БД может быть много серьезнее, чем на сервер приложений, ну и, ясное дело, все эта возня приложения с БД по каждому чиху пользователя вносит лаги.
На торнадо же можно спокойно организовать внутренние кэши объектов и состояний, особенно для простых данных, что активно используется в большинстве реальных приложений на нем. Жонглирование этими кэшами требует некоторого мозгового напряжения, но результат того стоит.
Допустим, у приложения есть кэш содержащий 1000 пользователей, обращавшихся в последний раз, вот пользователь перешел на новую страничку, сервер смотрит данные о нем во внутреннем классе-кэше и вытаскивает их оттуда, если пользователь там находится. В итоге экономим запрос.
Или у нас то там то сям должна появляться лента последних 10 сообщений в чятике или облако тегов… ну вы поняли, они просто живут в стейте приложения. В итоге БД тупо не нужна. Не нужна до тех пор пока сервер не упадет :) А это случается. Поэтому для большинства операций запрашивающих состояние кэш можно хранить спокойно, а вот апдейтящие состояния приложения можно, например, порционно флашить в БД по заполнению апдейт-буфера или таймаутам, если он заполняется медленно.
Короче стейты у самого веб-приложения — это сразу куча возможностей и принципиальное изменение архитектуры, если даже примитивное приложение создавать с их учетом, то разрыв в производительности должен быть очень внушительным. Вот такой вот забавный парадокс, что на практике Tornado может оказаться много быстрее чем по тестам :)
В мане описан тест производительности, плюс его бурное обсуждение на хабре:
habrahabr.ru/blogs/python/69346/
Правда суть бурности сводится к тому, что часть людей не прочитала о методике тестирования, а часть не дочитала до конца. Поэтому тред абсолютно неинформативный.
Плюс там сравниваются именно продакшен решения. Я просто советую прочесть раздел мана о производительности.
Тестировать на hello world имхо некорректно, лучше взять какой ни будь маленький чатик или бложек, чтобы еще с БД работал, вот тогда архитектура может показать чудеса, а не четырехкратное превосходство, сейчас объясню почему:
Обычно веб-приложение сохраняет стейт в базе данных и кукисах, то есть ему нужно постоянно работать с БД, на практике нагрузка на сервера БД может быть много серьезнее, чем на сервер приложений, ну и, ясное дело, все эта возня приложения с БД по каждому чиху пользователя вносит лаги.
На торнадо же можно спокойно организовать внутренние кэши объектов и состояний, особенно для простых данных, что активно используется в большинстве реальных приложений на нем. Жонглирование этими кэшами требует некоторого мозгового напряжения, но результат того стоит.
Допустим, у приложения есть кэш содержащий 1000 пользователей, обращавшихся в последний раз, вот пользователь перешел на новую страничку, сервер смотрит данные о нем во внутреннем классе-кэше и вытаскивает их оттуда, если пользователь там находится. В итоге экономим запрос.
Или у нас то там то сям должна появляться лента последних 10 сообщений в чятике или облако тегов… ну вы поняли, они просто живут в стейте приложения. В итоге БД тупо не нужна. Не нужна до тех пор пока сервер не упадет :) А это случается. Поэтому для большинства операций запрашивающих состояние кэш можно хранить спокойно, а вот апдейтящие состояния приложения можно, например, порционно флашить в БД по заполнению апдейт-буфера или таймаутам, если он заполняется медленно.
Короче стейты у самого веб-приложения — это сразу куча возможностей и принципиальное изменение архитектуры, если даже примитивное приложение создавать с их учетом, то разрыв в производительности должен быть очень внушительным. Вот такой вот забавный парадокс, что на практике Tornado может оказаться много быстрее чем по тестам :)
Еще хотелось бы добавить в какой свет это окрашивает девелопмент.
Для некоторых проектов торнадо действительно серебряная пуля, но это не MVC а VC фреймворк, с моделью извольте морочиться сами (фремфорк содержит библиотеку лишь чуть-чуть упрощающую работу с БД), с учетом специфики это резкий рост человекочасов на разработку.
Учитывая, что в принципе архитектура приложений на торнадо документирована плохо — есть полтора примера без комментариев и все, а наличие стейтов и прочие радости с непривычки выкручивают мозг почти любому веб-разработчику, время разработки опять же увеличивается.
Изобилия свистелок и перделок Django там тоже нет, фактически голая платформа, извольте все ручками.
С другой стороны масштабируемость, исключительная простота разворачивания и т.д. могут сильно сэкономить время потом. Очень просто ключевые классы оформить в виде фабрики, и осуществлять «сборку» в зависимости от порта, на котором запущено приложение. Допустим, во время тестирования при запуске на один порт осуществляется работа с одной базой данных, а на другом порту классы ответственные за модель соберутся для работы с другой, или и вовсе будут заглушкой, и вперед — сравнивать работу запущенных вариантов сборок.
Сейчас куча разработчиков пытается скрестить торнадо с блокирующими архиектурами, что по суди феерический идиотизм и полное непонимание того, какая платформа им нужна в итоге, на практике разумно использовать гибриды, допустим частые ajax-запросы обрабатывать висящим торнадо, все остальное быстренько набросать на django, (ясно что ту часть, что на торнадо нужно будет ручками дружить с моделью костяка на django но это не очень страшно) опять же примеров подобных архитектур для изучения практически нет.
Короче это офигенный сервер-фреймворк, но нужно четко понимать что он умеет и зачем нужен.
Для некоторых проектов торнадо действительно серебряная пуля, но это не MVC а VC фреймворк, с моделью извольте морочиться сами (фремфорк содержит библиотеку лишь чуть-чуть упрощающую работу с БД), с учетом специфики это резкий рост человекочасов на разработку.
Учитывая, что в принципе архитектура приложений на торнадо документирована плохо — есть полтора примера без комментариев и все, а наличие стейтов и прочие радости с непривычки выкручивают мозг почти любому веб-разработчику, время разработки опять же увеличивается.
Изобилия свистелок и перделок Django там тоже нет, фактически голая платформа, извольте все ручками.
С другой стороны масштабируемость, исключительная простота разворачивания и т.д. могут сильно сэкономить время потом. Очень просто ключевые классы оформить в виде фабрики, и осуществлять «сборку» в зависимости от порта, на котором запущено приложение. Допустим, во время тестирования при запуске на один порт осуществляется работа с одной базой данных, а на другом порту классы ответственные за модель соберутся для работы с другой, или и вовсе будут заглушкой, и вперед — сравнивать работу запущенных вариантов сборок.
Сейчас куча разработчиков пытается скрестить торнадо с блокирующими архиектурами, что по суди феерический идиотизм и полное непонимание того, какая платформа им нужна в итоге, на практике разумно использовать гибриды, допустим частые ajax-запросы обрабатывать висящим торнадо, все остальное быстренько набросать на django, (ясно что ту часть, что на торнадо нужно будет ручками дружить с моделью костяка на django но это не очень страшно) опять же примеров подобных архитектур для изучения практически нет.
Короче это офигенный сервер-фреймворк, но нужно четко понимать что он умеет и зачем нужен.
а вы не встречались на практике со связкой nginx tornado django. рекомендации такой связки, вроде бы, была недопиленность WCGI у nginx?
ЗЫ меня смутило наличие темплейтового движка в веб-сервере — мне как-то кажется это лишним
ЗЫ меня смутило наличие темплейтового движка в веб-сервере — мне как-то кажется это лишним
Очень странный вариант, есть вроде такой мод, но зачем? nginx хорош как прокси, лоадбалансер и сервер статики, то есть морда. Не нужно под ним питона гонять, они от этого дохнут. Под ним уже можно разворачивать apache с django и торнадовские инстансы, по которым распределены запросы.
Это не только сервер, но и фреймворк, архитектура бесшовная, то есть у него есть свой input-output loop, механизм отработки статики (кстати, весьма неплохо придуманный) и т.д., но есть и шаблонизатор, хэндлеры запросов, мэппер ЧПУ и прочая атрибутика, плюс простенькие прослойки для БД.
Шаблонизатор сам по себе нормальный типа флетлайна, хорошо оптимизированный и для большинства целей его хватит за глаза.
Мне тоже в начале это решение показалось немного необычным, но сейчас скорее склонен его расценивать как передовое, очень много плюсов связанных с разворачиванием отладкой, и управлением инстансами.
Это не только сервер, но и фреймворк, архитектура бесшовная, то есть у него есть свой input-output loop, механизм отработки статики (кстати, весьма неплохо придуманный) и т.д., но есть и шаблонизатор, хэндлеры запросов, мэппер ЧПУ и прочая атрибутика, плюс простенькие прослойки для БД.
Шаблонизатор сам по себе нормальный типа флетлайна, хорошо оптимизированный и для большинства целей его хватит за глаза.
Мне тоже в начале это решение показалось немного необычным, но сейчас скорее склонен его расценивать как передовое, очень много плюсов связанных с разворачиванием отладкой, и управлением инстансами.
гм, я вообще всеми правдами отказаться от апача.
на счет второго абзаца — я так понимаю стоит отдельно сравнить связки с nginx и просто tornado-django?
на счет второго абзаца — я так понимаю стоит отдельно сравнить связки с nginx и просто tornado-django?
Не совсем понял по каким критериям сравнивать, производительности?
производительность + безбажность )
По тестам сравнивали tornado+nginx против Apache и разных питоновских фреймворков на нем.
При множественных обращениях апач с wscgi плодит свои процессы или потоки более или менее равномерно загружая ядра.
Торнадо будучи запущенным одним инстансом без балансировщика живет в рамках одного процесса, соответственно при большой нагрузке упрется лбом в свое ядро и просядет намного раньше. Поэтому если мы говорим о производительности его на любой многоядерной системе пускают с ngnix (если это не два ядра с БД на том же сервере) с кратным количеству ядер количеством инстансов.
Просто серверу с апачем на одном порте наличие nginx не так уж и важно, апач в пределах одной машины сам неплохо разберется с ресурсами и никакой прибавки от его использования не будет, поэтому его из тестов других платформ исключили.
Если он правильно развернут, то по сравнению с LAMP это настоящая дробилка, которая не дохнет не под мелочью ажаксов ни под длинными отдачами.
Насчет глючности, судя по рассылке иногда глючит, баги в сервере вылавливают в достаточно быстро, за дни, недели, правда последний крупный релиз уже староват, нужно брать свежую версию из репозитория.
Видел жалобы, что падают запущенные ноды по достаточно мутным причинам, чтобы с ними определиться надо щупать само приложение, может внутренний кэш протекает или еще что, у меня пока на тестах не было. Но вряд ли разработчик будет рассчитывать на непадающий инстанс и долго хранить в состоянии приложения что-то ключевое.
Мне это кажется лучшим вариантом, чем гадать почему именно в это полнолуние апач при никакой нагрузке попытался съесть все системные ресурсы, подавился и сдох.
При множественных обращениях апач с wscgi плодит свои процессы или потоки более или менее равномерно загружая ядра.
Торнадо будучи запущенным одним инстансом без балансировщика живет в рамках одного процесса, соответственно при большой нагрузке упрется лбом в свое ядро и просядет намного раньше. Поэтому если мы говорим о производительности его на любой многоядерной системе пускают с ngnix (если это не два ядра с БД на том же сервере) с кратным количеству ядер количеством инстансов.
Просто серверу с апачем на одном порте наличие nginx не так уж и важно, апач в пределах одной машины сам неплохо разберется с ресурсами и никакой прибавки от его использования не будет, поэтому его из тестов других платформ исключили.
Если он правильно развернут, то по сравнению с LAMP это настоящая дробилка, которая не дохнет не под мелочью ажаксов ни под длинными отдачами.
Насчет глючности, судя по рассылке иногда глючит, баги в сервере вылавливают в достаточно быстро, за дни, недели, правда последний крупный релиз уже староват, нужно брать свежую версию из репозитория.
Видел жалобы, что падают запущенные ноды по достаточно мутным причинам, чтобы с ними определиться надо щупать само приложение, может внутренний кэш протекает или еще что, у меня пока на тестах не было. Но вряд ли разработчик будет рассчитывать на непадающий инстанс и долго хранить в состоянии приложения что-то ключевое.
Мне это кажется лучшим вариантом, чем гадать почему именно в это полнолуние апач при никакой нагрузке попытался съесть все системные ресурсы, подавился и сдох.
Джанго — это всги. Тут нужно понять простую вещь, торнадо в всги-варианте превращается из асинхронного сервера в однопоточный. Если ничего длительного (сетевого, например, типа загрузки картинок юзерами) не происходит, всё будет нормально. А если такое планируется, то на время таких операций сайт будет подвисать у *всех* юзеров.
Или вот еще один пример для размышления, мы пишем игру, например, в морской бой, у нас есть партии. Ммы берем и храним состояния текущих партий в стейтах, ни одного запроса к БД пока партия не закончится и мы не захотим запостить в БД ее результаты. Выглядит чудесно до определенного момента.
А теперь у нас несколько инстансов торнадо с разными стейтами, партия ведь живет только в одном из них. Что тогда делать? Выравнивать стейты инстансов через БД, что сведет все преимущества на нет, или ручками дописывать второй слой балансировки для определенных запросов, привязывая к пользователям? А точно ли тогда хорошо ляжет нагрузка? А может привязать к серверам своего рода румы, как часто делается и не париться, но тогда может сложиться, что один или два сервера забиты, а остальные стоят на нуле, какая нафиг балансировка. Или придумывать что-то более хитрое.
То есть невероятный профит от стейтов одновременно резко усложнит архитектуру и готовых рецептов пока нет.
А теперь у нас несколько инстансов торнадо с разными стейтами, партия ведь живет только в одном из них. Что тогда делать? Выравнивать стейты инстансов через БД, что сведет все преимущества на нет, или ручками дописывать второй слой балансировки для определенных запросов, привязывая к пользователям? А точно ли тогда хорошо ляжет нагрузка? А может привязать к серверам своего рода румы, как часто делается и не париться, но тогда может сложиться, что один или два сервера забиты, а остальные стоят на нуле, какая нафиг балансировка. Или придумывать что-то более хитрое.
То есть невероятный профит от стейтов одновременно резко усложнит архитектуру и готовых рецептов пока нет.
UFO just landed and posted this here
Попробуйте связаться с создателем trellis-club.com, он обычно делится с желающими исходниками старой версии проекта и в принципе хочет в перспективе создать универсальный движок для онлайн-игр на торнадо.
Исходники несколько хаотичны и недокументированны, но это самое серьезное из того, что попадалось. Может на гитхабе появилось еще что-то интересное.
Исходники несколько хаотичны и недокументированны, но это самое серьезное из того, что попадалось. Может на гитхабе появилось еще что-то интересное.
UFO just landed and posted this here
Зачем?
о, спасибо огромное за документацию!
только собирался изучать, и тут еще удобнее :)
только собирался изучать, и тут еще удобнее :)
Sign up to leave a comment.
Документация tornado на русском языке