Skip to content
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

Slow preloading of Replicator Field meta data when importing many fieldsets #8395

Closed
o1y opened this issue Jul 3, 2023 · 8 comments
Closed

Comments

@o1y
Copy link
Contributor

o1y commented Jul 3, 2023

Bug description

When creating a "Page Builder" using a combination of a Replicator and Bard Field with various imported Content Sets, the Replicator Field tends to load slowly. This is especially in situations where sets need to be nested, for example when creating a columns/layout or accordion/collapse set. This results in a performance problem as the Replicator Field needs to preload the same fields over and over.

I have identified two possible causes for this issue:

  1. The toPublishArray() method is being executed multiple times for the same fields.

    cms/src/Fields/Fields.php

    Lines 147 to 150 in 62451f1

    public function toPublishArray()
    {
    return $this->fields->values()->map->toPublishArray()->all();
    }

  2. The preload() method of the Replicator Field is loading the same metadata multiple times for the same config:

return [$set['_id'] => (new Fields($config))->addValues($set)->meta()->put('_', '_')];

I understand that this is a specific case that mainly affects those building Page Builders, like me :) However, I have noticed similar performance challenges mentioned on Discord, and we have also encountered them in our project.

How to reproduce

Logs

No response

Environment

Environment
Application Name: Statamic
Laravel Version: 10.14.1
PHP Version: 8.2.5
Composer Version: 2.4.4
Environment: local
Debug Mode: ENABLED
URL: statamic-replicator-performance.test
Maintenance Mode: OFF

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: log
Cache: statamic
Database: mysql
Logs: stack / single
Mail: smtp
Queue: sync
Session: file

Statamic
Addons: 0
Antlers: runtime
Stache Watcher: Enabled
Static Caching: Disabled
Version: 4.9.2 Solo

Installation

Fresh statamic/statamic site via CLI

Antlers Parser

None

Additional details

No response

@o1y o1y changed the title Slow preloading of Replicator Field meta data when importing lots fieldsets Slow preloading of Replicator Field meta data when importing many fieldsets Jul 3, 2023
@paul-hph
Copy link

Same here.
It takes up to 5 seconds when an input is clicked until we are able to actually type something. That makes the CMS unusable.
(PageBuilder with lots of repeater fieldtypes on 4.41.0)

Please Fix!

@o1y
Copy link
Contributor Author

o1y commented Dec 20, 2023

@paul-hph Do you have a performance issue in the frontend when clicking through the replicator sets, or is it slow when loading the initial entry from the backend (php-side)?

@paul-hph
Copy link

Both. 20 second page load. 12 seconds to be able to edit a field.

@paul-hph
Copy link

Slwo.mp4

@tobimori
Copy link

I'd say I can reproduce this in "small". We only have max 15 replicator sets per page and the more there are, the longer the page load is. Larger pages (10-15) tend to load around 5-10 seconds TTFB and smaller pages (<10 sets) are around 3-5 seconds.

@o1y
Copy link
Contributor Author

o1y commented Dec 20, 2023

@paul-hph This seems mostly JS / Vue related and possibly not related to this issue, which is about replicator metadata in php. You page was loaded in about 3-4s (TTFB), which this PR could improve #8397. I would rather open a new issue for the JS part.

Are you using lots of Bard sets? Then @jacksleight did some performance checks here in #8716 (comment)

@tobimori
Copy link

I just tested your PR @o1y - and I noticed the following changes on some pages:

  1. 3.43s -> 1.74s
  2. 3.96s -> 1.95s
  3. 4.13 -> 1.79s

regarding TTFB times

@o1y
Copy link
Contributor Author

o1y commented Jun 13, 2024

Fixed in PR #10280

@o1y o1y closed this as completed Jun 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants