Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 38
Хорошая штука для тех кто разрабатывает веб-софт на питоне.
А на питоне уже написаны довольно посещаемые сервисы, если верить Alexa.com — www.alexa.com/siteinfo/friendfeed.com+plurk.com
Думаю теперь все станут быстрее.
А есть у кого опыт использование его совместно с django?
Я думаю еще ни у кого =)
Опыта пока нет, но я думаю, что можно отлично строить обычную (просто динамические страницы) часть сайта на Django, а ту часть, что требует постоянных подключений — на Tornado
по идее все должно взлететь без проблем
wsgi судя по примерам поддерживается.
wsgi судя по примерам поддерживается.
Tornado comes with limited support for WSGI. However, since WSGI does not support non-blocking requests, you cannot use any of the asynchronous/non-blocking features of Tornado in your application if you choose to use WSGI instead of Tornado's HTTP server. Some of the features that are not available in WSGI applications: @tornado.web.asynchronous, the httpclient module, and the auth module.
www.tornadoweb.org/documentation#wsgi-and-google-appengine
www.tornadoweb.org/documentation#wsgi-and-google-appengine
скоро будет
Вот тут Amix (ведуший разработчик проекта Plurk) пишет про использование Tornado в качестве WSGI-сервера — amix.dk/blog/viewEntry/19472
Использовал такую вещь как fapws.
Судя по описанию практически то же самое только с использованием libevent.
Судя по описанию практически то же самое только с использованием libevent.
Жаль в таблице нет сравнения с twisted.
Из-за своей неблокирующей природы (используется epoll)а можно немного матчасти по этому вопросу? Чем отличаются блокирующий и неблокирующий веб-сервера?
По английски — www.developerfusion.com/article/28/introduction-to-tcpip/8/
Самая суть в первых двух параграфах:
One of the first issues that you’ll encounter when developing your Windows Sockets applications is the difference between blocking and non-blocking sockets. Whenever you perform some operation on a socket, it may not be able to complete immediately and return control back to your program. For example, a read on a socket cannot complete until some data has been sent by the remote host. If there is no data waiting to be read, one of two things can happen: the function can wait until some data has been written on the socket, or it can return immediately with an error that indicates that there is no data to be read.
The first case is called a blocking socket. In other words, the program is «blocked» until the request for data has been satisfied. When the remote system does write some data on the socket, the read operation will complete and execution of the program will resume. The second case is called a non-blocking socket, and requires that the application recognize the error condition and handle the situation appropriately. Programs that use non-blocking sockets typically use one of two methods when sending and receiving data. The first method, called polling, is when the program periodically attempts to read or write data from the socket (typically using a timer). The second, and preferred method, is to use what is called asynchronous notification. This means that the program is notified whenever a socket event takes place, and in turn can respond to that event. For example, if the remote program writes some data to the socket, a «read event» is generated so that program knows it can read the data from the socket at that point.
Самая суть в первых двух параграфах:
One of the first issues that you’ll encounter when developing your Windows Sockets applications is the difference between blocking and non-blocking sockets. Whenever you perform some operation on a socket, it may not be able to complete immediately and return control back to your program. For example, a read on a socket cannot complete until some data has been sent by the remote host. If there is no data waiting to be read, one of two things can happen: the function can wait until some data has been written on the socket, or it can return immediately with an error that indicates that there is no data to be read.
The first case is called a blocking socket. In other words, the program is «blocked» until the request for data has been satisfied. When the remote system does write some data on the socket, the read operation will complete and execution of the program will resume. The second case is called a non-blocking socket, and requires that the application recognize the error condition and handle the situation appropriately. Programs that use non-blocking sockets typically use one of two methods when sending and receiving data. The first method, called polling, is when the program periodically attempts to read or write data from the socket (typically using a timer). The second, and preferred method, is to use what is called asynchronous notification. This means that the program is notified whenever a socket event takes place, and in turn can respond to that event. For example, if the remote program writes some data to the socket, a «read event» is generated so that program knows it can read the data from the socket at that point.
хотел потестить, но под W7 не удалось по причине отсутствия fcntl модуля :(
Не очень понятно, откуда взялся такой отрыв от mod_wsgi. Он типа тоже неблокирующий.
1. Разница nginx/apache
2. Django все же чуть посложнее будет, а из-за этого и чуть помедленнее
Вообще я не думаю что Tornado — это серебрянная пуля. Я скорее радуюсь, что чуваки из Гугла не побоялись и собрали фреймфорк, который идеально подходит именно для их проекта :)))) (чуваки из Гугла — основатели friendfeed) Теперь-то понятно, как они собрали и развили такой немаленький сервис ввосьмером.
2. Django все же чуть посложнее будет, а из-за этого и чуть помедленнее
Вообще я не думаю что Tornado — это серебрянная пуля. Я скорее радуюсь, что чуваки из Гугла не побоялись и собрали фреймфорк, который идеально подходит именно для их проекта :)))) (чуваки из Гугла — основатели friendfeed) Теперь-то понятно, как они собрали и развили такой немаленький сервис ввосьмером.
Я не верю в разницу в 4 раза только из-за nginx/apache.
Там разница в 4 раза из-за проксирования запросов nginx'ом на 4 сервера Tornado. Точно так же можно сделать и с апачем (4 апача и nginx как реверс прокси).
Я думаю они это для красоты написали.
К тому же при проксировании Tornado будет бэкэндом, а не фронтэндом как у них написано.
Я думаю они это для красоты написали.
К тому же при проксировании Tornado будет бэкэндом, а не фронтэндом как у них написано.
У них все правильно написано: 4 nginx'а (фронтенда) кормят запросами 1 сервер торнадо (бекенд). Дело в том, что «hello, world» отдается бекендом гораздо быстрее, чем форнтенд справляется с обслуживанием подключений клиентов. Поэтому, в одиночку, фронтенд не способен нагрузить бекенд полностью. Хотя на 4-х ядрах логичнее было бы пускать 3+1.
Хм… А почему они его не сравнили с uwsgi. Это было бы интереснее.
Ну что hello world он отдаёт быстро — это хорошо. Интересно, а тот же Django сколько запросов в секунду способен генерировать? Запросов, обращающихся к базе и что-то делающих? Нет ли тут ускорения, которое в реальной системе не будет заметно?
Торнадо стоит использовать в тех случаях, когда есть возможность создания неблокирующихся обработчиков запросов. Чтиво по этой теме: twistedmatrix.com/projects/core/documentation/howto/async.html
У приложений Django иная модель обработки запросов.
У приложений Django иная модель обработки запросов.
Я при виде заголовка подумал было, что речь о возрождении «tornado bbs» в амплуа уже web-сервера ;-) Во времена fido был такой простенький и симпатичный bbs сервер по обслуживанию одного клиента.
Требую сравнение с Mochiweb
Интересная статистика.
Только мне похоже матчасти нехватает: почему они сравниваются не в одинаковых условиях?
ngix (поставленный фронендом) против Апача, это нормально?
Только мне похоже матчасти нехватает: почему они сравниваются не в одинаковых условиях?
ngix (поставленный фронендом) против Апача, это нормально?
чесно говоря Comet здесь ни при чем. для комета важна не скорость отработки запроса а способность сервера держать сотни тысяч подключений одновременно и долго.
график конечно интересный но боюсь бесполезный — сравнивать полнофункциональный апач с узкоспециализированным торнадо это что-то вроде заявить что феррари быстрее танка и лепить графики об этом на каждом углу.
кульминацией таких вот гонок будет сишный цикл отдающий статические данные на каждое входящее подключение — вот ведь где запрятался самый быстрый веб-сервер. а мы и не знали…
график конечно интересный но боюсь бесполезный — сравнивать полнофункциональный апач с узкоспециализированным торнадо это что-то вроде заявить что феррари быстрее танка и лепить графики об этом на каждом углу.
кульминацией таких вот гонок будет сишный цикл отдающий статические данные на каждое входящее подключение — вот ведь где запрятался самый быстрый веб-сервер. а мы и не знали…
Не передёргивайте, а почитайте лучше про асинхронную обработку запросов в Tornado. Именно для Comet (он же «long polling» или «push») Tornado подходит очень хорошо.
График показывает превосходство nginx над apache, а не tornado над django.
Однако, апачем всё равно будут пользоваться. Он надёжнее. По мнению хостинговых компаний, конечно :)
Однако, апачем всё равно будут пользоваться. Он надёжнее. По мнению хостинговых компаний, конечно :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Tornado Web Server