Skip to content
  • martinlanghoff's avatar
    930413b1
    mod/chat: Normal method - introducing "Stream" updates. · 930413b1
    martinlanghoff authored
    This is an alternative version of jsupdate.php that acts
    as a long-running daemon. It will feed/stall/feed JS updates
    to the client. From the module configuration select "Stream"
    updates.
    
    The client connection is not forever though. Once we reach
    CHAT_MAX_CLIENT_UPDATES (currently 1000), it will force
    the client to re-fetch it.
    
    This buys us all the benefits that chatd has, minus the setup,
    as we are using apache to do the daemon handling.
    
    Chat still defaults to the normal update method, which is now
    optimised to take advantage of keepalives -- so this change is
    safe. The instructions in the config page also indicate that this
    mode may not be well supported everywhere. It hasn't been
    tested on IIS for starters.
    
    In terms of relative cost -- if each hit on jsupdate.php incurs
    on ~20 db queries and delivers one update to the client, each hit
    on jsupdate takes ~20 queries, and then roughly 2~3 queries to
    serve each of the next 1000 updates. On busy sites, the difference
    is huge.
    
    There is still room for enhancements in both keepalive and stream
    update methods. I am pretty sure we can trim DB queries more.
    930413b1
    mod/chat: Normal method - introducing "Stream" updates.
    martinlanghoff authored
    This is an alternative version of jsupdate.php that acts
    as a long-running daemon. It will feed/stall/feed JS updates
    to the client. From the module configuration select "Stream"
    updates.
    
    The client connection is not forever though. Once we reach
    CHAT_MAX_CLIENT_UPDATES (currently 1000), it will force
    the client to re-fetch it.
    
    This buys us all the benefits that chatd has, minus the setup,
    as we are using apache to do the daemon handling.
    
    Chat still defaults to the normal update method, which is now
    optimised to take advantage of keepalives -- so this change is
    safe. The instructions in the config page also indicate that this
    mode may not be well supported everywhere. It hasn't been
    tested on IIS for starters.
    
    In terms of relative cost -- if each hit on jsupdate.php incurs
    on ~20 db queries and delivers one update to the client, each hit
    on jsupdate takes ~20 queries, and then roughly 2~3 queries to
    serve each of the next 1000 updates. On busy sites, the difference
    is huge.
    
    There is still room for enhancements in both keepalive and stream
    update methods. I am pretty sure we can trim DB queries more.
Loading