Since my first days of using Skuid this has been getting worse.
I’m having a lot of issues aggregating or querying on normal model, using skuid on the native object: Tasks
The only reason i can see if the # of records we have in tasks (almost 300k), Could that be it?
But even if filtering to reduce the data returned, very often i get timed out errors.
Is there anything I can do to make it work or improve performance?
I tried all the basic steps I could find on this forum.
Strange. I work in tasks a lot with some custom activity fields and process builders and have never had a problem. I don’t have 300K, but I have many thousands.
Yes, querying against 300K tasks could definitely be causing your problems. Take a look at the section of Improving Query performance of this tutorial to see if any of the suggestions help …
The task model is a beast anyways because of the polymorphic WhoID and WhatID fields (point to multiple objects.) We built some reference custom fields on our task object back to common objects (Related Account, Related Opportunity, Related Case) and populate these fields along with the WhatID when tasks are created (via Skuid, of course.) These fields are then indexed and querying on that value, instead of the WhatID, has improved our performance a ton.
Thanks for sharing how you work around the beast, Chandra!!!
Karen thank you, but had already went trough this help guide.
1 thing I should have maybe mentioned in case it makes a difference:
I have 4 different models based on Task Object on the skuid page and all 4 are aggregate models.
Even querying only 1 of them most often times out.
And Chandra thank you for suggestion I’m actually in the middle of trying it atm
Chandra , may I ask roughly how many task record your org has? Would like to know if your solution worked for something similar to mine (almost 300k records)