On 2/1/10 11:51 PM, Abhinav Singh wrote: > Hi, > > I am looking to deploy pub sub for a website build to display live > sports scorecard to the users. > At peak traffic, there are about 200K concurrent users. Since the load > is probably too much, I am doubting if pub sub can really be a good > solution here.
The challenge is usually in the implementation, not the protocol. People used to say that XMPP couldn't scale, until Google deployed their Talk service. Now they have the same questions about pubsub, but I think a lot of it will depend on which implementation you use. FWIW, Apple is using Idavoll in their iPhone push notification service, but there are several other implementations of XEP-0060 out there. > Here is an overview of how I am looking to deploy pub sub: > > 1. User visits http://localhost/match-id-23000 > 2. As soon as user loads the match page, he is subscribed to the > match specific node > 3. There can be 1 or more (<5) publishers, who actually are vendors > sitting in remote locations > 4. Vendors publish the live scorecard as and when data is available > with them > 5. Subscribed users gets the live scorecard update in almost real-time > > Here is the technical flow of the same: > > 1. On page load, an ajax is fired subscribing the user for match node > 2. Target url for all ajax requests in a PHP connection manager (say > bosh.class.php) > 3. PHP connection manager parse incoming request params, generated > appropriate xml's as specified in various XEP's and communicate > with the jabber server > 4. PHP conn. manager communicate by curling the jabber server > 5. Jabber server respond back whenever there is new data available > for the subscribers > > Now the scalability doubts which comes to my mind are: > > 1. With PHP connection manager holding every single incoming request > (timeout 60 sec) and waiting for a response from the jabber > server, I assume under 200K concurrent users the web server will > soon stop accepting the incoming ajax requests. That is not a problem with pubsub, that is a problem with PHP. > 2. Also are ejabberd, openfire and the likes capable of handling such > a load. Openfire, probably not. But servers like ejabberd and Tigase and I think Prosody, probably yes. > 3. If yes, how much is the estimated throughput of these jabber > server. (need to access amount of infrastructure required) Talk to the people who develop and deploy those servers. > 4. Overall I think PHP connection manager will be the main bottleneck > here. I completely agree and would counsel you to find a different solution. > So will it be advisable to proxy all incoming ajax requests > directly to the jabber server and put the login between the vendor > and the jabber server. I don't know enough about your application to say. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
