Pages are extremely slow to load

[ek68794998]

I just started with a brand new installation of Grav (w/ admin tools). I'm working on a dev box with EasyPHP on PHP 7.0.4 locally. Functionally, the service is fine so far.

However, I'm getting extremely slow load times from Grav, both on EasyPHP and WampServer. Admin panel pages take 7-8 seconds to load, and content pages take 3-4. Other pages of mine I work with locally take under a second.

Based on the docs, Grav should be built to be highly performant. Are these kind of load times expected? If not, how can I diagnose the issue?

I found the debugging view in Grav, and was able to get a view of where those 3 seconds are going. A lot of those seem to be taking longer than they should -- configuration, for example, is taking over 800ms by itself (200ms when it hits the cache, but the overall time is still over 3sec).

Edit: Added debugging image and tested with WampServer also.

[rhukster]

That's definitely not normal. With PHP 7.0 you should be under 50ms (per Grav debugger) no matter your hardware (pretty much). I commonly get 10ms on my 2008 mac pro.

The first thing to check is extra PHP extensions. Things like xdebug can really slow PHP down a lot. The other thing is a slow file system. This could be related to accessing your site from a shared folder, or worse yet, a network folder.

What is your computer setup like? Even in my VMWare virtual machine running windows 10, i get only slightly worse performance than my native mac.

[rhukster]

BTW to compare your debugger timeline screenshot, this is a site i'm working on now:

[ek68794998]

Yeah, that's what I figured. In the debugger docs, it shows the load time as 9ms. (I wish!)

The first thing to check is extra PHP extensions. Things like xdebug can really slow PHP down a lot.

Xdebug hasn't been enabled, I don't think. My php.ini file currently has:

zend_extension=""
xdebug.default_enable=0
xdebug.remote_enable=0
xdebug.remote_autostart = false
xdebug.auto_trace=0
xdebug.profiler_enable=0

And when I run xdebug_* commands in PHP, they fail with a "command not found" error. Not sure which other extensions I should remove, but I will poke around at removing some of them and see what happens!

Edit: Just tried removing all extensions except for the required mbstring; still getting 3sec+ load times.

The other thing is a slow file system. This could be related to accessing your site from a shared folder, or worse yet, a network folder.

I'm not sure how slow would be considered "slow". I think the last benchmark I ran on my HDD had it at around 150 MB/s. Additionally, my test with Wamp (which was somehow ~1sec slower) was on an SSD.

What is your computer setup like? Even in my VMWare virtual machine running windows 10, i get only slightly worse performance than my native mac.

Windows 10 x64, i7 3.6GHz processor, 32 GB memory, GTX 960 SLI for graphics, and as mentioned I've been trying on both an SSD and HDD.

[rhukster]

well you certainly don't have a slow machine, could you please try running with the built-in php server?

php -S localhost:8000 router.php

BTW, this only works with latest Grav release.

[ek68794998]

I had to pull up the router.php file from /system to the project root to get it to run. Once I did so, and accessed localhost:8000, I got this:

I:\Projects\Websites\ekumlin-web>php -S localhost:8000 router.php
Failed loading D:\EasyPHP\Devserver-16.1\eds-binaries\php\php704vc14x86x161220120433\ext\
PHP 7.0.4 Development Server started at Fri Jan  6 22:18:17 2017
Listening on http://localhost:8000
Document root is I:\Projects\Websites\ekumlin-web
Press Ctrl-C to quit.
[Fri Jan  6 22:18:22 2017] ::1:60267 [200]: /
[Fri Jan  6 22:18:22 2017] ::1:60268 [200]: /user/themes/antimatter/css/pure-0.5.0/grids-min.css
[Fri Jan  6 22:18:22 2017] ::1:60269 [200]: /user/themes/antimatter/css-compiled/nucleus.css
[Fri Jan  6 22:18:22 2017] ::1:60270 [200]: /user/themes/antimatter/css-compiled/template.css
[Fri Jan  6 22:18:22 2017] ::1:60271 [200]: /user/themes/antimatter/css/font-awesome.min.css
[Fri Jan  6 22:18:22 2017] ::1:60272 [200]: /vendor/maximebf/debugbar/src/DebugBar/Resources/debugbar.css
[Fri Jan  6 22:18:22 2017] ::1:60273 [200]: /vendor/maximebf/debugbar/src/DebugBar/Resources/widgets.css
[Fri Jan  6 22:18:22 2017] ::1:60274 [200]: /vendor/maximebf/debugbar/src/DebugBar/Resources/openhandler.css
[Fri Jan  6 22:18:22 2017] ::1:60275 [200]: /system/assets/debugger.css
[Fri Jan  6 22:18:22 2017] ::1:60276 [200]: /user/plugins/markdown-notices/assets/notices.css
[Fri Jan  6 22:18:22 2017] ::1:60277 [200]: /user/plugins/login/css/login.css
[Fri Jan  6 22:18:22 2017] ::1:60278 [200]: /user/themes/antimatter/css/slidebars.min.css
[Fri Jan  6 22:18:22 2017] ::1:60279 [200]: /system/assets/jquery/jquery-2.x.min.js
[Fri Jan  6 22:18:22 2017] ::1:60280 [200]: /user/themes/antimatter/js/modernizr.custom.71422.js
[Fri Jan  6 22:18:22 2017] ::1:60281 [200]: /vendor/maximebf/debugbar/src/DebugBar/Resources/debugbar.js
[Fri Jan  6 22:18:22 2017] ::1:60282 [200]: /vendor/maximebf/debugbar/src/DebugBar/Resources/widgets.js
[Fri Jan  6 22:18:22 2017] ::1:60283 [200]: /vendor/maximebf/debugbar/src/DebugBar/Resources/openhandler.js
[Fri Jan  6 22:18:22 2017] ::1:60284 [200]: /user/themes/antimatter/js/antimatter.js
[Fri Jan  6 22:18:22 2017] ::1:60285 [200]: /user/themes/antimatter/js/slidebars.min.js
[Fri Jan  6 22:18:22 2017] ::1:60288 [200]: /user/themes/antimatter/css-compiled/nucleus.css.map
[Fri Jan  6 22:18:22 2017] ::1:60289 [200]: /user/themes/antimatter/css-compiled/template.css.map
[Fri Jan  6 22:18:22 2017] ::1:60290 [200]: /user/themes/antimatter/fonts/fontawesome-webfont.woff2?v=4.6.3
[Fri Jan  6 22:18:22 2017] ::1:60291 [200]: /system/assets/grav.png

Access time was still around 3.7sec.

[ek68794998]

Some good news! Not great, but good.

I set realpath_cache_size = 16M in php.ini, which reduced the load time to around 1.2sec instead of 3sec+.

Unfortunately I'm thinking, at this point, that there's little related to Grav in the slowness I'm experiencing. Feel free to close the issue if you feel it's appropriate. (Though I'm of course open to more suggestions!)

[OleVik]

Have you considered something apart from EasyPHP or WampServer? I occasionally use WampServer, but haven't had anything near that long of a load on a much weaker computer. I notice you are running one PHP-installation from I:/ and EasyPHP from D:/, is the Grav-installation running in the intersection of these two disks/partitions?

For an example setup, which I favor, I run CaddyServer from C:/Caddy and Grav from C:/Caddy/Grav. The overhead of Caddy is practically non-existent, as is running it with individual PHP-installations (7.0.x for Grav and some others, 5.6 for some older scripts) and databases (MySQL, MariaDB).

[ek68794998]

I'm not sure what other alternatives I have in terms of PHP+Apache server. I left Wamp because it didn't support PHP 7, and EasyPHP did. I also tried using MAMP on my Macbook, but ran into all kinds of other problems with that (like internal server errors with no log messages associated); not sure what setup you have on your MBP.

Having the code on D: doesn't help, oddly enough, though I understand that Windows' file operations can be sluggish. Both drives generally vary from 800ms~1.2s if I don't load the page for a while (i.e. wait a minute or two, then refresh).

What is interesting is that if I refresh the page over and over in quick succession, the time reduces down to ~180ms. It seems kind of like the cache "warms up" and then after some time, shuts down and has to start up again.

[rhukster]

Out of curiosity have you tested PHP 5.6, or 7.1??

[rhukster]

Just wandering if its a bug on PHP7 on windows.

[ek68794998]

Yeah, I tried on PHP 5.6 as well. It was ~15% slower. Haven't tried 7.1.

[rhukster]

Do you have any antivirus software or anything that might be trying to inspect files as they are created (like grav's cache) ???

[ek68794998]

All I've got running is Windows Defender. I tried disabling that and adding EasyPHP and my project folders to exclusions, and the result is the same.

I've also been trying with the router.php method, but no difference there.

[rhukster]

I'm running out of ideas, but you clearly have something not running efficiently/correctly on your system. Windows is one of those platforms with so many variables involved, that debugging issues like this is really hard.

The crazy thing is that a $5/mo DigitalOcean VPS is going to give you amazing performance (like those 10ms screenshots I showed you). Heck even a $35 RaspberryPi running Raspbian with the filesystem on a MicroSD card is going to give you < 100ms performance with Grav. What you are seeing is clearly a big problem and probably one that is pandemic on your system, but is merely more evident while testing Grav because those kinds of numbers are just so out of whack with the norm.

I don't suppose a clean install is in the cards? How about a dual-boot install of a linux distro like Ubuntu? I know these are major steps, and frankly if your happy with everything else on your machine, I wouldn't bother just to get Grav running. Maybe it makes more sense just to try a VPS, or RaspberryPi I mentioned above :)

FWIW, When I ran windows (15 years ago), I would commonly come up against weird issues that only a reinstall would fix. Moving to a Mac was the best decision of my professional career as the lack of 'problems' and 'issues' has made me more efficient in getting my work done, and in turn has made my life more enjoyable and rewarding.

[rhukster]

BTW, here's a blog post I did on how I setup my RaspberryPi for Grav: https://getgrav.org/blog/raspberrypi-nginx-php7-dev

[ek68794998]

I'm running out of ideas, but you clearly have something not running efficiently/correctly on your system. Windows is one of those platforms with so many variables involved, that debugging issues like this is really hard.

Agreed. There's just too many moving parts.

I did just get my Macbook working with MAMP, and I'm getting ~400ms load times on first load, with ~180ms load times after that.

I might try out your Raspberry PI solution. Otherwise I'll just fall back on the 200-ish millisecond load times for local dev. It will be interesting to see what kind of times they'll translate to on the production servers.

[rhukster]

Oh can you please zip up your current site (whole grav folder) and send me a link to download and test it locally. You never know might be something I can test myself.

Can email me at xxx@xxxx.com

[ek68794998]

Yup, done.

[rhukster]

Yah, not the Grav config. 180ms for first uncached load, < 20ms every refresh after that.

[ek68794998]

Huh. This is definitely odd. The fact that it is slow across both my Windows and Mac machines, but not yours.

I also just tried on my prod server, and I get 60~70ms load times. So that's a definite improvement, and probably one that I can live with.

[OleVik]

From experience all versions of PHP 7.x.x works equally well with Grav, I've ran through all the released ones. Windows Defender is not the issue, unless you get a flashing message saying "Defender found a bad file". The only way disk read/write speed would be affected by Windows would be if operations had to run across disks/partitions or if a Service or Process had to be accessed during runtime. Other than that file-transfers, reading, and writing runs pretty much like in MS-DOS, leveraged through explorer.exe.

Is your browser (Chrome from your screenshots) up to date? And does it have any peculiar (ie, experimental) settings? In my experience sluggish performance in the browser, seemingly disappearing with fast reloads, is an issue with the browser cache or bad antivirus interfering with it (read: Avast). This is most obvious if the browser uses a lot of CPU-power, memory, and has many running processes (many tabs, extensions loaded on each).

Another problem, common in "easy setup" development environments like Wamp, Mamp, EasyPHP, XAMPP etc. is that their default configurations are miles away from optimal or simple. This usually applies to both the server (Apache, Nginx) and the scripts (PHP). This is why I prefer Caddy: Single binary (~14MB), no included scripts or annoying setups. Thus PHP runs as simple and "pure" as possible, and the environment itself has no hidden hindrances. Starting it is just typing caddy into a console window, and pretty much every relevant setting resides in a single php.ini (well, one for each active version of PHP) that gets run with a basic call within the caddyfile: fastcgi / 127.0.0.1:9000 php (ie. a pure PHP-server controlled by Caddy).

[ek68794998]

Is your browser (Chrome from your screenshots) up to date?

Yup.

And does it have any peculiar (ie, experimental) settings?

No, it has a couple extensions, but nothing too taxing. Nothing that would affect back-end execution, anyway. I also tried in Internet Explorer on Windows (with all default settings, no extensions) and Safari on Mac, and got the same result.

This is why I prefer Caddy: Single binary (~14MB), no included scripts or annoying setups.

Unfortunately, Caddy doesn't work for me. I just get errors when I try to access the page.

07/Jan/2017:15:01:09 -0800 [ERROR 502 /] read tcp 127.0.0.1:5360->127.0.0.1:9000: wsarecv: An existing connection was forcibly closed by the remote host.

Doesn't look like a common problem, though I may open an issue on the Caddy project and see if anyone has any suggestions about that.

[OleVik]

Looks like a more common issue when ran within Docker, are you running Caddy locally on Windows or dockerized?

[ek68794998]

Locally. I'm not using any kind of virtualization.

[OleVik]

It's an odd error for sure. Alongside the caddyfile and caddy.exe I have a folder named php with a clean copy of PHP 7.0.7, and I run this in the caddyfile to get Grav up:

# Grav
grav.dev:80 {
    root C:\caddy\grav
    log logs/access.log
    errors logs/error.log
    gzip
    tls off
    fastcgi / 127.0.0.1:9000 php

    # Begin - Security
    # deny all direct access for these folders
    rewrite {
        r       /(.git|cache|bin|logs|backups|tests)/.*$
        to      /403
    }
    # deny running scripts inside core system folders
    rewrite {
        r       /(system|vendor)/.*\.(txt|xml|md|html|yaml|php|pl|py|cgi|twig|sh|bat)$
        to      /403
    }
    # deny running scripts inside user folder
    rewrite {
        r       /user/.*\.(txt|md|yaml|php|pl|py|cgi|twig|sh|bat)$
        to      /403
    }
    # deny access to specific files in the root folder
    rewrite {
        r       /(LICENSE.txt|composer.lock|composer.json|nginx.conf|web.config|htaccess.txt|\.htaccess)
        to      /403
    }

    status 403 /403
    ## End - Security

    # global rewrite should come last.
    rewrite {
        to  {path} {path}/ /index.php?_url={uri}
    }
}

If you have time I'm in the Gitter-chat.

[OleVik]

For future reference, the above caddyfile needed the following addition:

# Grav
grav.dev:80 {
    ...
    tls off
    startup php-cgi -b 127.0.0.1:9000 &
    fastcgi / 127.0.0.1:9000 php
    ...
}

Ie. startup php-cgi -b 127.0.0.1:9000 & on the line before fastcgi / 127.0.0.1:9000 php. And of course, it assumes that php is available from the command-line (in Windows system paths/environment variables).

[ek68794998]

Caddy's a bit faster, but not much.

• EasyPHP (Win, PHP 7.0.4): \~1.5s cold, 300~800ms warm
• Caddy (Win, fresh PHP 7.1.0): \~1.5s cold, 300~500ms warm
• MAMP (Mac, PHP 7.1.0): \~400ms cold, 150~300ms warm
• Production server (Linux, PHP ~5.5.19~ 7.1.0): ~\~1.6s cold, \~70ms warm~ \~200ms cold, 20~30ms warm

[OleVik]

On my massively slower laptop, with a cleared Grav-cache I clock admin in at 6.06s, and cached at 3.52s. Of course, I run about 8 sites of various size on the same instantiation of PHP within Caddy. If I were to discount Font Awesome, Montserrat Google Font, and run it over HTTP/2 this would probably be lowered to a third of those values. Drop the multiple configurations within Caddy, maybe even 0.5-1s less than that.

At least now you have a cleaner and easier-to-upgrade version of PHP running, with less overhead, though it might be worthwhile to diff the Caddy and Mamp PHP configurations to see what part of Mamp's php.ini leads to the lower times. On production I reckon the biggest improvements would be PHP 7 and HTTP/2.

[rhukster]

FWIW I've found that APCu is actually slightly slower than file caching with PHP7. Not sure how that's possible, but something to consider.

[ek68794998]

Yeah, I think this is as good as it's going to get. I'm fairly sure I'm not using APC, but I'll double-check my config. I'm going to close this issue now, since it seems to be a machine-related issue and not a Grav issue.

For anyone who finds this in the future with a similar issue, my take-aways were:

• The issue was with PHP execution, not with connection time (meaning none of the ::1 or hosts hacks worked for me)
• Set realpath_cache_size = 16M (not 16k) in php.ini
• Use latest PHP (7.1+ right now)
• WampServer is very slow, EasyPHP is slightly faster, and Caddy is slightly faster than that (configuring Caddy is a tad tricky; see OleVik's notes above)
• Instead of Windows, try Mac or Linux (at least 50% reduction in load times for me), if for no other reason than to see if Windows is holding you back
• Drive type (SSD vs HDD) didn't matter much

Thanks for the help, guys!

[Rarst]

Having just been through similar troubleshooting (though not as severely slow), see linked thread, https://blackfire.io/ profiler was helpful to figure it out. By now it works with Windows and PHP 7. Beats guessing. :)

[gooddha]

I have similar problem with GRAV+Gantry on Openserver + W7x64. Pages loaded very slow, on any browser.

Problem was gone when i turned Apache+PHP7.1 into x86, before that they was x64.

[mahagr]

Just a comment which I found out from some user -- it looks like that checks for non-existing files aren't cached in Windows. It may be one contributing factor on why it is so slow in Win, but fast on every other system.

[Rarst]

@mahagr yep, I raised that in https://github.com/getgrav/grav/issues/931#issuecomment-270714008 :)

[mahagr]

Oh, there it was! I need to bookmark it. :1st_place_medal:

[codersguild]

GreaT,

[martic]

Just on the subject of web servers try https://laragon.org

[ashraf21c]

realpath_cache_size Set realpath_cache_size = 16M (not 16k) in php.ini

The same problem here, but Im using WIndows. I use CPanel/ paid shared hosting. Im using PHP8.2, Theres no such value, but, instead, theres max_execution_time that was set to "60", despite the default value is "30" as mentioned there. (The hoster changed it??) However, I changed this value to "16M". It became faster, but not always.. multiple times it still takes a long time. I changed the value to "16". It`s always fast now.

Only Grav requires this setting. It`s a fresh softaculous installation.