Further tests using Ylsow +perfdebug

Further tests using Ylsow +perfdebug

by Mari Cruz García -
Number of replies: 9

Changing to the standar Moodle theme in our production site, these are the values that I got for perdebug:

Moodle 2.2.4

around 100 user accounts, low traffic (no more than 10/20 students loged at the same time).

Tests Firefox and being administrator (times for loging as a simple user are, roughly, very similar).

Logging to frontapage:

3.971782 secs

RAM: 48MB

RAM peak: 48.7MB Included 1075 files

Contexts for which filters were loaded: 59

Filters created: 177

Pieces of content filtered: 45

Strings filtered: 0

get_string calls: 2321

strings mem cache hits: 2516 strings

disk cache hits: 209

DB reads/writes: 1288/47

Session: 10.6KB

 

From frontpage to one of our current courses (medium size course):

3.392716 secs

RAM: 55.7MB

RAM peak: 56MB

Included 799 files

Contexts for which filters were loaded: 7

Filters created: 21

Pieces of content filtered: 21

Strings filtered: 0

get_string calls: 2305 strings

mem cache hits: 2501 strings disk

cache hits: 210 DB reads/writes: 884/24 Session: 28.9KB

We embed Vime content in our courses, whose requests to Google Analytics slow down the uploading time.

I was wondering if there is any benchmark value I can compare with ?

Likewise, I have use Ylsow, as it was suggested in Moodle.org.

This is our moodle site:

https://learning.health.org.kw/

 

Our original grade was 'F', and it changed to 'C', when I adopted Yslow suggestions regarding 'Content Delivery Network (CDN)'

Our poorest performance is for:

http request, DOM elements, components that are not 'cookie-free', 70 static components without a 70 static components without a far-future expiration date, etc.

This is the complete report:

https://docs.google.com/file/d/0B-wvoM6OdO1TeS1YUWFnTEtpQjg/edit?usp=sharing

I thought that, perphaps, some of the elements of our customised theme (although we don't use jquery) could be related to this poor rate. I changed to 'Standard', which is the most basic theme for Moodle, but I still got a rate 'F' in the Yslow final score (the standard theme itself has

has 47 external Javascript scripts and 7 external stylesheets)

 

Before I install WinCache in our test serve, I would like to ask if I should take the Yslow recommendations serious or  not.

Thank you very much for your advice.

 

 

Average of ratings: -
In reply to Mari Cruz García

Re: Further tests using Ylsow +perfdebug

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

From quote:

DB reads/writes: 1288/47

That is a lot of DB reads.

I just checked on one of our live courses (Moodle 2.3.x), logged in as admin (which makes more db requests than student, but I can't see perfcheck info when logged in as student) and I get:

DB reads/writes: 152/1

So about an order of magnitude less.

You should probably look at reducing the number of db reads. (E.g. try turning off text cache.)

--sam

Average of ratings: -
In reply to sam marshall

Re: Further tests using Ylsow +perfdebug

by Mari Cruz García -

Thanks for your suggestion, Sam.

Text cache was set to 1 minute, but I changed it to 'no' anyway.

However, I cannot see any different as, the number of DB reads and writes is still 1300/2, from a medium size course to frontpage, for instance, and from homepage to medium size course:

DB reads/writes: 901/3

I am fully aware that the figures are very high for such a small Moodle site and I suspect that installing a php accelerator is not going to solve the problem.

In 'Session Handing', I have just read 'If you are using MySQL please make sure that 'max_allowed_packet' in my.cnf (or my.ini) is at least 4M.'

In our my.in there is not max_allowed_packet, I don't know if this could be the problem or not.

Average of ratings: -
In reply to Mari Cruz García

Re: Further tests using Ylsow +perfdebug

by Andrew Lyons -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Hi Aaricia,

Installing a PHP accelerator will not help with your DB calls, but it really will help with the speed of your site in general. You really should be using one.

There is definitely something fruity going on with your site though - that level of DB reads is far from normal. Do you have any contrib blocks shown on all affected pages, or any local plugins which may be doing this?

Andrew

Average of ratings: -
In reply to Mari Cruz García

Re: Further tests using Ylsow +perfdebug

by Andrew Lyons -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

I wouldn't be too concerned with the YSlow recomendations that you have left.

Most of the recommendations are actually a little bogus in this case, for example if you actually look at the page source, you'll see that there are only about three JS files included in the head, and two of those are minified and combo loaded. The rest of the files that YSlow is reporting (Put JavaScript at bottom) are added by the YUI loader in the footer. I also notice that you are (now?) gzipping content on the fly, so that recommendation should be improved now too.

Similarly, a majority of Moodle JS, CSS, and images already do set a far-future expiry date as long as you aren't in theme designer mode, or have any of the other related settings altered (e.g. jsrev, cachejs, etc).

From Moodle 2.5, we'll also be combining more of our JS requests, and minifying their code. We've also removed a couple more JS requests, and much of the CSS will be improved too, hopefully reducing the amount of markup and redundant CSS selectors.

Andrew

Average of ratings: -
In reply to Andrew Lyons

Re: Further tests using Ylsow +perfdebug

by Mari Cruz García -

Thanks, Andrew. I am definitively trying a php accelerator, but I also want to discart any performance issues in the database.

I knew that there was something 'fishy' with our database because it is not normal that such a small site has so many DB request.

We do use, in fact, a block that I created that call some files in the /local plugin directory. We also use third-party blocks, but from trusful encoders such as OU or Davo Smith.

I disabled some of the third parties blocks (including mine) and deleted all blocks from the frontpage except Navigation and settings.

I also created a new course totally blank, no strange course formats, no resources.

I am using 'standard' theme, which is, is not the simplest, one of the most basic.

 

  • SQL server: MySQL 5.5.13

-Uploading times logging to the frontpage:

4.236535 sec
s RAM: 47.2MB RAM
peak: 47.5MB Included 1116 files
Contexts for which filters were loaded: 48 Filters created: 192 Pieces of content filtered: 42 Strings filtered: 368 get_string calls: 2060 strings mem cache hits: 2243 strings disk cache hits: 221 Included YUI modules: 54 Other JavaScript modules:
2 DB reads/writes: 1253/2 Session: 8.1KB
  • From frontpage to blank course:
2.771673 secs RAM: 46.6MB RAM peak: 47.1MB Included 783 files Contexts for which filters were loaded: 26 Filters created: 104 Pieces of content filtered: 0 Strings filtered: 344 get_string calls: 2088 strings mem cache hits: 2275 strings disk cache hits: 221 Included YUI modules: 54 Other JavaScript modules: 3
DB reads/writes: 903/3 Session: 8.6KB
903 reads for a course which no content/no blocks is still really high.
 
I noticed that in the my.ini of mysql there is no ''max_allowed_packet' variable. I wonder if that may be causing the problem
 
Average of ratings: -
In reply to Mari Cruz García

Re: Further tests using Ylsow +perfdebug

by Simon Story -

The size of max_allowed_packet won't alter the amount of DB queries Moodle executes.

If max_allowed_packet was to small, you would soon get errors relating to sessions coming up or other problems. It's probably okay on your system.

If you do want to find the size it is currently set to, login to mysql as a super user and do the following query:

show variables where Variable_name = 'max_allowed_packet';

The value is in bytes.

Average of ratings: -
In reply to Simon Story

Re: Further tests using Ylsow +perfdebug

by J S -

Hi

I took a look at your site and would say its not terrible, but not great either.  If you want to reduce the number of DB calls, configure moodle to not call the DB.  The easiest way to do this is by removing content from your frontpage (I dont know what your site looks like behind the frontpage and can only comment on your frontpage).  For every course you have configured to display, the more calls you will make to your DB.  Do a test of your current page and then remove content and test again.  I have a feeling your site will speed up.  

Code optimizers are a must though if you are concerned about speed.

Average of ratings: -