locked
Notifications pollInterval RRS feed

  • Question

  • Hi!
    I've noticed that the shortest pollInterval for notifications is 1 second. One second is a very long time when it comes to computers, maybe the polling interval could be cut down to 1/100 or 1/1000 of a second. So the question is, is this polling interval going to shorter in the final release?

    With regards

    Jan Mukkala

    Monday, April 27, 2009 11:43 AM

Answers

All replies


  • Jan Mukkala,

    Shortening the poll-interval may have some performance implications. We would like to understand your scenario first so that it helps us to decide on the requirement for milliSecond pollInterval.

    Thanks
    Shankar
    Tuesday, April 28, 2009 4:46 AM
  • Hi!

    The main reason for a short poll-inteval as possible, is that the client should get new data with as short delay as possible. It is the possibility to both cache data and that the client could get a notification that there is new data in the cache that woke our interest for velocity.
    If I simplify it, we are running a 3-tier system where the access to the database is very slow. As the database are slow we would like to have the possibility to cache the result in Velocity and then send let Velocity notify the clients that there in new data in the cache, and the notification should therefore be done as soon as possible so that the clients don't experience the system as a slow system.
    We are currently using ASP.NET cache and our own tcp/ip based notification system to solve this tasks, to solve these tasks with Velocity instead would simplify the work for us a lot.
    Maybe there isn't a requirement for millisecond pollInterval. After consulting with my colleagues, we figured out the 1/10 of a second would be sufficient to meet our demands on response time. With a pollInterval of 1/10 of a second the average time for a notification would be 1/20 of a second, and the experience for the user of a slow system would be minimal.
    Maybe there could be an option to have the possibility to have a shorter pollInterval?

    /Jan Mukkala


    Wednesday, April 29, 2009 7:45 AM
  • Thanks for the feedback, we will definitely consider you sugestion for the RTM.
    MSFT
    Wednesday, May 6, 2009 5:12 AM
  • I would also cast my vote for this change.

    Regards
    Ivan Bondy - MCPD, MCDBA, MCSA, MCTS - Sharepoint consultant
    Thursday, May 7, 2009 4:23 PM
  • If you do every 100 miliseconds then you are essentially creating 10 hits a second to the cache servers to just check for timed out objects.  I don't know what the overhead of polling is, but it has to be high.  Something to think about. 
    Friday, May 29, 2009 7:02 PM
  • Instead of polling, can each servers call back to each client's listener to notify changes? Polling seems to be overkilled.
    Wednesday, June 10, 2009 3:34 AM
  • Instead of polling, can each servers call back to each client's listener to notify changes? Polling seems to be overkilled.

    Polling may provide for efficient CPU & network load to replace a database cache.. an efficiency that is critical if you’re going to have to visit the database for cache misses, but polling does not address the caching needs for a Market.  In a market you must avoid publishing a stale price quote when the underlying has changed.

    For quasi-real-time environments I’d like to see the option of a “notification policy” that could trigger direct push of item/region changes from source to proxies concurrently with cache write.. in this scenario the cache provides the subscription list & fall-back polling.. and the cache does not need to deserialise streams on the cache server to check for event routing.

     

    Wednesday, July 1, 2009 4:05 PM
  • Hi!

    The main reason for a short poll-inteval as possible, is that the client should get new data with as short delay as possible. It is the possibility to both cache data and that the client could get a notification that there is new data in the cache that woke our interest for velocity.
    If I simplify it, we are running a 3-tier system where the access to the database is very slow. As the database are slow we would like to have the possibility to cache the result in Velocity and then send let Velocity notify the clients that there in new data in the cache, and the notification should therefore be done as soon as possible so that the clients don't experience the system as a slow system.
    We are currently using ASP.NET cache and our own tcp/ip based notification system to solve this tasks, to solve these tasks with Velocity instead would simplify the work for us a lot.
    Maybe there isn't a requirement for millisecond pollInterval. After consulting with my colleagues, we figured out the 1/10 of a second would be sufficient to meet our demands on response time. With a pollInterval of 1/10 of a second the average time for a notification would be 1/20 of a second, and the experience for the user of a slow system would be minimal.
    Maybe there could be an option to have the possibility to have a shorter pollInterval?

    /Jan Mukkala


    Not sure I understand your issue 100%. You say performance is the issue and you have a slow DB. How do you plan to get velocity updated from the DB. Will this synch always be sub second? If not, the sub second poll interval won't do you any good. The poll interval will only impact how much time between cluster update and local cache update/notification. It will not impact the responsiveness of the client.

    If you want local cache to be 100% in sych with the cluster cache (strong consistency) you can implement your own local cache mechanism. Simply store the version info with each object then go back to the cluster on each access and verify the versions match (use GetIfNewer). This will avoid all the serialization and network overhead with brining all the data back, when the data has not changed in the cluster.

    The velocity team should probably consider this pattern as a built in feature for local synchronization.   

    Wednesday, July 1, 2009 8:48 PM