search

getgrav / grav-plugin-precache

Grav PreCache Plugin
https://getgrav.org
MIT License
7 stars 2 forks source link

Various inconsistencies #3

Open ohnonot opened 7 years ago

ohnonot commented 7 years ago

Hello, i'm a little unsure about using precache on my production server. i have my development environment set up with precache enabled: true and the public environment enabled: false. is that sensible, in other words, is my production environment already (pre)cached now?

ohnonot commented 7 years ago

is somebody actually using this plugin? precache takes very long on my site. admittedly, it's a single-core somewhat older consumer hardware, and i have a few image galleries, but 10mins? i also have duplicate log entries for every precached page, like this:

[2016-12-14 16:57:30] grav.WARNING: precache: /some-page [] []
[2016-12-14 16:57:30] grav.WARNING: precache: /blog/some-page [] []

(system.yaml has hide_in_urls: true for the /blog alias)

even after that loading a page takes a long time sometimes and i've been having weird intermittent problems (long page loads, wrong redirections, have to press F5 repeatedly...), which might be due to loading both environments (see above) in the same browser?

i also could not get the CLI trigger to work (after a few seconds i get a positive message, but loading the site in the browser then triggers a 10min precache run).

all in all i'm getting the weird feeling that this plugin is not fully functional?

flaviocopes commented 7 years ago

1) it's normal that it crawls all routes for a page. The /blog/blog-post route in your case is an alternative route, although the canonical one is /blog-post. They are both page routes so they are crawled at the same time.

2) there is no correlation between the 2 environments. Pages are cached server-side, so there is nothing stored in the browser memory cross-site if the domain is different.

That said, 10 minutes is really strange and seems something is blocking execution. I just tried it and it works fine to me. I'm testing it on a local MAMP setup.

The plugin also runs on onShutdown which should trigger after the page is loaded and sent to the browser. It's not working in every setup but if you're using php-fpm as I think you were talking about nginx, that should work out of the box.

ohnonot commented 7 years ago

changing to nginx has significantly improved the situation. i should have done this much earlier, it wasn't hard to do.

i just did some serious benchmarking on my development site (same machine as production site). the processor is intel celeron @ 1.6GHz. ram is 2GB, there's no problem with that.

there's 470 .png and .jpg images, that includes headers and such, but most of them are photos á ~2MB.

looking at it this way, it seems normal that it takes a long while. maybe i can throttle php-fpm to leave some resources for others?