Hi All,
I just started experimenting with Moodle in my computer lab. But I hit a snag especially when Messaging is enabled. So here is my idea to resolve it.
What would happen if I installed Moodle on all student workstations but setup only the MySQL database on the server? I want to set up the workstations such that when the moodle Icon is clicked, it starts moodle on the local machine but maps the database connection to the fixed IP of the server.
I am just thinking.. I would greatly appreciate any feedback from anyone who has attempted something like this.
-Ruwan Jayasinghe
Roosevelt HS, Los Angeles CA
OK, I haven't tried anything like that. It is an interesting approach though.
First a fundamental question: What is the "snag" which you are going to elimiinate? The messaging thing?
If that is the reason, I would install any one of the dozens of the IRC servers available free, rather than upsetting Moodle, which is meant to do _much_ more.
Secondly, for the messaging to be of any use, all clients should connect to _one_ server!
That said, the experiment which you suggest is feasiblie IMHO under one condition: the socalled $MOODLEDATA directory, where Moodle puts all the uploaded files, must be common to and writable by all the web servers. Theoritically you can do that using NFS, but I guess the write-access will keep you busy for some time
First a fundamental question: What is the "snag" which you are going to elimiinate? The messaging thing?
If that is the reason, I would install any one of the dozens of the IRC servers available free, rather than upsetting Moodle, which is meant to do _much_ more.
Secondly, for the messaging to be of any use, all clients should connect to _one_ server!
That said, the experiment which you suggest is feasiblie IMHO under one condition: the socalled $MOODLEDATA directory, where Moodle puts all the uploaded files, must be common to and writable by all the web servers. Theoritically you can do that using NFS, but I guess the write-access will keep you busy for some time
Yes, I was thinking of the implications of many concurrent connections to $moodledata.. I guess giving a special status to files that need to be edited by many people could be a solution. Or conversly making files explicitly "unavailable"(greyed-out) while locked for use by one process(or user). But are there many files in $moodledata that have this problem? I dont know enough PHP to do this but will look into it shortly.
The reason I thought of this idea for heavy use in a computer lab is that with Dual processor WSs w/Gigs of ram and still having to deal with a slow updates was just too much.
The messaging thing is a big hit with my 9th graders. I definitely want to keep messaging, but thought that we could cut out the processor overload problem by distributing that to the student workstations. Hmm.. seems like this is leading to a Java Applet type solution..
hi Ruwan,
Mate I fear that you may be heading down the wrong track here...
The reason that messaging (and anything else in Moodle) generates a big hit on the server is a feature of web applications generally. You're talking about trying to defer processing to the clients... when the clients don't really need to do any processing. By their nature, systems like Moodle are about negotiating a shared environment (shared learning, shared resources etc)... and the client (i.e. the browser) has little to do. Changes such as the growing use of AJAX are helping to overcome this to some degree, but even this will be limited largely to presentation and asynchronous communication.
Even an applet-based messaging solution is (as Visvanath has pointed out) going to be reliant on a server. Usually the reason behind using client apps like applets is some combination of (a) needing a richer, more dynamic client and (b) getting away from the connectionless nature of http.
If (as you say) you're running a dual proc machine with "gigs of ram"... it sounds to me like a better use of your time would be to trawl through this forum and get busy with some performance tuning, rather than trying to change the fundamental architecture of moodle.
Hope this helps you with your thinking,
Myles C.
Mate I fear that you may be heading down the wrong track here...
The reason that messaging (and anything else in Moodle) generates a big hit on the server is a feature of web applications generally. You're talking about trying to defer processing to the clients... when the clients don't really need to do any processing. By their nature, systems like Moodle are about negotiating a shared environment (shared learning, shared resources etc)... and the client (i.e. the browser) has little to do. Changes such as the growing use of AJAX are helping to overcome this to some degree, but even this will be limited largely to presentation and asynchronous communication.
Even an applet-based messaging solution is (as Visvanath has pointed out) going to be reliant on a server. Usually the reason behind using client apps like applets is some combination of (a) needing a richer, more dynamic client and (b) getting away from the connectionless nature of http.
If (as you say) you're running a dual proc machine with "gigs of ram"... it sounds to me like a better use of your time would be to trawl through this forum and get busy with some performance tuning, rather than trying to change the fundamental architecture of moodle.
Hope this helps you with your thinking,
Myles C.
Hi Myles
I wouldn't say "wrong", just an unconventional approach.
We both agree that, if the messaging is very important and is killing the Moodle server, to find an alternative solution - for messaging of course!
Yes the second point is somewhat dubious: Why a machine as you say cannot handle a single classroom? What powers that machine? How do these 9th graders ground that machine?
Ruwan, BTW, your name sounds familier to me
I wouldn't say "wrong", just an unconventional approach.
We both agree that, if the messaging is very important and is killing the Moodle server, to find an alternative solution - for messaging of course!
Yes the second point is somewhat dubious: Why a machine as you say cannot handle a single classroom? What powers that machine? How do these 9th graders ground that machine?
Ruwan, BTW, your name sounds familier to me
The machine is a Gateway 955 Xeon 1.7Ghz, 3Gigs of Ram. I think it maxes out at about 25 concurrent. In one class I have about 35 and it slows to a crawl.
In this room I have rather new, 2G RAM, DualProcessor workstations. So what I wanted to do was to do a share-nothing but rsynced moodle and a replicated mysql on all the workstations behind a load balancer (like Hercules). This is not a lot of work since we have Altiris to manage images on workstations. The workstations just need to run all the time..
Like this..
Myles.. Thanks.. In any case I will try the performance tune-ups first.
In this room I have rather new, 2G RAM, DualProcessor workstations. So what I wanted to do was to do a share-nothing but rsynced moodle and a replicated mysql on all the workstations behind a load balancer (like Hercules). This is not a lot of work since we have Altiris to manage images on workstations. The workstations just need to run all the time..
Like this..
Myles.. Thanks.. In any case I will try the performance tune-ups first.