So I’ve had to make fairly big changes over the last day or so to the MSG block to reduce the amount of communication between the Moodle and MSG servers. The way I’ve got around this is to create a database table for the MSG block to cache users presence for a minute or so and only to update the presence when the cache has expired. The obvious downside of this is that user’s presence doesn’t appear quite so ‘live’ on the browser page. There’s also a kind of natural limit to how long the cache should be set to – as if it’s too long it defeats the point of having the live updates via AJAX and the presences only refreshed when the whole page is refreshed (and no AJAX). At the moment I have the cache set to 1 minute, which seems ok for now, but we may have to make this even longer if performance drops again.

I would have preferred to have kept this cache in memory rather than database table (which keeps needing to be read and updated), but apparently this is a bit tricky to do in PHP – see the posting I made on the Moodle forums at: http://moodle.org/mod/forum/discuss.php?d=54994

We’ve found that if the content-length is set in the returned XML (back to the AJAX in MSG block) then this prevents too many open connections building up on the browsing PC. Though I seem to be having problems setting the content length in PHP – if I do (eg):

header(“Content-Length: 100″);

then this just seems to be ignored (even if I send no other headers) – so I’m a bit confused as to what’s going on here. PHP appears to randomly decide whether a response is going to have a content-length or it’s going to have a ‘chunked’ transfer-encoding….

Also would like to arrange some time over the next couple of weeks when we can properly load test the the MSG Block (and MSG itself) and see how it’ll cope (or not!).