We are excited to continue our Ask Me Anything series and to be inviting Harrison Hersch, a senior product manager here at Quick Base, to join us on the Community to talk about his work on Perfo...
Published 6 years ago
Version 1.0
Blog Post
Just a anecdotal comment on an app I just did as sometimes users wonder what the performance will be for an app with high record counts. The typical response on this forum and from support will be the stock answer is "well it will depend on the complexity of your app and especially on the # of summary fields which need to be calculated to display the report or record or dashboard".
In my app there is one main data feed table which is a child to several other Parent tables. It has 1 million records. The individual size of these child records is small, with not very many fields so the table is only 33% "full" despite the 1 million records
Each parent table has a small handful of summary fields but these summary fields on some cases are themselves rolled up to higher level Grand Parent records.
The app was specifically planned using Sync Tables for various Parents to be sure that the app is isolated from the rest of our apps.
The app takes a good 30 seconds to wake up if it has been sleeping quietly, but once it loads to memory the response time for a Dashboard which requires the app to summarize these 1 million records on three different reports, is about 5 seconds. That is quite acceptable to our users. Since large Excel workbooks also can take a long time to open, we explain that to our users and they understand that the data in the app needs to load to memory, same as Excel - so they have their expectations set for when they wake up the app for the first time in the day.
Other screens which require the app to draw data from these 1 million records, but only need to extract and summarize data for just 1 customer load in under a second or two.
I think that this app performs well because it was designed knowing that Performance was a risk and the # of summary fields is reasonable. There were other possible designs for the data feed level of aggregation which would have resulted in higher record counts for that million record table, but we estimated that if we kept the record count to about a million without too many fields that we would not hit the table limit of 500 MB and the app response time would be OK. I was pleased to see that it performs quite nicely.
In my app there is one main data feed table which is a child to several other Parent tables. It has 1 million records. The individual size of these child records is small, with not very many fields so the table is only 33% "full" despite the 1 million records
Each parent table has a small handful of summary fields but these summary fields on some cases are themselves rolled up to higher level Grand Parent records.
The app was specifically planned using Sync Tables for various Parents to be sure that the app is isolated from the rest of our apps.
The app takes a good 30 seconds to wake up if it has been sleeping quietly, but once it loads to memory the response time for a Dashboard which requires the app to summarize these 1 million records on three different reports, is about 5 seconds. That is quite acceptable to our users. Since large Excel workbooks also can take a long time to open, we explain that to our users and they understand that the data in the app needs to load to memory, same as Excel - so they have their expectations set for when they wake up the app for the first time in the day.
Other screens which require the app to draw data from these 1 million records, but only need to extract and summarize data for just 1 customer load in under a second or two.
I think that this app performs well because it was designed knowing that Performance was a risk and the # of summary fields is reasonable. There were other possible designs for the data feed level of aggregation which would have resulted in higher record counts for that million record table, but we estimated that if we kept the record count to about a million without too many fields that we would not hit the table limit of 500 MB and the app response time would be OK. I was pleased to see that it performs quite nicely.