If you have millions of users on line, I think you'll be facing other problems
than just
Socket.io, some old-ish benchmarks showed socket.io maxing out at around 5-20K
concurrents in a single process, other websocket servers performed differently.
If
you're serious about scaling realtime infrastructure, then you should probably
have
a look at talks from Keeping It Realtime Conference (http://2011.krtconf.com/),
as well
as looking into Autobahn Test Suite benchmarks.
Things to be cautious of:
- You'll need a way to do load balancing (Traditional load balancers tend
to fail
pretty hard with WebSockets or persistent Connections)
- I would NOT recommend using redis or any other centralised message bus,
this
is by far the easiest way to do scaling across multiple servers, however,
it's also
the easiest way to shoot yourself in the foot if the message bus goes
down
(process crash, server network isolation, etc).
- I would recommend looking into using more servers with lower load versus
fewer
servers with higher load; This will enable you to scale much better in
short bursts.
(experience tells me that generally you'll find that your application or
service will
have peaks and troughs in usage, generally these match up well if the
three main
timezone blocks (US, GMT, and East Asian / Oceanic)
Those points aside, getting above 100K concurrent users tends to be incredibly
hard,
some of the largest apps around that I've seen have only just been pushing 250K
(we're
talking like big service providers that have 500K -> 2M users, I can't name
them due
to legal reasons).
As for storage of data, you will most likely need both realtime communication
between
servers as well as some sort of key/value store for things like presence
information and
authentication tokens. For the storage of data, I would actually recommend
redis, it tends
to scale out really well for master / slave type stuff. As for message
communication, I'm
beginning to think that pull-based may be better than push based, so something
like
Apache Kafka (not that I've had personal experience with it.)
You will most likely want to also define a transport protocol on top of your
connection,
dependent on your type of application, there aren't many resources on doing
this, but
if you want help with that, give me a shout, I've done a lot of research into
that area over
the last two years.
Alternatively, you could look at third party services for scaling your realtime
architecture.
At present, given the information I have on various services, I would be
inclined to
recommend PubNub (http://pubnub.com), they appear to have a very high quality
setup.
(disclaimer, I did work for a competitor in the past, but that does not bias my
choice,
another option is Pusher (http://pusher.com), or for more, you can look here:
http://www.leggetter.co.uk/real-time-web-technologies-guide )
Hopefully this gives some useful information or things to think about. Scaling
realtime
architecture is kind of hard (not impossible, but can be a pain in the ass).
Regards,
Micheil Smith
--
BrandedCode.com
On 06/05/2012, at 4:26 PM, jason.桂林 wrote:
> Thanks Roly, it's very useful for single machine app.
>
> I have a real app question. If we have millions of online user, how to
> computer system capacity, and how to design a architecture to fit the
> capacity?
>
>
>
> 2012/5/6 Roly Fentanes <roly...@gmail.com>
> https://github.com/fent/socket.io-clusterhub
>
>
> On Sunday, May 6, 2012 4:04:30 AM UTC-7, Jason.桂林(Gui Lin) wrote:
> I just join hackthon party, our team made a very cool chat web application in
> 24 hours.
>
> But I know, it is a demo, It use socket.io, redis, I think it is a little
> expensive on session. and it can't communicate with processes it make it
> cluster.
>
> What nodejs could be use to? frontend server? core internal server?
>
> Some body said ZMQ is very fast message queue, is it help with this case?
>
>
>
> --
> Best regards,
>
> 桂林 (Gui Lin)
>
> guileen@twitter
> 桂林-V@weibo
> guileen@github
>
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
>
> --
> Best regards,
>
> 桂林 (Gui Lin)
>
> guileen@twitter
> 桂林-V@weibo
> guileen@github
>
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
