Matrix blocks causing slow saves and crashes on multi-site installs

[turnstylerj]

Description

What appears to be similar issues have been closed in this and Neo's repositories:

• Craft issue 9789
• Neo issue 494
• Neo issue 496

It sounded like people were able to reproduce with Matrix fields, so I wanted to provide a more stripped-down test case with a fresh install of Craft CMS and no plugins.

Steps to reproduce

1. Install Craft CMS
2. Create several sites on the install (I did English, Spanish, Portuguese, and French)
3. Create a Matrix field with several blocks (I did three blocks, each containing two plain text fields, all default options).
4. Create a structure with all default options and assign the matrix field to its layout.

Results

Creating a new entry in this structure and timing my saves as I entered additional blocks, I clocked the following times:

4 blocks: 3 seconds
8 blocks: 5 seconds
12 blocks: 7 seconds
16 blocks: 8 seconds
20 blocks: 11 seconds
24 blocks: 14 seconds
28 blocks: 16 seconds

The current homepage of the real site we're working on has 93 fields across 21 Neo blocks, and entries are taking upwards of 30 seconds to save/often resulting in a 503 error on our development servers. Given I'm able to repro a 16-second save time on a fresh install with 28 matrix blocks, each containing 2 plain text fields, it feels like this is more likely a Craft issue.

Please let me know if there's any additional information I can provide from my local test site. This issue is really slowing down development on the current site we're working on.

Additional info

• Craft version: 3.7.11
• PHP version: 7.4.12
• Database driver & version: MySQL 5.7.32
• Plugins & versions: N/A

[turnstylerj]

Possibly related to this? #9801

We have also noticed an uptick in updating search engine jobs in the task queue.

[zizther]

This seems similar and maybe some what related to an issue I posted as a Neo issue.

I think the issue I am seeing there is related to how Craft handles things, when saving an entry I presume it has to convert drafts, save a revision and the entry and it all takes time.

As this is something maybe more related to Craft, I wonder if there are any optimisations which can be made to help improve the performance of the entries being saved

[brandonkelly]

This should be drastically improved for the next release, for Matrix fields. Slightly improved for Neo & Super Table as well, and they should be able to fully match the improvements by following suit with a couple of the changes.

If you want to help test, change your craftcms/cms requirement in composer.json to "dev-develop as 3.7.11" and run composer update.

[carlcs]

We’re running into this as well on a multi-site install. Changes made in 95fc4df improved things, but it’s still much worse than 3.6. We’d like to update to 3.7, but don’t really want our client to tolerate save times close to 10 seconds.

We have a section which is enabled for 8 sites, the matrix field is very simple, one block type only, with an entries and a plain text field. The propagation method is set to “Only save blocks to the site they were created in”.

Messured the following performance for the post request when saving an entry in that section.

1. Open entry (specific entry has 13 blocks already)
2. Updated a text field in a single block
3. Wait for autosave to complete
4. Save entry

Version	Queries	Peak memory	Processing time	Compared to 3.6
3.6.18	2,083	22,725 MB	2,913 ms	–
3.7.11	9,493	77,079 MB	12,259 ms	4,2 x
95fc4df	5,508	47,396 MB	7,459 ms	2,5 x

I don’t know if this is related, but autosave is also slow when it saves the first time (~3000 ms), subsequent autosaves are quick (~500 ms).

[brandonkelly]

Yeah the change is purely focused on the time it takes to apply a draft’s changes to the canonical entry (whether the draft was normal or provisional), which we were finding to be far worse than the initial draft creation. It won’t help with the initial provisional draft creation (or revision creation), as that involves duplicating the entire entry and all its blocks.

You can opt out of the entire autosave feature by setting the autosaveDrafts config setting to false in config/general.php. As of 3.7.0 that also disables Live Preview, but I just brought it back for the next release. So going forward, with that setting disabled, you’d be looking at basically identical performance to 3.6, where the only time you’re going to have to wait for draft creation is when you open Live Preview.

[carlcs]

Ahh… that’s some interesting insights, thanks. You are right, disabling autosave brings me back to 3.6 performance. And as you’ve mentioned revision creation, I was interested to messure the overhead, and ran tests with versioning disabled for that section.

Version	Autosave	Versioning	Queries	Peak memory	Processing time
e4fec03	✓	✓	5,508	47.427 MB	9,837 ms
e4fec03	✓	–	3,780	40.397 MB	6,652 ms
e4fec03	–	✓	1,983	36.293 MB	3,974 ms
e4fec03	–	–	257	13.460 MB	919 ms

Seems like both features come with quite a cost (on multi-site installs), so good that it’s possible to opt-out.

[brandonkelly]

Yeah. I have an idea that will seriously improve draft creation performance for 4.0, but it’s a bit too involved to get in before then. (And won’t have any impact on revision creation unfortunately.)

Update: found a way to improve revision performance too 🎉 (#10589)

[brandonkelly]

Craft 3.7.12 is out now with those improvements.

[carlcs]

Nice, I hope your idea works out. And it’s also good to see 4.0 is not only about the big features.

Earlier, when I noticed the impact of the revision creation, I was thinking it may be nice to have it running in the background. Don’t know if that’s feasible and if you’d like to put it on the list.

[brandonkelly]

Yeah that could be a good idea, although it would be a little risky as the entry could be quickly re-edited before the job has a chance to run.

[brandonkelly]

Just wrapped up that performance improvement idea I had for Craft 4: #10577

[brandonkelly]

Revisions too now! #10589