In terms of web applications (and by extension Rails applications), real time is just an illusion. Long polling is a very close approximation. Unfortunately it's not well suited to Rails. Even less so on Passenger.
Long polling requires a persistent open connection for each user, which doesn't scale very on servers that weren't designed to handle it (such as Apache). Unfortunately there really many servers designed for long polling scalability that play well with Rails. You could try the Shooting-Star server, but I really have no idea how its performance compares to Passenger, for your standard requests.
My personal opinion of long polling is it's a solution in need of a problem.
Really you should be asking yourself the following questions:
- Are these updates of a high enough priority that they cannot wait 40 seconds?
- What will happen if updates are not received immediately?
- Are my users going to so focused on my application that waiting 15 seconds is going to impact their experience negatively?
- What percentage of a user's attention does my application attract under normal use?
- How long does it take to respond to an update?
- Does it really need to be real time?
A few of those questions are asking other questions in a different way, but that's kind of necessary with such subjective questions.
I think you see what I'm getting at: Real time updates are very nice to have, but never really necessary. If you are working on something where the consequence of failing to react to a real time update is the end of the world. You really should not be developing it as a web application at all.
If you've still got your mind on Real Time updates you can look into Juggernaut. But that's a Flash based solution.