0

we want to enter push technology, and our use case is as following:

  • huge number of simultanous clients (several 100.000s)
  • low message rate (~ 1 every minute)
  • small data (<500 bytes/message)
  • latency under 2 seconds

now we have two competing solutions:

  1. we could build up a real websocket/longpolling server-cluster (we will evaluate atmosphere, playframework and socket.io on node or vert.x); this would result in several 100.000 sockets being alive at the same time, nearly all of them idling around (except 25% IE constantly reestablishing a long polling connection);

  2. we could just use static json files behind caching webservers (invalidatable) as the endpoint for classical polling; this would result in several 100.000 requests/second from the browsers, nearly all of them being answered with a result code of 304.

which solution would you propose? especially in terms of resource consumption: cpu, memory, traffic, io?

fujan
  • 13
  • 2
  • Can't say which one is better in terms of resources but I'd choose the first. I've realized the first solution using Vert.x (1.3.1) and our stress-test result were very good (after I convinced my company to remove apache as-a-proxy for vert.x). Sorry did it more than 8 months ago and didn't go in production so I can't provide numbers -- just give vert.x a chance. HTH – Carlo Bertuccini Jun 03 '13 at 18:23

1 Answers1

0

we used a very simple approach for this:

the browsers do periodic ajax polls to a static file, that is distributed via akamai. so we have very few requests really hitting our backend. the caching time of the file is set to 5 secs and so is the poll interval.

its not elegant, its not realtime, but it works for our usecase.

bennob
  • 1