Я бы взглянул на evserver (http://code.google.com/p/evserver/), если все, что вам нужно, это комета.
. Он "поддерживает малоизвестное асинхронное расширение WSGI" и построен вокруг libevent. Работает как шарм.и поддерживает django. Фактический код обработчика немного уродлив, но он хорошо масштабируется, поскольку он действительно асинхронный.
Я использовал evserver, и в настоящее время я перехожу на циклон (торнадо на витой), потому что мне нужнонемного больше, чем у evserver. Мне нужен настоящий двунаправленный интерфейс io (думаю, socket.io (http://socket.io/)), и хотя evserver мог его поддерживать, я подумал, что проще переопределить socket.io торнадо в циклоне (я выбралЦиклон вместо торнадо, так как циклон построен на витой, что позволяет использовать больше транспортов, которые не реализованы в витой (ic zeromq)) Socket.io поддерживает веб-сокеты, опросы в стиле комет и, что гораздо важнее, пересекающиеся веб-сокеты на основе Flash.что в большинстве практических ситуаций веб-сокетов + флэш-сокетов на основе флэш-памяти достаточно для поддержки 99% (по данным Adobe Flash PenЭто составляет около 99% (http://www.adobe.com/products/player_census/flashplayer/version_penetration.html)) посетителей веб-сайтов (только люди, не использующие Flash, могут использовать один из сокетов socket.io - его резервные транспорты (с меньшими затратами ресурсов и ресурсов))
Знайте, хотя websockets не являются http-транспортом , поэтому размещение их за прокси-серверами, основанными на http (например, haproxy в режиме http), разрывает соединение.Лучше обслуживать их по альтернативному ip или порту, чтобы вы могли использовать прокси в режиме tcp (например, haproxy в режиме tcp).
Чтобы ответить на ваши вопросы: (1) Если вам не нужны решения на основе двунаправленного транспорта с длинным опросомдостаточно хороши (все, что они делают, это поддерживают соединение открытым).Вещи становятся неуместными, когда вам нужно, чтобы ваше соединение было полным, или вы должны иметь возможность и отправлять, и получать данные.В последнем случае socket.io помогает.Тем не менее, для этого сценария созданы веб-сокеты, и с поддержкой flash он доступен для большинства посетителей веб-сайтов (через socket.io или автономно, однако socket.io имеет дополнительное преимущество в виде транспорта для резервного копирования для тех, кто не хочет устанавливать flash)
(2) если все, что вам нужно, это нажать, evserver - ваш лучший выбор.Он использует те же самые javascripts на стороне клиента, что и на орбите.Еще посмотрите на socket.io (для этого также необходим поддерживающий сервер, единственный доступный питон - это tornado.)
(3) Это просто еще одна реализация сервера.Если я правильно прочитал, это только толчок.отправка данных клиенту осуществляется путем установки http equest из вашего приложения на сервер nginx.(Затем nginx позаботится о том, чтобы они достигли клиента).Если вы заинтересованы в этом, посмотрите на mongrel2 (http://mongrel2.org/home) имеет не только обработчики для длинного опроса, но и для веб-сокетов. (Вместо того, чтобы делать http-запрос к mongrel, на этот раз вы используете обработчики zeromq для передачи данных на ваш сервер mongrel)(Обратите внимание на то, что разработчик не проявляет энтузиазма по поводу веб-сокетов и веб-сокетов на основе флеш-памяти. Особенно принимая во внимание, что протокол веб-сокетов имеет тенденцию развиваться, в какой-то момент вам может понадобиться перекодировать поддержку веб-сокетов mongrel2 самостоятельно, продолжая поддерживать веб-сокеты)
(4) Все решения, кроме evserver, заменяют wsgi чем-то другим. Хотя большинство серверов также поддерживают некоторые wsgi поверх этого «чего-то другого». Независимо от того, какое решение вы выберете, будьте осторожны, если один процессор интенсивно или иначе блокирует запрос.не блокирует сервер (вам нужно несколько экземпляров или потоков).
(5) Не очень важно.Все решения зависят от некоторых пользовательских обработчиков, которые передают (и, если применимо, получают) данные клиенту.Все упомянутые решения позволяют писать эти обработчики на python.Если вы хотите использовать совершенно другой фреймворк (node.js), вам нужно взвесить легкость node.js (он предполагается легким, но также довольно экспериментальным, и я обнаружил, что очень немногие библиотеки действительно стабильны)удобство использования существующей кодовой базы и доступных библиотек (например, если вашему приложению нужен блог, существует множество блогов django, которые вы можете подключить, но нет ни одного для node.js). Также не закрывайте глаза на статистику производительности.если вы не планируете передавать тупые предопределенные данные (что делают все тесты) клиенту, вы обнаружите, что фактическая обработка данных добавляет намного дополнительных издержек, чем даже худшая асинхронная реализация.(Но вы по-прежнему хотите использовать сервер на основе асинхронного ввода-вывода, если вы планируете иметь много одновременных клиентов, многопоточность просто не предназначена для поддержки тысяч соединений)/ комета только выталкивает данные, но не принимает записи.(Socket.io имитирует эту двунаправленную поддержку, используя два http-запроса, один для longpoll, один для отправки данных. Он отслеживает их взаимозависимость по идентификатору (сеанса), который является частью строки запроса обоих запросов).Веб-сокеты на основе флэш-памяти аналогичны реальным веб-сокетам (разница в том, что их реализация в SWF, а не в браузере).Также протокол websockets не соответствует протоколу http;Лонгполлинг / кометы делают (технически клиент websocket отправляет запрос на обновление на сервер websocket, обновленный протокол больше не http)