Pages slow to load (even simple pages)

Permalink
I noticed that many of our pages seem to take a long time to load (1.5-2 seconds). I installed the "Speed Analyzer" extension, and confirmed that even really simple pages are taking more than 1.5 seconds to load. I clicked on the record for one of the pages that took about 1600ms, and saw a graph of the load time for each event, and there are a couple of events that take a long time (300ms and 707ms). Both events are of type "on_block_before_render." The first includes 589 SQL queries in 127ms, and the second includes 641 SQL queries in 248ms.

This is a really simple page -- any idea why it would take so long to load, and what I could do to speed it up?

Environment Info:
# concrete5 Version
Core Version - 8.4.3
Version Installed - 8.4.3
Database Version - 20180716000000

# concrete5 Packages
ExchangeCore reCAPTCHA (1.1.1), Formidable (Lite Version) (1.0.4), Instant Page Speed Magic (1.0.8), Speed Analyzer (1.2.3), Supermint Theme (3.4.1.3)

# concrete5 Overrides
None

# concrete5 Cache Settings
Block Cache - On
Overrides Cache - On
Full Page Caching - On - If blocks on the particular page allow it.
Full Page Cache Lifetime - Every 6 hours (default setting).

# Server Software
Apache

# Server API
cgi-fcgi

# PHP Version
5.6.40

# PHP Extensions
bcmath, bz2, calendar, cgi-fcgi, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imap, intl, ionCube Loader, json, ldap, libxml, mbstring, mcrypt, mhash, mysql, mysqli, mysqlnd, openssl, pcntl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, posix, pspell, Reflection, session, SimpleXML, soap, sockets, SPL, sqlite3, standard, sureacct, tidy, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib

# PHP Settings
max_execution_time - 120
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - -1
max_input_vars - 1000
memory_limit - 400M
post_max_size - 20M
sql.safe_mode - Off
upload_max_filesize - 20M
ldap.max_links - Unlimited
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 7200
soap.wsdl_cache_limit - 5

 
JohntheFish replied on at Permalink Reply
JohntheFish
Look carefully at your Autonav settings in the header and footer. A poor load speed is often the result of autonav being poorly configured. For example, spidering the whole site when only the first 2 levels are shown in the navigation.
avsfan replied on at Permalink Reply
Hi John,

Thanks for the suggestion. We really only have 2 levels of Nav, so I don't know if that's it.

However, I wanted to check it anyway. So, in the "Stacks and Global Areas" section, I went to the "Edit Auto-Nav" page, and edited it. Under "Page Levels" it's set to "Display a custom amount" with a value of 1. So that sounds right, correct?

Also, in the same section, I looked at "Sidebar" and edited it. On this one, under "Page Levels" it's set to "Display all." When I tried to change it and clicked "Save", an error box was displayed, but there was nothing in the box. So I don't know what's going on with that.

Still, since we have very few pages on the entire site ( fewer than 50 pages), would this be a major issue?

What other things should I check? (and where would they be located?)

Thanks again!
JohntheFish replied on at Permalink Reply
JohntheFish
Does your theme have any hard-coded nav blocks? They could also be over-enthusiastic and hard codced blocks are not cached.
avsfan replied on at Permalink Reply
I don't think so. I didn't build the site, but I believe that the guy who did used standard blocks.

How would I be able to check that?
JohntheFish replied on at Permalink Reply
JohntheFish
You will need to look at the php source for the theme, typically in the header and footer elements.
avsfan replied on at Permalink Reply
The header and footer files appear to be unmodified (based on their file dates). However, both the head and navigation files have more recently modified dates.

I tried to attach them to this message, but got an "Invalid token" message. I also tried to include their code directly inside code tags, but got the same error.

I haven't seen that error message before -- any idea what would be triggering it? Also, how can I share that code so it can be examined?
JohntheFish replied on at Permalink Reply
JohntheFish
usually that it took too long to add/edit the post and the validity of the edit form timed out.

You can't attach directly - .php will be rejected.

Inline, you can use (square-parentheis)$code(slash square-parentheis) to show code inserts.
eg
$some_php;
avsfan replied on at Permalink Reply
Thanks -- I renamed the php files to file.php.txt, didn't work. I did use those tags to try to inline, but I'll try again.
head.php:
<?php  defined('C5_EXECUTE') or die(_("Access Denied."));
$c = Page::getCurrentPage();
// Les options
$o = \Concrete\Package\ThemeSupermint\Src\Models\ThemeSupermintOptions::get();
?>
<!DOCTYPE html>
<html lang="<?php echo Localization::activeLanguage()?>" class="<?php  echo $o->navigation_style == 'lateral-regular' ? 'with-lateral-nav' : '' ?>">
<head>
<?php echo $html->css($view->getStylesheet('main.less')); ?>
<!-- Start Concrete Header -->
<?php Loader::element('header_required'); ?>
<!-- End Concrete Header -->
<?php if (Loader::helper('concrete/ui')->showWhiteLabelMessage()) :?><style media="screen">body div#ccm-toolbar>ul>li#ccm-white-label-message{display: none !important}</style><?php endif ?>
<!-- HTML5 shim and Respond.js for IE8 support of HTML5 elements and media queries -->
<!-- WARNING: Respond.js doesn't work if you view the page via file:// -->


navigation.php:
<?php  defined('C5_EXECUTE') or die(_("Access Denied."));
$o = \Concrete\Package\ThemeSupermint\Src\Models\ThemeSupermintOptions::get();
$this->inc('elements/head.php');
$page = $c;   
$bannerImage = $page->getAttribute('banner_image');   
?>
<?php
$pt = $c->getPageTemplateObject();
if (is_object($pt)) {
    $handle = $pt->getPageTemplateHandle();
}
?>
<?php $this->inc('elements/top_bar.php'); ?>
<div class="top-info">
   <div class="logo-box">
avsfan replied on at Permalink Reply
didn't work until I put each of the code tags on its own line... weird...
JohntheFish replied on at Permalink Reply
JohntheFish
There is a hard coded nav towards the end of the second file. Try commenting that out and see if it makes a difference.
<?php 
                     $nav = BlockType::getByHandle('autonav');
                     $nav->controller->orderBy = 'display_asc';
                     $nav->controller->displayPages = 'top';
                     $nav->controller->displaySubPages = 'relevant_breadcrumb';
                     $nav->controller->displaySubPageLevels = 'enough';
                     $nav->render('templates/breadcrumb');
                  ?>

to
<?php 
                     /*$nav = BlockType::getByHandle('autonav');
                     $nav->controller->orderBy = 'display_asc';
                     $nav->controller->displayPages = 'top';
                     $nav->controller->displaySubPages = 'relevant_breadcrumb';
                     $nav->controller->displaySubPageLevels = 'enough';
                     $nav->render('templates/breadcrumb');*/
                  ?>
avsfan replied on at Permalink Reply
Thanks for finding that, and showing what to do. As a benchmark, I refreshed the page before making the changes and noted the time to complete. Then I made those changes, reloaded the page, and the time was almost identical. I did it a couple more times to make sure, and that section doesn't appear to make a difference (at least not a noticeable one).

Any other thoughts on what might be causing such a slowdown?

Thanks again!
JohntheFish replied on at Permalink Reply
JohntheFish
The important measure would be to look at speed analyzer.

Can you screengrab the speed analyzer chart before/after and post it?

There may be similar or worse in the footer.
avsfan replied on at Permalink Reply 1 Attachment
Sure, thanks. Graphs attached. These show about 1400ms (before on top), but a few minutes later both were in the 2000ms range.
JohntheFish replied on at Permalink Reply
JohntheFish
The preamble and tail are things you can't avoid, its the nature of a cms. They are only improved by server spec and caching.

The part you should be able to improve is the gap in the middle. You need to identify what that block is.

At first I was pointing to autonav because its the usual villain. However, autonav tends to be towards the start (header) or end (footer). So the location of that gap suggests another block may be the culprit (unless there is an autonav in the middle of the page). You need to look through the speed analyzer report and identify that block.
avsfan replied on at Permalink Reply 1 Attachment
The section that takes so long has 641 queries. I grabbed them and put them in a excel sheet with data bars to show relative times for each (attached, with extension .txt added). How would I use this to determine the block(s) causing the slowdown?
JohntheFish replied on at Permalink Reply
JohntheFish
Usually you can see the block handle by hovering the events or in the query trace.
JohntheFish replied on at Permalink Reply
JohntheFish
The SQL looks like the queries from an autonav.
avsfan replied on at Permalink Reply
Hmmm. The log shows that big delay in the "Custom" category, with "on_block_output" next to it, but when I hover over either one, it doesn't display the block. Hovering on "on_block_output" just says "triggered in the Block class. Runs just before a block is outputted on the page."

Looking at the individual queries (they show up as links, but hovering them shows nothing, and clicking them just copies the link to the clipboard).

What are some other places I could look to see if there's some other autonav or something like that?

Thanks for your patience and continued help!