Performance Tuning Tips

Have any of your users ever complained that certain QuickBase operations take too long? We do get reports of this and once application managers go through the steps outlined in our "troubleshooting performance" knowledgebase article, a vast majority of the cases are the result of poor internet connections causing slow page downloads. Having said that, there are times where slowness can be attributed to applications and the amount of data they contain or the way they are setup and used. Here are some tips and tricks that should help you ensure you are getting the best performance possible out of your applications:

Minimize which fields are searched. Whenever someone attempts to find records through the "Find" menu and/or the "Find a record" menu item in a table’s menu, QuickBase needs to figure out which fields to search for the information. For example, if you use the Find menu and haven’t done anything to limit the search, QuickBase will search every field in every table across all records. The smaller the number of fields QuickBase searches, the faster the response from QuickBase. Here are some ways you can limit the number of fields searched:

    - Create a view that uses matching criteria that is setup to ask the user for the information they want to search for and then QuickBase searches that specific field only. For example, if your team generally brings up contact information by searching for names, you can have the view ask and then search for the contact name in that one field.

    - If you go to any field’s "properties" page, you will notice that there is a property in the "Advanced Options" section with the "Prevent the Find menu from searching this field" label. This property tells QuickBase whether it should search that field when users use the more general search mechanisms like the "Find" menu. The more fields that have this property checked, the better your performance will be.

Minimize embedded views. Each time a form is rendered with embedded views, QuickBase needs to do a fair amount of work to apply any security and view logic (matching, sorting, etc) for the embedded view(s). If an application has complex custom rules for roles and large numbers of records, it can improve performance if you cut back on the number of embedded views because each one has overhead associated with the logic required to display that view. Instead, if you can display one embedded view that shows all the appropriate records with sorting and grouping.

Archive Data. The more data in an application, the more work QuickBase has to do to apply any application logic you have built (e.g. custom rules, view criteria, etc). If you can automate the export and deleting of data so that applications only contain relevant information, applications will perform better.

Field Usage. Here are a few things to consider about the fields and their usage:

    - Prefer formula fields over custom columns which are specific to views. Formula fields have better performance characteristics than view custom columns.

    - Reduce the creation of summary and lookup fields: If you find that you do not need some formula, lookup or summary fields, delete them.

  • Soumya De

    Here is another performance tip. When you are creating views, try to put user input fields in the matching criteria BEFORE putting derived fields.
    User input fields are fields that you enter data into. Derived fields are fields like formula fields, lookup fields and summary fields whose values are “derived” from user input fields. Derived fields are more expensive to compute because the data needs to be “updated” for every request. The reason that including user input fields before derived fields is faster is that QuickBase can “skip” certain records without having to evaluate the values of the derived fields since the user input fields might already exclude the record from matching the query. In some cases, doing this can result in significant performance gains.

    Here is a short example:

    Suppose your view’s matching criteria looks like this:

    [A summary field] IS 10 AND
    [A text field] IS ‘Auto’

    Rewrite this to be:

    [A text field] IS ‘Auto’ AND
    [A summary field] IS 10

    For those records where the value of the “A text field’ is not Auto, QuickBase will not need to compute the value of the [A summary field].

    At some point, we will enhance our product so that the order will not matter but in the meantime, you can use this to speed up your query.

    Along these lines, try to exclude as many derived fields from your views as possible. In other words, even if you do not use the derived fields in your matching criteria, if they need to be displayed in the view, they need to be calculated. If you do not need to show these fields, exclude them from the view.

    [Reply]

  • Soumya De

    Here is another performance tip. When you are creating views, try to put user input fields in the matching criteria BEFORE putting derived fields.
    User input fields are fields that you enter data into. Derived fields are fields like formula fields, lookup fields and summary fields whose values are “derived” from user input fields. Derived fields are more expensive to compute because the data needs to be “updated” for every request. The reason that including user input fields before derived fields is faster is that QuickBase can “skip” certain records without having to evaluate the values of the derived fields since the user input fields might already exclude the record from matching the query. In some cases, doing this can result in significant performance gains.

    Here is a short example:

    Suppose your view’s matching criteria looks like this:

    [A summary field] IS 10 AND
    [A text field] IS ‘Auto’

    Rewrite this to be:

    [A text field] IS ‘Auto’ AND
    [A summary field] IS 10

    For those records where the value of the “A text field’ is not Auto, QuickBase will not need to compute the value of the [A summary field].

    At some point, we will enhance our product so that the order will not matter but in the meantime, you can use this to speed up your query.

    Along these lines, try to exclude as many derived fields from your views as possible. In other words, even if you do not use the derived fields in your matching criteria, if they need to be displayed in the view, they need to be calculated. If you do not need to show these fields, exclude them from the view.

    [Reply]

  • Regina Iverson

    How do you replace a misspelled name in a created field for more than one hundred files created in Quickbase?

    Can you use the Advanced Find feature? Or is there a Find/Replace feature?

    [Reply]

  • Regina Iverson

    How do you replace a misspelled name in a created field for more than one hundred files created in Quickbase?

    Can you use the Advanced Find feature? Or is there a Find/Replace feature?

    [Reply]