Как стать автором
Обновить

Комментарии 16

НЛО прилетело и опубликовало эту надпись здесь
да, по торнадо — однозначно продолжать.
Интересует по торнадо — подробнее про концепт coroutine. И поглубже про yield.
Писал на торнадо аснхронный http прокси сервер, была беда, после недели работы, кончалась память, и его убивал oom. Как сейчас там с утечками?
Я с утечками не сталкивался ни разу. Возможно, это было что-то специфичное для прокси, какие-нибудь зависшие соединения.
было но давно, исправлено в какой-то версии 3.x с год назад см. changelog
Отличначя статья, просто и понятно. Спасибо.
А «распределенный» из заголовка статьи — это относится к возможности сконфигурить монгодб в кластер? А где тогда хоть пару строк про конфигурацию распределенности как базы так и самого приложения? Или в Торнадо есть своя уличная магия на этот счет? ;)
Всё верно — распределённость за счёт распределённости хранилища. Немного магии есть: tornado.process, но пользоваться ей не рекомендуется. А настройки монги и nginx мне показались лишними в этой вводной статье, тут же даже настроек самого Application нету :)
Спасибо. Про tornado.process — интересно почему не рекомендуется, из-за расширенных возможностей выстрелить в ногу при рестарте или IO операциях?
А вот тут подробно написано.
У меня ламерский вопрос. Почему для веб-сервисов используют медленные управляемые языки? Разве это не увеличивает нагрузку? Или узкое место — канал и диск?
Если вы про Python, Ruby и т.п., то тут чаще роль играет скорость разработки. Как-то в одной из презентаций яндекса рассказывалось, как они писали один из своих сервисов (вроде афишу), и для прототипирования было решено взять Django. Начали, посмотрели, подумали, так и остались на джанге (сейчас правда уже не знаю на чём, может поменялось). Во всяком случае подобный довод я слышу чаще всего, их много разных.
Очень многие задачи упираются в IO, а не в CPU. Чаще всего в БД. Для таких задач то, что они реализованы на Python или Ruby, не имеет существенной разницы с точки зрения производительности — от переписывания на Java/C#/C++/asm сильно быстрее не станет. А вот скорость разработки будет различаться в разы.
Если что-то упирается в производительность процессора/памяти, то это «что-то» обычно переписывают на чем-то более высоко-производительном. Частая связка, например, Ruby+Scala.
Как написали выше, то все упирается в жесткий диск, а не CPU. Если так-уж и происходит что ваше приложение где-то уперлось в CPU то обычно выносят эту часть системы на другой язык.

К примеру обработка фото на пайтоне займет много времени и cpu конечно-же. Чтоб это более не являлось узким горлышком, его переписывают C++ и состыковывают с пайтоном через Python C API в качестве пакета. В итоге вы получаете тяжелый кусок кода на C++, который меньше жрет процессора, а всё остальное работает на пайтоне.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории