AWS and EFS page load

AWS and EFS page load

by Raimundo Farrapo -
Number of replies: 3
Hello,
I am testing my Moodle application (3.5.1) on an architecture on AWS.
The architecture built on AWS allows me to create multiple EC2 instances using Aurora DB. That way I can guarantee scalability.
When I use the moodledata directory in EC2 local, the page load time is about 0.1s.
When I use the moodledata on Amazon EFS, the load time increases to 3s or more depending on the page.
I tried using the ElastiCache service with Redis and EFS, but apparently the slowness was higher.

Has anyone had a similar situation? I am trying to set up an architecture that supports at least 1000 students online all day without problems.

I am grateful for the answers, I need to solve that.
Average of ratings: Useful (1)
In reply to Raimundo Farrapo

Re: AWS and EFS page load

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Moving to Hardware and performance forum (and splitting from original discussion that this had nothing to do with)...
Average of ratings: -
In reply to Raimundo Farrapo

Re: AWS and EFS page load

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
This is exactly what I would expect if you moved moodledata to shared storage due to cache latency.

You say you tried Redis. That would have been the first thing I suggested. Are you absolutely *sure* that you configured the MUC properly to use Redis?
Average of ratings: -
In reply to Raimundo Farrapo

Re: AWS and EFS page load

by Michael Spall -
Picture of Core developers Picture of Testers
Raimundo,

We have a fairly busy Moodle site in AWS and have had success with it. We tested EFS when it was in preview mode and at that time it wan't a good choice for Moodle caching. Instead we use Gluster for file caching. We also use Gluster for Moodle's dataroot, $CFG->dataroot. We have not re-evaluated EFS recently so it's performance could have changed, but I have seen other comments that EFS doesn't work well with large numbers of small files changing a lot.

Moodle Caching on our site is set up this way:
1. We have Redis installed on an EC2 instance with start up scripts set up so that, per Moodle instance, there are two separate Redis databases listening on two different ports. This is a recommended practice described in the Redis documentation.
A. Sessions are in one Redis DB. Something like this should be in your config.php:
$CFG->session_handler_class = '\core\session\redis';
$CFG->session_redis_host = 'redis.server.ip';
$CFG->session_redis_port = 6379; // Defaults to 6379
B. Application Cache is on the second Redis DB. This is set up using the Moodle Admin interface. Make sure to use the second port.
2. We have the three different types of MUC file caching broken up into three different directories.
A. $CFG->tempdir needs to be shared so $CFG->tempdir = 'path on Gluster/temp'
B. $CFG->cachedir also needs to be shared so $CFG->cachedir = 'path on Gluster/cache'
C. $CFG->localcachedir can be local so $CFG->localcachedir = 'path on the local machine that is consistent between all web servers/localcache"
D. In summary, lines similar to this should be in your Moodle config.php file:
$CFG->tempdir = '/shared/path/temp';
$CFG->cachedir = '/shared/path/cache';
$CFG->localcachedir = '/local/path/localcache';
* where /shared/path and /local/path are the actual paths in your system.

I would also echo what Howard Miller said about double checking that Redis is set up correctly. On an initial set up, before the Application cache can be set up, Moodle will be very slow which is expected.

Average of ratings: Useful (3)