mrverrall

This is such a massive topic it is really hard to know where to begin. Firstly take a look at your MySql config and configure it to make good use of the RAM you have available. There is no point in having lots of RAM if nothing is configured to use it. Secondly take a look at using an PHP opcode cache, such as xcache or php apc. Without one you are basically having to compile each pages code every time you load it. Again configure the cache to use the RAM you have available. From the Moodle config side make sure you have theme designer mode turned off and Javascipt caching turned on. Lastly think about some real hardware if you are going to be running a production system. On a laptop with one piddly hard disk you are going to have a crap-tonne of IO contention between the DB and other service for disk access as soon as you have even a handful of users on it. Get some suitable hardware and set it up well. Some people will probably suggest running on a Linux OS, and they may have a good point. However if you are going to be running and maintaining this systems stick to the OS you are most comfortable with. There is a heap of helpful posts on the moodle.org forums also, that is your best source of advice on moodle in general. Oh, and one more thing. If none of this makes any sense think about getting a professionally hosted Moodle and make tuning it someone else's problem. Hope that helps somewhat.

Quite right, It can also help to turn on Javascipt caching too (cachejs).

It's important to understand how your teachers use moodle. For example do teachers generate content while in school or do they do the bulk of their vle work from home. If it's the latter then a hosted solution will probably end up actually being quicker. This is also an important port for you pupil experience, a hosted solution will almost certainly be quicker as it should be hosted in a datacentre with a decent backbone (e.g. 1Gbps here). At LUNS we ran a LA hosted moodle solutions for ~1000 schools (~250k users) and the upstream bandwidth (content bringing pushed to us) rarely exceeded 10M so I don't think your bandwidth is an issue in that regards. There are plenty of companies out there who can provider a hosted moodle solution. At LUNS our packages are based on the number of learners.

Well that is me stumped then! You could always move to a hosted solution ;o)

Hi mansin, To give any really helpful feedback we'll need the answers to Pete questions above. However if I was to take a best guess I'd suggest that the new server has not been tuned correctly for the resources available, namely the database and any PHP accelerator you may be using. You'll find that linux packages (if indeed you are running linux) come with configs designed to work with any hardware. At LUNS we use Debian with PostgreSQL databases and Apache2 with php-apc for caching. The package defaults in Debian are hopeless for the sort of hardware spec we run and so need some modification. I've cherry picked a few posts by one of our Devs on the moodle.org forums which may be helpful, other that that we'll need to wait and find out what your set up is ) It would also be good to know what your server resources are up to, i.e. are you CPU, I/O (disk) or network bound? Check these out... Using Moodle: moodle system going down/getting stuck very often Using Moodle: Number of concurrent users supported

While Moodle does support subscription from external apps using ical, you can't as yet import calendar data into moodle let alone be able to have that data feed back into a parent app. Mr V

Achandler has the right idea, a mailto directive in your cron job will do the trick nicely. You should also read the docs at Cron - MoodleDocs

Ok, so @sted mentioned openfire, which is also XMPP... Which looks great if Windows is your only server option. Nice one @sted! Also I just found this NanoANT. Which is a Windows server port of jabberd2... Probably worth a look.

My choice would be an XMPP server like those available at jabberd14 or jabberd2 XMPP is the same protocol that Google Talk runs over. Once you have a server running you can you a whole bunch of windows clients (e.g. pidgin) to send messages as well as have group chats. I think this is the only answer so far that addresses all of your requirements, * Internal messaging system * Client similar to Windows Messenger * Popup alerts * Free * Strictly for internal use only

Just a few points spring to mind; * OCFS is for data clusters... not multiple clients, i.e. primary/primary DRBD clusters. For your purpose NFS will be just fine and you can do away with iscsi entirely. * For the DB mysql multi master is just begging for dataloss; I would take a good look at postgres 9 with streaming replication. * As you only have one data-store you've not achieved HA; without this it all seems a bit pointless. * HAProxy will work great, but have you thought about how you'll fail-over the service IP? You'll need something to do VRRP for you. Hope that's helpful! Paul

CLEO Moodle is also only version 1.9 rather than the current 2.0

One more thing! I believe when you traverse the CLEOland proxies you end up getting a number of different source IP's for your traffic depending on the we-cache your traffic hits. I'm told reliably that 4OD cuts you off if your source IP changes during the stream; So another thing to try (in conjunction with the above) is to try using a single web-cache explicitly, although I'm not sure I would recommend this as a permanent solution! There is always the option of looking elsewhere for your internet connection, although I wouldn't dream of recommending anyone specifically!

The problem is that 4OD tries to use RTMPE over port 1935, and if it gets a reject back from a firewall attempts to tunnel the traffic over HTTP. CLEO blackholes traffic on iffy ports, which is a sensible policy. This means however that 4OD never gets it's reject packet (the difference between DROP and REJECT in iptables parlance) and thus never gets around to trying HTTP. It instead just assumes that there isn't a connection, this is really a flaw in 4OD in my opinion. So what's the solution? if you have a local firewall in your control, (i.e. sat before your CLEO edge router), configure it to reject traffic on port 1935. You could even try a 'personal' firewall on the clients being used. WARNING!! This is really just a best guess, and I can't try this for myself... If any one does get around to giving this a shot let us know if it works!