Archive for September 2006

getElementsByName…

Found that we had a bug where the presences weren’t being updated in IE but they were in Firefox (which I usually use) – tracked the problem down to the differences in how these browsers deal with the document.getElementsByName – I was using the name element on a span tag which Firefox ‘recognises’ but IE doesn’t, for more info on this: http://jszen.blogspot.com/2004/07/whats-in-name.html.

Anyway, turned out to be easy enough to fix by just putting the name on the img tag rather than span.

Scaling

Had a bit of a nightmare the last couple of days! When we moved the MSG Block over to the ‘live’ server, we started to find that things weren’t working very well – the Moodle site was incredibly slow, this obviously(!) turned out to be a problem with the MSG block slowing things down with the number of requests being made keeping peoples presence status up to date. And this was with relatively few users…

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

KeepAlive

Eventually tracked down the issue with the headers – they were being automatically set by Apache and had been set to have KeepAlive off (apparently that’s the default for Apache on RedHat, but default for Apache generally is KeepAlive on). Once we’d set this up correctly there aren’t loads of open connections left open on the server (the same connection is used for multiple requests), the performance has significantly improved.

The other area I’m looking at too try and speed things up is to replace the proxy library that I’m using which downloads the data from the MSG server. I’m currently using fsockopen and fread to download the data, but I’m looking to replace this with cURL – which is apparently much quicker….

Improving performance

Spent the last couple of days trying to improve the performance of the MSG Moodle block – seems to be going ok, though some of the things I’ve tried actually make things worse (when they ought to improve!) so spent a bit of time going back and forwards with the code base!

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!).

Website moved!

I’ve just moved my website over to the server here in KMi, so the url has changed – but redirects from the old site are all in place. Was fairly easy to get everything moved acrosss – though my old site was running ColdFusion and MS SQL and this new site is on WordPress (so it’s MySQL and PHP) so I’ve had to rewrite parts, eg the photo pages as I couldn’t find a WordPress photo plugin that did exactly what I wanted!

Tuesday 12 September 06

Found that for now we can just carry on using the ‘old’ Moodle 1.6 functions for roles and permissions and we’ll update to the new 1.7 functionality later in October.
Chris and I are getting very close to having the Jabber server properly connected up to Moodle – still a few more things to do, like checking that the Jabber server can log a user in based on being passed the Moodle cookies. Had a bit of a nightmare yesterday when I tried to connect my Moodle up to Chris’s desktop PC, and I updated the blocks setting, unfortunately the firewall (or something) was blocking the connection between my dev Moodle and Chris’s PC – the resulted in my Moodle site just hanging. I couldn’t go back and edit the setting (because the site was hanging). Eventually got this fixed by commenting out the code which tries to connect, which then allowed me to edit the block setting. I had hoped to just be able edit the settings in the Moodle database, but I couldn’t find where the global settings are stored for a block – though I could find where they are stored for a block instance.

I then tried to implement the stream_set_timeout() function (to stop this happening in the future) – so that fsockopen didn’t just hang the server, but I couldn’t get it to work correctly. I could really do with getting this working so that we can return a decent error message if the Jabber server isn’t available for some reason (but Moodle is still running).

I’m also going to implement some security on the group and user services provided so that the results will only be returned if they have originated from one of the given IP addresses.

Wednesday 6 September 06

Now have my demo server updated to use the current version of the OU VLE Moodle with the LabSpace theme applied. Still getting very confused about the new roles and permissions, I’ve set up the db/access.php page as it looks like it ought to be set up – then I update the version number and run the admin page, but my new capabilities aren’t imported into the database – I can’t quite work out what’s going wrong here. few other queries I have about the new roles are permissions are:

  • docs say that the capability should start with the path to the block or mod, but then the example given is block/… which of course ought to be blocks/… if it’s the path
  • The get_context_instance() is passed an id as the second parameter, and I’ve seen a few examples which all use the instance id but I can’t work out how this should be applied to my block – which would usually be a sticky block so each block won’t have an instance id to use? The examples all seem to be something like:
$context = get_context_instance(CONTEXT_MODULE, $cm->id);
But I don’t know where $cm->id would come from in my case?
  • For user enrolments on courses – how can I figure out if a user is enrolled on a course without using mdl_user_students? I can see the mdl_role_assignments so I assume it’s something to do with this, but I’d need to know what the ‘student’ role was actually called to be able to query reliably – wouldn’t want to have the role id or role name from mdl_role hard coded into my php?

Anyway, for now I’m just going to leave my code using the old Moodle 1.6 functions/tables as I know these will still work with Moodle 1.7 (just deprecated) until I find someone who can help me sort it out!

Friday 1 September 06

Trying to get my head a bit more around the changes to the roles and permissions in Moodle 1.7. Was getting a little confused about how to test whether a user is a guest or not, but think I’ve got it figured out now – well maybe – will have to check next week once I get the OU VLE version of Moodle 1.7 installed to play about with.

I think what I need to do is create 2 capabilities:

block/msg:view – this would determine whether someone had access to view the block, so we could have this turned off by guests
block/msg:chat – this would determine whether someone had access to the MSG client. By default this would be turned on for all identified users (i.e. not guests), but would give us the ability to block users if necessary.