Each repeater action takes a long time (livewire/update)
Since each action with the repeater is accompanied by a call to livewire/update, in my case it takes more than 10 seconds for each action (adding, deleting, moving), which is absolutely unusable.
Moreover, depending on the number of fields in the model, this time can increase up to 30 seconds.
I probably missed something during the architecture. Because a custom field storage structure is used through the EAV model (similar to fields in WordPress).
And in general, instead of updating a separate field, the entire page for editing the model is received in the snapshot and in the response.
I don't need reactivity here at all, so how can I limit livewire to a simple action - adding a new field in repeater, without checking snapshots? Or is the only solution to create a custom component?
Thank you for your attention and help.
12 Replies
That should not take 10 seconds, more like a few hundred ms.
Do you have Laravel Debug bar enabled?
Does your EAV have indexes?
I don't need reactivity here at all, so how can I limit livewire to a simple action - adding a new field in repeater, without checking snapshots?The data is rendered on the backend though. So no way around it.
No, Laravel Debugbar is disabled.
And yes, my EAV have indexes.
What’s strange is that the editing page loads instantly with any amount of data, only repeater actions with livewire/update take a lot of time.
When you check the dev tools: is it the page loading that is slow? Or the diffing of the Dom?
Waiting for server response only.
Ok, I would adivse you install telescope, then on clicking add look for that request, telescope will show you everything and everything that is slowing it down.
According to the telescope, everything is fine, queries to the db do not slow down.
Path /livewire/update
Duration 8477 ms
Memory usage 26 MB
Query
80 queries, 72 of which are duplicated. Duration
93.81ms
Hm. It's weird that the second requests takes so much longer than the first one
8477 = 8.47s
I'd be looking at the qurieis 72 duplicated... which onces are taking so long....
What is the query you are using?
I've got a feeling the second is a different query which isn't indexed compared to the first one since the first is a page load, opposed to an update.
Also... what stack are you on?
The queries are taking 90ms though 😉
Yep which is the total of the them. But why are there so many duplicates...
@matsesh I've just had a thought, can you ensure the options are in a closure? Can you provide the repeater code?
I've got a feeling you have put a model select for the options and that's why you are having so many duplicates. Filament has a funky issue when not using closures on the options for a select for instance, it loops through them. If you use a closure, it returns them so that would to me explain your duplicates and performance issues.