I see that in the comparison between the “Core” and “Enterprise +” plans, resource allocation for performance is rated as LOW for Core, and as HIGH for Enterprise +.
I would like to ask if anyone has real, quantifiable, experience in the performance difference between the two plans.
We have been carrying out some performance testing on our apps recently, for example creating copies of apps with the tables only, no actions, no virtual columns, no ref’s and testing loading and sync times based on the number of table, rows, etc., and then slowly adding back some virtual columns etc. to measure the affects on performance.
I would like to hear if anyone has some comparisons in performance between Core and Enterprise+.
Quantifiable? I guess that depends on what you mean. But I think I can help here.
First, there are slight improvements going from Core to Enterprise in that the number of parallel processes increases from 2-3 to 10. This helps mostly for very active apps where either many multiple users are submitting rows at the same time OR a single user performing data entry in rapid succession. But adding parallel processes doesn’t really help with a single user experience in Sync times or app transitions - e.g. from one view to another. Those performance improvements come when migrating to a database.
I consult on moderately large apps which started out on Google sheets and then migrated to Big Query. These apps are used by about 110 users who add about 1000 rows daily. These additions are cumulative and so add up over time.
Initially, one of the apps was experiencing very slow Sync time at around 30 seconds while on Google sheets. We were able to adjust implementations (e.g. remove virtual columns) and apply Security Filter to reduce downloaded data to get that down a bit but it was still in 20-25 second range. We eventually decided to migrate to Big Query which made a HUGE difference.
The migration itself helped only slightly but the real improvements came when we tailored our Security Filters so they would run on the database side. If you are not aware, when you use a database, AppSheet will, if possible, modify the Security Filters to run on the database. It is faster and results in less data brought down in the AppSheet servers. We needed to adjust some Security filter implementations to make that happen. For instance IN() statements did not translate directly into SQL - at least on Big Query. We converted the IN() statements into a set or OR conditions since we had finite list of items.
Additionally we made some user specific tweaks to further reduce Synce times and amount of data downloaded per user. The app has been enjoying Sync times in the range of 5-6 seconds for well over a year. This is all entirely possible because of database usage through the Enterprise plan.
I can answer any more specific questions you might have.
@WillowMobileSys thank you for your insights on this. For a long time we struggled to understand why moving to a database would improve sync times, but if with a database the security filters run on the database side, then that finally explains it.
I have another related question if I may. How do you handle use cases where the user needs to access older data? For example, lets say we have an Orders table, and an Order Items table. Let’s say our security filters are built to only load open/upcoming orders, and to not load closed/completed orders.
Now imagine the user wants to view the last 10 orders from a certain customer, or all the orders from a certain customer over a certain time range. How would you do that? Would you use some user defined variables in your security filter, meaning the user would need to sync again to load that data? Or would you achieve it some other way?
There are many ways depending on how your users interact with the system, the number of customers and the expected number of orders per customer. Can you elaborate?
Do all users enter orders AND also need to see history? Or do only certain users deal with history?
How many customers and how frequently do they place orders?
How large are the Orders - i.e. avg number of items ordered each time?
Not all users need to see the older orders all of the time, but any/each user may need to see the older orders for a specific customer, or for a specific item type from all customers, for a specific date range.
Imagine a customer calls and says, remember I had those items from you one year ago, to a certain location, I would like to do a repeat order. Also, can happen that we have a quiet period for certain items, and we want to look up the orders we had for that item type this in the same period the previous year. So there are varying use cases.
Currently we might add 1000 orders to the order table per month, and to the Order Items table, typically we could add anything from 1 to 20 rows to that table per each row to the Orders table. However, the app needs many other tables to support the addition of rows to those 2 tables, such as Customers, Customer Contacts, Items, Item categories, etc. etc. Also, the rate at which we are adding rows is growing as the business itself is also growing rapidly, so we are looking to improve our architecture to enrue it is scalable.
Happy New Year @WillowMobileSys . I would just like to ask if you had any further thoughts on this considering the additional information below.
Kind regards.