I know this is going to be a how longs a piece of string type question …..
Given a relatively similar record set size (lets say prod is around 10% larger than UAT at ~ 50k records)
Why would the record search performance on Live be so much worse than UAT ?
Like the difference is 5 seconds vs 30 seconds …. something seems wrong !!!
This is with all the performance cogs turned up on production too at the expense of the other environments.
Could it be the history of the objects (fields etc) ?
Live is significantly more used …..
Yes there are a few subsets in play - but removing them doesn’t seem to make a significant difference.
According to the performance tab in monitor studio its the actual record search taking the time, not subset recalcs.
Also and maybe a red herring - why does one of my subsets seem to be run twice [the subset constraint] ? This is happening in all environments so its not unusual to production but it looks weird to me.
It might be our weird setting for Database Memory Boost (in UAT) [Custom value] ? which was set for us quite some time ago by Netcall when we were having some data migration issues and never reverted.
I’m wondering if this is skewing things because it looks like UAT is using 2x as much memory as production yet is not used all that much on a daily basis.
At the very least I’m going to rule it out 
before moving on to other things ….
I’m still confused by the double record search though with the same subset recalc - that just looks wrong to me.
This seems to have started with the 2025.2 upgrade about a month ago. At least that’s when the client started having a little moan !!!
Have you got any composites or agregates on the page? Since I believe those are calculated in real time with no caching that may be impacting things so if they can be copied into properties that may improve things.
It may also be the increased load from lots of people accessing the data simultaneously. Presumably on test you only had a small number of people accessing?
I’ve noticed the double subset search before. Sometimes I think it’s something valid that isn’t obvious (a subset restriction on a relationship or buried in the settings of a single field) but I’ve also definitely noticed it triggering searches multiple times in unusual circumstances, particularly when using the “Advanced” settings relating to triggering/refreshing on page events.
It does look a bit like its one of my subset restrictions - its a general subset and given the number of records it should probably be an event driven one instead to at least reduce the subset recalc potential.
Still cant really explain the sheer difference in Live vs UAT given similar ish records but maybe you are right - it could be the subsets coupled with the number of users.
Will have to play around some more !!!
Looks like I may have spoken too soon 
I think our UAT and Prod are in fact exhibiting the same issue - which is good from a consistency perspective.
I mean I still have the issue to resolve but that should be straightforward enough now.
Yeah unfortunately that hasn’t been the case.
Even a move to using event driven subsets does not resolve the page load problem.
Not sure what to try next to be honest.
I’m also still struggling to understand why my specific subset is being run twice - if I could solve that the load time would halve as they are run linearly.
I can confirm this subset is NOT configured twice (or more in the page). If I remove it in one place on the page - both disappear in the metrics of the performance monitor.
Would an applied record search filter be a better option rather than a page subset filter ?
I’m guessing not if all that filter is going to do is use the same event subset anyway ?
Without any filter the page (paginated to 50 rows) loads the 48k+ records in less than 2 seconds - with it applied its ~ 30 seconds.
Going to raise a ticket to netcall shortly as there is not much deeper “I” can go with this without more information.