Speed Up Table Filters

BenBen
edited September 1, 2016 in Questions
We have 3 models, 2 are aggregate for use with Charting and the third is a basic chart for pulling specific report related data. We have a Tab Set and use the Picklist function. The two charts draw pretty much immediately, but the table takes about 30 seconds to display. It is obviously using a selection criteria that returns 66 records from a thousand or so. The we have a filter that allows the user to filter by Category. If you change the filter is takes a minimum of 50-60 seconds to re-display the information. I know that using the aggregate model will allow SF to do the processing and basic brings the record set down to the end user, but this is quite un-usable. Can you have an aggregate model and still bring fields into the table that are not defined as aggregations?

Comments

  • Rob HatchRob Hatch 💎💎💎
    edited September 1, 2016
    It sounds like your query performance is suffering.  I'd use this document from Salesforce to look at ways your SOQL query might be improved.  You might also contact Salesforce and ask that additional fields on your object be indexed to increase performance. 
  • BenBen
    edited April 22, 2015
    I'm not thinking that is the problem considering the number of documents being returned, a subset of 68 out of about 6800 and SF performance indexing performance really becomes an issue when you hit much higher thresholds. In Chrome, I am see the "Transferring data from ..." which takes forever when using a SKUID table but when I load the same SF report with the same filters and data, it takes literally 2-3 seconds.
  • Rob HatchRob Hatch 💎💎💎
    edited September 1, 2016
    Here is a test.  In your skuid page open the browser console.  Type the following javascript command. 

                skuid.$M('YourModelName').soql

    This will give you the actual soql that skuid is running. 

    Then open the salesforce developer console and run that query in the query editor. 

    If there are substantial differences in performance we'd like to know about it.  If both queries take a long time its a problem at salesforce.   Standard layouts and reports use substantially different technologies (smoke and mirrors) to present data quickly. They are not reliable comparisons.  Though I do wish we could leverage them in some way.... 
  • BenBen
    edited April 22, 2015
    When I refresh the page, it takes about 240 seconds to get the following, and 200 records are displayed. If I click the "Load More" button, it takes about that long.
    The following is what I get from the Browser Console:
    "SELECT RecordTypeId,RecordType.Name,Category__c,Sub_Category__c,Service__r.Name,CaseNumber,Closure_Status__c,Closure_SubStatus__c,Resolution_2015__c,Description,Id FROM Case WHERE (Service__r.Use_in_Reports__c = true)AND(ClientNum__c = 'XXXXX') LIMIT 10000"

    When I put that in the developer console in SF, I get back the results in 2 seconds and it returns 994 records.
  • Rob HatchRob Hatch 💎💎💎
    edited September 1, 2016
    Would you mind giving us login rights to your org so we can take a look at what is going on?   Here is how: 

    1. Use this tutorial to give us login rights: http://help.skuidify.com/m/getting-started/l/182412-getting-help-how-to-grant-skuid-login-rights-to-...

    2. Then send an email to [email protected]  with the following information: 
    - Your org Id 
    - The name of the page where the problem is happening 
    - The steps required to reproduce the problem.  

    We'll see what's going on...

  • BenBen
    edited April 24, 2015
    Sent that information two days ago and was wondering if you had a chance to look at it.
  • Rob HatchRob Hatch 💎💎💎
    edited September 1, 2016
    We've been just a bit busy..  We'll look at this today.  Sorry. 
  • BenBen
    edited April 27, 2015
    Any news? 
  • Rob HatchRob Hatch 💎💎💎
    edited September 1, 2016
    Here is some further information from Ben:  (Sent via email)
    Well I am not quite sure what is going on but I had the table set to “Apply Filters and Search Immediatley” to false. When you bring up the page, and select the Cases table nothing shows. That most certainly is quick. I set that value to True, and when in the page designer, Preview, the table is almost instantaneous. When logged into our Community Site and access the page via a tab, it takes 2 minutes to load the data, each time you select the tab or a filter.
    Why would there be large differences in load time between an admin "previewing" a skuid page, and a community user viewing the same page.  Sharing rules.  The admin has a "view all records" permission and therefore Salesforce does not need to evaluate sharing rules for each record.  But when the community user asks for the data,  Salesforce has to evaluate the sharing rules on each record. 

    So, this makes it even more critical to reduce the number of records requested in the model, and base conditions on indexed fields. 
  • BenBen
    edited April 28, 2015
    Still not convinced. Although the whole Admin theory seems to make sense, we have done a ton of testing and really don't think it has anything to do with the Sharing and how long it takes SF to serve up the records. We have 2 visualizations that use similar selection criteria and are accessed via a community user and the data is returned immediately. We have reports that the data is returned immediately, and we have standard SF views that are returned immediately. We even went so far as to add a new text field designated as an External UID which will then get indexed by default by SF and made that the only field in the selection on the Model, same performance. We use another product for Grids/Tables and when creating and viewing them, the data is instantaneous. Wasted way too much time on this but if this is not about how our page is setup, and I am assuming it is not based on the above, and we have a single condition in the model and this is the type of performance, then using a table in communities is simply not an option due to the performance. 
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!