07 November 2013, 21:55

Hello everyone,

thanks for your suggestions!

Indeed we are using NFS (and SSL as already stated). On our testsystem the problem doesn´t occur and everything loads fine and quick enough. These two are the differences to productive system: NFS and SSL. I also believe that NFS is the problem (or even SSL according to logic). It´s not generally slow but in some special cases wherove loading thumbs.php we can reproduce: /view/blocks.php?id=*** and /view/layout.php?id=*** take very long loading the thumbs, often about one minute or more! Unfortunately these are the base sites editing the portfolio!

Also listing files (/artefact/file/index.php) is very slow the more files there are to display. Here, too the thumbs are loading slow, filenames are displayed immediately.

In any case the next page is displayed only after loading all of the previous page.

@Dirk: You changed lines 34 and 51 of auth/sessions.php? You replaced 'dataroot' with? Anything else? I tested it on our testsystem but after changing login doesn´t work anymore.

@Aaron: Is there any instruction using memcache and what exactly has to be changed in Mahara 1.7 to test your solution?

Thank you very much!

kind regards
Klaus

11 November 2013, 15:38

Hi Klaus,

To use the memcache patch:

1. Make sure you have the PHP "memcache" module installed (not the similarly named "memcached" module)

2. Set up a memcache server (on my local workstation, I installed this by doing "apt-get install memcachedb". I wasn't involved in setting it up on our hosting cluster)

3. Cherry-pick the top two commits from here to your Mahara branch: https://gitorious.org/mahara/agwells-mahara/commits/79bda3f3d2da7b9b45333bf1d449eff5f94059d5

4. In your config.php file, set the address of your memcache server(s) as a comma-separated list in the $cfg->memcacheservers config setting: $cfg->memcacheservers = 'tcp://memcache-a:11211,tcp://memcache-b:11211';

That should do it.  Like I said, we've been using this in production for a few months now, on Mahara 1.6, 1.7, and 1.8 sites (including this one!), and we haven't had any problems. I'd like to incorporate this into Mahara core, but we'd need to make it so you can choose between DB sessions and memcache sessions via the config, and, ideally, make it a pluggable system so other DB handlers are possible as well. And that would be non-trivial, so I haven't had the opportunity to do it yet.

Cheers,

Aaron

11 November 2013, 23:25

Hello everyone,

thank Dirk we fixed the enormous loading times - made my day not to say my month!!! The solution was indeed changing lines 34 and 51 of auth/sessions.php from "dataroot" to a local directory. That means NFS where our dataroot is located caused the problems. It only worked in the second try because get_config had to be deleted so that the path is prompted directly.

Though the problem for us is fixed it should be implemented in core as Aaron wants to and every admin should be able to configure it.

Using memcache is also a local source which prevents from long external loading times (e.g. NFS). I wasn´t able to test it yet because i had to request installation of memcache for our server first.

Have a nice week...!
Klaus

12 November 2013, 4:44

Glad it worked out for you. I am away from my office and would only be able to look at exactly what we are doing tomorrow, Nov 12. I meant to post our workaround 2-3 years ago but forgot. During our recent 1.4 - 1.8 upgrade we re-discovered this as a problem and so your post was very timely I think.

12 November 2013, 12:56

Actually I was talking about putting the memcache option into core.

I could certainly add a config option to store the session data in a custom location, though. In fact, I've gone ahead and submitted a patch for it in 1.9 now: https://bugs.launchpad.net/mahara/+bug/1250256

(The main reason we store it in the dataroot is to support load-balancing. If you've got multiple web servers, and the user might get sent to any one of them when they make their request, then the session data needs to be in a location that all of the servers can access. Or you need to make sure each user gets sent to the same web server each time during a session.)

Cheers,

Aaron

24 July 2015, 20:59

Just for documentation purposes:

The fix Aaron described above, works fine since Mahara 1.9.

You have just to add that line in config.php:

$cfg->sessionpath = '/tmp/mahara-sessions';

That example is also documented in config-defaults.php (line 319):
"If your dataroot is stored on a slow volume (such as NFS) you may want to change this to a local directory.
Although if you're using a web server cluster, be aware that session files need to be stored in a location shared by all servers, or you need to use persistence to send each user to only one server per session."

Cheers,
Klaus