0

I am reading on various ways of doing server push to client side(broswer).I would like to understand the best approach out of these.

  1. Long polling -- To be avoided as it holds up resources longer on server side.
  2. Node JS async delegation using callbacks.--cons that it is single threaded.
  3. Write callbacks in java , use threads to do task in background and later use callback to push it to server like node.js does.

The advantage here is that we will have multiple threads running in parallel and utilizing CPU efficiently.

Can anyone suggest the best way of implementation? Any other way is also appreciated.

Michael Petrotta
  • 59,888
  • 27
  • 145
  • 179
user2203937
  • 181
  • 1
  • 8

1 Answers1

0

You seem to misunderstand few things. You cannot compare for example long polling to the server side technology.

Long polling means that the client (i.e. browser) makes an AJAX request to the server. Then the server keeps that request alive until there is a notification. Then it responds to that request and the client after receiveing the update immediatly calls the server with new AJAX request.

You can chose whatever technology you want to handle that on the server side. People made NodeJS with this on they're mind and thus I would recommend using it for that. But use whatever suits you better.

Now another misunderstanding is that threads increase performance and thus they are better then single threaded applications. Actually the opposite is true: with threads the performance gets worse (here I assume that we are working on one core CPU). Threads increase responsivness, but not performance. There is however a problem (with single threaded apps) that if a thing you're trying to do is CPU intensive, then it will block your server. However if you are talking about simple notifications, then that's not an issue at all (you don't need CPU power for that). SIDE NOTE: You can fire as many instances of NodeJS as you have cores to take advantage of multiple cores (you will need a bit more complex code, though).

Also you should consider using WebSockets (thus implementing a simple TCP server on the server side). Long polling is inefficient and most modern browsers do support WebSockets (in particular IE10+ as it was always an issue with IE).

Concluding: on the server side use the technology you're most familiar with.

freakish
  • 54,167
  • 9
  • 132
  • 169
  • Thanks for the answer.With threads, we do optimal utilization of CPU and my server would be deployed on multi-core CPU.I am intrigued with your comment that Threads do not improve performance but still make the system more responsive.Responsiveness is only related to good performance.Yes, we need to see as to how many threads the system should spawn for optimal performance as more number of threads would also mean more time for job scheduling by OS.But i am sure that if we have optimal number of threads, the system would respond faster. – user2203937 Apr 08 '13 at 04:27
  • Also,Why should we use - Node.js async JS delegation model with single process,when we can spawn threads in Java(or any other language) to do work in background and later when done, give response via callback.With server side technology, we have better control on spawning threads and making system more responsive.Why is node.js given so much of importance? – user2203937 Apr 08 '13 at 04:33
  • @user2203937 Because event loop is more efficient then threads. You can handle tens of thousands of simultaneous connections with it. It is a bit difficult to do that with threads. – freakish Apr 08 '13 at 06:10
  • I didnt get it why?I can have thread pools created at server startup which can be assigned tasks later so that there is no overhead of thread creation ? – user2203937 Apr 08 '13 at 08:30
  • @user2203937 Thread pool? The question is: how will you listen on a socket? You either do: one thread per socket (i.e. true multithreaded server) which is inefficient (although a lot easier to implement) **or** you use a nonblocking architecture in a single thread (i.e. an event loop). Well you can mix these two architectures which is pretty much the same as firing multiple instances of NodeJS. But I guess that if you are not expecting tens of thousands of simultaneous connections then you can easily go with threads. – freakish Apr 08 '13 at 08:39
  • Also have a look at this: http://stackoverflow.com/questions/953428/event-loop-vs-multithread-blocking-io – freakish Apr 08 '13 at 08:41
  • @freakish--I am expecting around 50000 simultaneous connections. – user2203937 Apr 08 '13 at 09:51
  • @user2203937 Uh, that's a lot. I don't think that one machine can even handle it. You will have to scale it to multiple machines anyway. – freakish Apr 08 '13 at 10:31
  • @freakish.. Sorry to bug you a lot.I am just a java guy and hardly dabbled ever with JS frameworks.I talked about thread pools so that we have already created thread before hand and yes as suggested by you .. it would be non-blocking architecture as i have thought of using java nio for socket connectivity which doesnt block any thread.I was exploring nod.js but i dont see any positives here compared to what java already provides. – user2203937 Apr 08 '13 at 13:07
  • @user2203937 It's not that NodeJS is the best thing in the world. So yeah, go for it. Whatever suits you better. – freakish Apr 08 '13 at 13:09