-
Notifications
You must be signed in to change notification settings - Fork 16
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
Spock hangs up Statamic on content save/reorder for... a while #32
Comments
Have you configured spock to run any non standard commands? |
Nope — just the default options. Here's a sample of what's going on in the logs (identifying info redacted):
As further context, more details that I've been able to ascertain:
Thoughts? |
If the last point above is actually what's going on, then it seems like there're maybe two issues afoot:
|
Looking into queue support. Also curious, which versions of both Statamic and Spock are you running? |
The latestest I think — only been using both for ~two weeks-ish. Statamic |
The next version of Spock should automatically queue commands, so if you have That said, I'm still unclear what's happening to cause such long wait on re-order. How does everything perform when editing a single page, etc.? |
@timichango I notice you've mentioned the entry re-ordering thing here which is valid, but a separate issue. Created a new issue for that specifically #33 🙂 |
"That said, I'm still unclear what's happening to cause such long wait on re-order. How does everything perform when editing a single page, etc.?" Reckon you've already discerned the answer to this, given the new issue #33 that you just opened, but in my case I believe the latency is down to the fact that during a re-order, only a handful of entries (or none at all, if no changes have been made but a re-order-->save-order is initiated anyways) wind up being renamed (thus changed, in git's eyes), while all wind up being re-saved anyways — and since it's firing one commit per entry re-save, those commits that correspond to a no-change situation wind up coming back with that weird |
In Sublime, with the collection folder open, for example, I can watch all of the files get touched/renamed — while watching |
Which makes me wonder... can/should Spock check the repo's change status (relative to the file/perceived change it's trying to commit) before firing a commit? If no change, don't commit... Like "is the repo changed? is/are the file/files related to this event in those changes? If yes to both: commit" |
No. Whether I re-order a few entries, or 30 entries, I can't reproduce the 18+ second hangtime you're facing. Still in the dark about what's causing that for you. I'd still like to figure out what's going on here, but I'm not convinced it's related to multiple commits specifically. Over here, I'm able to re-order 15 out of 30 entries, and Spock commits them all in well under 1 second 🤔 Again, we've implemented the ability to queue (via redis/etc.) Spock's event handling (likely coming in the next Spock release), so that the user won't feel any Spock-related lag. That's sidestepping the problem though. I'm still curious about the 18+ second hangtime, so I'll leave this issue open. Have a great weekend! |
Hey man — I'll do some more testing, but I'm pretty sure that when there is a change to make to the repo when the commit gets fired, they complete super quickly. It's when there isn't an actual change to the repo, but a Statamic event fires a commit anyways, that things seem to get funky. Basically it seems like whenever Spock starts logging commit failures, things get s-l-o-w-w-w. For a bit anyways. Watching the log with tail -f, you're not seeing it notch through each commit failure at like 1s+ per log message? |
WAITASEC — do you have yours set to push automatically? Maybe that's the exacerbating factor here... You have a great weekend too! :) |
Ah, that's it! A commit attempt (even with no changes to commit) is still quite fast, but pushing between each commit is slow because of having to connect to your remote. #33 will indeed improve this immensely. However, we'll get the queue update out to you soon, which I'd still recommend setting up because even a single |
Tagged Spock 2.2.0 with queueing (see docs on how to use) 🤘 Closing this issue, but will leave #33 open for when we have time to address that side of it. |
Was having an issue with re-ordering entries within a collection taking a long time (18s+) to complete, as well as intermittent long waits to save content, fieldset configs, etc. — eventually determined (with help from Erin over on the Statamic Discord channel) that Spock was the culprit. Removing Spock from my addons returned save/reorder performance to nigh-immediate execution.
Erin's suspicion was that something's maybe not getting queued properly? Bug perhaps?
The text was updated successfully, but these errors were encountered: