-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slower page saves with 1.7.6 — 30 secs for date md edit via Admin #3231
Comments
You could enable debugger and install clockwork into your browser to see what's taking the time. Additionally, you could also install PHP extension https://github.com/tideways/php-xhprof-extension which will provide data from the individual method calls. Saving shouldn't take that much time, though it does clear some cache and also recreates index file, which can be pretty large with 1000+ items. |
Hi @mahagr Here is a debugger screenshot when simply saving a css change on a fairly untouched local Typhoon install... is that helpful? Just looking at clockwork... |
So using Chrome and Clockwork now I am getting 35312ms in the log when it saves... not sure what I am looking for though that might point out what the issue is. |
trying to figure out the sharing... seems the logs are so big it kills Clockwork sharing! |
Just the performance log: https://clockwork.underground.works/share/nbocwail |
Check which plugins are using the event. You can do that by going to the events tab and finding the event from there. In the right there's a small arrow icon that will show the hooked up listeners. |
Hmm, also.. Do you have all the pages at the same level? All visible? |
Thing is, this is definitely a new issue with newer versions of Grav. Site was originally built by @rhukster :) |
I just saved a page in 1800 pages in a single folder test site. Saving takes 300ms. |
The thing that is clogging up 'events' is LOADS of 'onFlexObjectBefore / After Save entries... |
The onFlexObject events seem to have no listeners then finally AdminPlugin->onAdminAfterSave() GitSyncPlugin->onAdminAfterSave() and then GitSyncPlugin->synchronize() (GitSync is set to NOT sync on page save tho') |
Looks like I can see the clockwork in the frontend. (BTW) Can you contact me privately and send the installation to me, so I can take a look. This is clearly something I'm not able to reproduce locally. |
I'm able to reproduce the issue. |
@MattAppleton Can you try if everything looks good with above fix? Please test saving pages in the news as well as adding new pages to there. |
Will do. Swapping out this file
right? |
So far that seems much quicker, now 6-7 secs per save... |
Cool. I think you're also using gitsync, which also slows down saves. Let me know if you find any side effects from the fix. |
I'll check that on live site ASAP. Does Gitsync slow things down even if the 'Automatic Synchronization Settings' are toggled 'off'? If so, I guess its best to disable Gitsync between development stages then? thanks |
It only slows the save when it pushes to the repository. |
Automatic synchronization off won’t slow things down as no push will happen on save. Of course there will be the push time when you manually sync. |
Released version should be improved. |
I have noticed recently that a simple page edit (changing a date) is taking around 30 seconds to save?!
This site running
Grav v1.7.6
Admin v1.10.5
PHP Version 7.4.15 with plenty of memory allocated (1024MB)
The site does have a fair few pages — 734 at the minute... the page I was editing as an example here — but this applies to the whole admin it seems to be going pretty slow...
edit — changing plugin settings seems to save quickly, page amends are taking a long time to see... **
I was wondering if this was something to do with the admin plugin and associated cache? If I edit the page directly on the server via FTP it saves pretty much instantly...
thanks for looking
The text was updated successfully, but these errors were encountered: