Reply to comment
The QuickBase team takes performance very seriously. We constantly monitor the software and we use the information we gather to tune our software. We currently monitor our systems in the following ways:
* We have geographically dispersed systems that monitor QuickBase performance and report back to our operations team daily.
* We have an independent firm testing multiple QuickBase operations from multiple sites across the United States every hour.
* Intuit's data center team that monitors our machines, the internal network performance, and the bandwidth to and from our data center continually.
* Intuit workgroups extensively uses the same QuickBase you do, so our employees provide us with immediate feedback on performance as well.
If you are experiencing a slowdown or delays, we suggest you take the following steps:
1) Test your internet connection speed. You can do this by running the test at http://www.pcpitstop.com/internet/Bandwidth.asp. You can see varying performance of your connection throughout the day.
You can also check the overall health of the Internet at www.internetpulse.net/
Here you can see if there are latency or availability problems currently being experienced throughout the net.
Also, if a QuickBase page's header appears quickly before the page is completely displayed, then QuickBase has processed your request, but you are constrained by your internet connection and/or the speed of your computer.
2) Compare the performance of QuickBase to other Internet sites that use HTTPS encryption. For example, visit the Amazon.com account info page at https://www.amazon.com/gp/css/homepage.html and compare the performance of that page versus QuickBase. Make sure that the address bar contains "HTTPS" (not HTTP). Many reported QuickBase performance issues are due to customer firewall problems that affect all HTTPS sites.
3) Monitor performance to help isolate the issue. Pay attention to:
- When delays happen – specific days or times of day.
- Delays using a specific QuickBase application, and not others.
- Specific actions that seem to take longer
- Specific groups or roles that experiences longer delays
4) Review your application.
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:
a) 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 report 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 report ask and then search for the contact name in that one field.
- You can exclude certain fields from being included in Quick Find searches. Each field has a property called “Include this field while searching.” By default, QuickBase searches every field; however, if you uncheck this property for any field, you can tell QuickBase to skip over this field when performing a Quick Find or any search that uses <Some field> as search criteria.
Note that you can access this property for an individual field on its field properties page. You can also exclude several fields at a time using the field listing page. (To learn more, please see our Prevent QuickBase from Searching Fields help topic.
-You can also exclude entire tables from Quick Find searches using property called "Include this table while searching." This property lets users choose whether QuickBase should include the table in Quick Find searches. Excluding one or more tables from Quick Find searches forces users to use the Find Record functions from the table menus and can significantly improve performance. Combining this with the suggestions above and below can be very effective.
b) Minimize the number of Embedded Reports
Each time a form is rendered with embedded reports, QuickBase needs to do a fair amount of work to apply any security and report logic (matching, sorting, etc) for the embedded report(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 reports because each one has overhead associated with the logic required to display that report. Instead, if you can display one embedded report that shows all the appropriate records with sorting and grouping.
c) 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, report criteria, etc). If you can automate the export of data so that applications only contain relevant information, applications will perform better. Read the How can I manage my application's tables? article for more information about strategies for archiving data.
d) Field Usage. Here are a few things to consider about the fields and their usage:
- Prefer formula fields over a report-specific custom column. Formula fields have better performance characteristics than a custom column in a report.
- Reduce the creation of summary and lookup fields: If you find that you do not need some formula, lookup or summary fields, delete them.
e) Limit Use of Custom Rule Permissions
When creating roles, the use of "custom rules" (aka "custom permissions") significantly slows an application's report generation performance. This is especially true when the custom rule depends on a formula, summary or lookup field.
f) Design Reports for Speed
When you are creating reports and filtering records, filter for user input fields BEFORE filtering for 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. Including user input fields before derived fields is faster because 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 report'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 reports 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 report, they need to be calculated. If you do not need to show these fields, exclude them from the report.
5) If you have gone through the above steps and you are not able to isolate the problem any further, then please help us understand your specific situation by submitting a support case and answering the questions stated above.