mrverrall

As an advocate of upgrading; here is a list of the 50 current known security vulnerabilities for Moodle 2.5.6... https://web.nvd.nist.gov/view/vuln/search-results?adv_search=true&cves=on&cpe_version=cpe:/a:moodle:moodle:2.5.6

For me GIT makes things much easier and basically combines your steps 2-5 into one. It generally makes moodle upgrading faster and more robust, the only barrier is learning GIT I suppose.

Hi, just edit your new url to the form, co.uk/?csid= That is, add a forward slash between the domain and the GET params (the '?' and what is after it) Cheers, Paul

[citation needed] Specifically, https://tools.ietf.org/html/rfc1034#section-3.6.2 and clarification at https://tools.ietf.org/html/rfc1912#section-2.4

Hi RabbieBurn, I've just cleared out some prior responses to keep things neat and clear here. What you ask id entirely possible. All you need to do is *uncheck* the following option, Site administration / Plugins / Activity modules / Forum / Use email address in reply The confusion (for me too) comes when this is checked so as to use users real email addresses, but is then overridden by a users preference to keep their email address private at user level. Cheers, Paul

I'm surprised anyone is using Moodle 1.9.11+ !!! Hope you get it sorted.

To the best of my knowledge it should apply to any HTTPD as it is PHP setting the cache-control header and the users browser acting on it, IIS is just the piggy in the middle.

Fixed

Unfortunately that information is WILDLY out of date! HTTPS/SSL caching was addressed in Moodle 2.3, specifically https://tracker.moodle.org/browse/MDL-32683 Regarding SSL client caching some interesting background information to he found here, https://blog.httpwatch.com/2009/01/15/https-performance-tuning/ specifically 'Tip #3'. Basically you are fine if you have a modern browser (Better than Firefox 3 or IE6) and a Moodle version above 2.2 I'll see what I can do about getting those pesky moodle docs updated.

I don't think this is true. You'll get a sight overhead for the actual encryption, but both client and httpd should continue to cache just the same as always.

Yeah, I agree for sure usage patterns will be different. In the context of system resources what I think we really care about is how many users are likely to be clicking stuff at any one time and I think it is safe to say in either usage context that this is actually going to be much much lower than the total users logged in at any one time. Here we graph not only the users logged in, but more importantly the number with near 'lastaccess' times in the user table. The latter is much more informative when you are deciding what resources to throw at your system. Interestingly what I have tended to find when inheriting the maintenance of schools existing moodles is once I start graphing their system resources it's fairly apparent that at some point they have decided to throw lots of RAM at the server without actually configuring anything to use it, the moral of the story being to understand your systems real resource usage and take care it it's configuration. RAM is great, but worthless if unused Sorry to take us off topic

I think people wildly over estimate their concurrency. The largest setup I'm involved with is too complex to define in terms of the 4 criteria listed here, but I can give some statistics regarding concurrency, Over the last Month we saw ~14k unique users log in. Over the last 24 hours 8k unique user logins. In terms of concurrency, defined as users with activity within 5 mins of each other, our absolute max is just below 300 users. I just thought that might be interesting.

Not related to performance, but you say you are running Moodle 2.7.3+ The current 2.7 branch release is 2.7.5 and included a critical security fix whereby access to system files could be gained, e.g. config files or moodle user uploads assignments etc. See https://moodle.org/mod/forum/discuss.php?d=279956 for details. I'd suggest you patch up asap if you plan on putting this into production use! Cheers, Paul

I would start by looking at the 'More' theme that is already built into Moodle and then using the Custom CSS options in-site to further customise as you can get some good mileage here (I'm assuming as you are looking at theming yourself you know your way around CSS). This is especially useful if you are just looking to bring Moodle on-theme rather than overhaul the entire thing. Moodle themes also work on a hierarchy system, so if you find a base you like you can easily extent it to suit you needs with minimal development.

For the php.ini it would be the memory_limit value. However on reflection this would not be an issues unless you have actually run into actual errors so you can probably leave this alone. One value you should definitely change though is the 'realpath_cache_size' as this will help with php's handling of the large number of files included in moodle. A value of 1M should be plenty (the default I think is only 16K). The big win for PHP will be in implementing the Opcache. I use APC and as Moodle is quiet large I find I need an apc.shm_size of ~410M to contain it comfortably. This gets pre allocated as a block of memory regardless of if it's used and so won't be available to other applications. You will want to keep this value as just-enough to stop the cache filling and purging (which it will do when it gets full). As for MySQL I'm not going to be much help as I tend to use PostgreSQL where I have a choice. When I do have to work with MySQL I use a tool like MySQLTuner-perl by major to guide me; unfortunately that tool is Linux only but you might be able to find an equivalent for Windows if you do some Googling. One principal that is sure to apply though is that it's not going to be as simple as telling it to 'use all the ram' and you almost certainly won't want it to. It's generally best to set up your daemons to use just enough ram to get their job done efficiently and will not be a one size fits all (unfortunately). Something else I forgot to mention is to check that your HTTPD (Apache, ISS or whatever you are using) is handling your connections efficiently, You want to be able to accepts enough connections and to be able to folk enough php workers to accommodate them, otherwise it may be queueing requests.