Nginx HTTP Push Module(pushmodule.slact.net)
pushmodule.slact.net
Nginx HTTP Push Module
http://pushmodule.slact.net
10 comments
Beep. I wrote this. Questions, comments -- ask away.
Could you explain to the layman how this compares to the web server that ships with Tornado? I mean more in terms of usecases rather than performance. Also, the entire Tornado stack is written to be async and non-blocking. If one was to use something like plain vanilla PHP behind your nginx module, would one get the same result? Cheers.
This looks fantastic. Thanks for writing it.
How would you go about restricting access to channels to a specific user or users? My first take would be to issue an unguessable id upon successful authentication and use this id as the channel id -- a shared secret. Only those who should know the id do know it.
I don't see support for streaming; the connection to the long-polling client is closed after consuming. Are you planning on adding support for streaming new messages as they are published?
How would you go about restricting access to channels to a specific user or users? My first take would be to issue an unguessable id upon successful authentication and use this id as the channel id -- a shared secret. Only those who should know the id do know it.
I don't see support for streaming; the connection to the long-polling client is closed after consuming. Are you planning on adding support for streaming new messages as they are published?
I just had some time to scan your repository on GitHub and noticed this: http://github.com/slact/nginx_http_push_module/commit/6823f7...
Though it just looks like a stub for now.
Also, I read the following here: http://github.com/slact/nginx_http_push_module/issues/unread...
"Meanwhile, you can use your application to do the authenticating, and generate ids for already-authenticated clients from a large enough (> 2^128) keyspace for security."
So, there, I did my homework.
Though it just looks like a stub for now.
Also, I read the following here: http://github.com/slact/nginx_http_push_module/issues/unread...
"Meanwhile, you can use your application to do the authenticating, and generate ids for already-authenticated clients from a large enough (> 2^128) keyspace for security."
So, there, I did my homework.
I haven't tried to implement this yet, so i have no question so far. But i'd like to compliment you for this incredible useful module. Keep it up :)
This blog post explains it better : http://www.igvita.com/2009/10/21/nginx-comet-low-latency-ser...
did anyone already do performance tests? I'm especially interested in memory and cpu usage. Any limitations?
Everything is pretty much as efficient as vanilla nginx. There are some O(log(n)) lookups, but i've not noticed CPU usage hit anything even remotely suspicious (fixed bugs aside).
Memory usage for long-polling requests is regular nginx usage ("2.5MB for 10K idle connections"), + around a hundred bytes or so per ling-polling requests. A channel eats up about a dozen bytes.
The only limitation that one might run into is the maximum memory allotted for shared messages -- but that's a configurable value.
Memory usage for long-polling requests is regular nginx usage ("2.5MB for 10K idle connections"), + around a hundred bytes or so per ling-polling requests. A channel eats up about a dozen bytes.
The only limitation that one might run into is the maximum memory allotted for shared messages -- but that's a configurable value.
Site isn't working for me, but the github url is http://github.com/slact/nginx_http_push_module
Site isn't working for me, but the github url is http://github.com/slact/nginx_http_push_module