0

I want to setup a comet/web-socket server for a forum sitting in front of a message queue i.e. rabbitmq, that will maintain client connections and update them about relevant events (i.e. new posts, topics, etc.)

The popular way to go about this is to use some async server that does this in one thread and hands off the blocking tasks to other worker threads. My question is, should this async update-server be on the same physical server as the website? In other words, the task of maintaining client connections and updating them as needed should be separated from the task of creating and returning dynamic web-pages right? Should they be on the same server or separated completely?

The criteria for evaluating the decision is performance and ease of scalability.

Also, this question isn't about what specific platforms to use. I'm asking about the general practice of seperating concerns: Serving dynamic webpages vs updates; when is it best to place them together and when is it best to seperate them? (physically on the server as well as in code base)

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
goldenarms
  • 9
  • 2
  • 2
    What criteria are you evaluating for making the decision? Number of simultaneous users? Ease of deployment? Or something else? – Robert Harvey Dec 08 '14 at 17:52
  • @RobertHarvey right, sorry for not clarifying; I made the appropriate edits. – goldenarms Dec 08 '14 at 18:02
  • How much load do you have? Is it enough to justify two machines? – Robert Harvey Dec 08 '14 at 18:26
  • @RobertHarvey I havent even deployed yet. Im just asking in context of general practice. – goldenarms Dec 08 '14 at 19:37
  • 1
    Then put it on one machine and divide the load later if and when it ever becomes a problem. – Robert Harvey Dec 08 '14 at 19:43
  • 1
    Multiple machines isn't about separation of concerns; it's about load distribution. Separation of concerns is a software design concept; done correctly, it can make the process of load distribution easier. – Robert Harvey Dec 08 '14 at 19:46
  • @RobertHarvey Yes, I'm well aware of what separation of concerns refers to. I am asking this question in _both_ senses --thats why in the edit, i mentioned "physically on the server as well as in code base". I guess I could have phrased it better. Anyway, thank you for your answers, you've been very helpful. I will put everything on one server first and separate both servers if it makes sense to do so. If you post this as an official answer I will accept it. I wonder though, in high traffic situations if having them on one server is still done in some sitiuations? – goldenarms Dec 08 '14 at 21:43
  • Sure it is, but there's really no reliable way to know ahead of time what the cut-over point is (except perhaps load testing, which you should probably do anyway), and the cutover point is almost certainly higher than whatever traffic you have now, unless you're replacing some really high-traffic site with a new one. – Robert Harvey Dec 08 '14 at 21:51

2 Answers2

1

You could use NodeJS and the node package module Socket.io for this. Separating the tasks of client connections and creating/returning dynamic web pages into node modules could work the way you described. Node describes their modules in their API docs.

The book NodeJS in Action has some projects that perform similar functionality (even the basic ChatApp in Chapter two performs this to some degree.

jbellison
  • 19
  • 1
  • Also, Node.js is all async non-blocking I/O. Sockets.io is also the most widely used web sockets module by the Node community, and has tons of good documentation and starter code. – Chris Cirefice Dec 08 '14 at 18:24
  • Thanks for the reply; but as for specific technology, I've narrowed it down to java nio libraries or Twisted. Anyway, this question isn't about specific technology but rather general practice: separating serving dynamic pages and updates vs placing them together. When is it best to do each? – goldenarms Dec 08 '14 at 19:42
-2

I use https://github.com/centrifugal/centrifuge, it is a standalone application that uses websockets and falls back to long polling if that fails. Unlike centrifuge, I had lots of issues with comet with high volumes, it did not scale well for various reasons.

Centrifuge even has a dockerfile so you could literally spin up the server on a server in a few seconds. Your web front end requires a tiny bit of javascript and server side is also really simple to push messages to

Clinton Bosch
  • 754
  • 6
  • 9
  • 1
    Why are people offering product suggestions when the OP didn't ask for them? – Robert Harvey Dec 08 '14 at 19:44
  • My point was that in my experience this is a VERY scalable solution, it can reside on the same server or separate server ... makes little difference and can easily be moved if you change your mind, you are not bound by your initial decision – Clinton Bosch Dec 08 '14 at 19:46
  • I suppose you should have said that in your answer. Is your point still valid if you're *not using Centrifuge?* – Robert Harvey Dec 08 '14 at 19:49
  • I am not sure I understand your question. As I said, I found comet to be very un-scalable due to the fact that it uses suspended requests, your application server can only handle so many concurrent requests and if each browser is hogging a request, then you can see the limitation here. I am not sure how many solutions there are now that can solve the problem as easily as centrifuge does, certainly when I did the research a year ao there wasn't much – Clinton Bosch Dec 08 '14 at 19:55
  • The most important part and most relevant to this question is that it doesn't matter whether you host it on the same server or a separate one, you can easily change your mind and move it in a matter of minutes – Clinton Bosch Dec 08 '14 at 19:57