What does it mean that Quickbase is single threaded ?
Is this single threaded nature by App (or by instance?) or quickbase in it's entirety ?
Forum Discussion
1. Does single threaded mean that only one request can be processed at any given point in time ? i.e if one user is loading a report while another is submitting a form, are they sequenced one behind the other ? YES - if it's some kind of killer report that takes 10 seconds to calculate, then for those 10 seconds, other users are frozen. Of course I'm talking about the time to process the report. Once the data is calculated to be sent, it does not matter if the user is on an ancient dial up modem with no speed - that time is not counted.
2. What are the common pitfalls in which this single threaded nature causes performance concerns ? The main pitfall is less with a single app, I mean you generally gotta do what you gotta do to get the app working. But the main pitfall (and this was the case for my main client who has 10 years of app development - mostly by me and before we had Sync tables) and a spider web of connected applications is that they now load as one giant single threaded eco-system. So there are probably 20 large apps all interconnected and 250 users. Actually the performance is pretty good - EXCEPT that it is mission critical to update the main app with updating 30,000 Open Order lines and say 15,000 Orders every few hours. That is done with QuNect every 2-3 hours in the day and the eco-system slows down during those reloads. We use some kind of feature called chunking with those updates so that the update process does not hog all the QuickBase cycles. It does a batch of a few thousand or hundreds of records, takes a pause and then starts again, so that way other users can get requests queued up and they maybe wait 10-15 seconds but at least they are moving.
3. Can someone confirm for sure if the report link too causes apps to be connected ? It feels like that should not be the case. That is my understanding from Support when I as trying to unhook app from the eco-system. They have diagnostic tools to tell if an app is connected to other apps. You an put in a support ticket and update this post here when you get an answer.
Performance is inversely related to # of concurrent users times # of records times complexity of summary fields being used on reports and records. The "times factor" is not scientifically knowable, it is mainly through experience.
If you have tables with a few thousand records, there will not be any problems. If you have tables with 200,000+ records involved with summary fields a records, then you have to be very careful about Performance pitfalls.
2. What are the common pitfalls in which this single threaded nature causes performance concerns ? The main pitfall is less with a single app, I mean you generally gotta do what you gotta do to get the app working. But the main pitfall (and this was the case for my main client who has 10 years of app development - mostly by me and before we had Sync tables) and a spider web of connected applications is that they now load as one giant single threaded eco-system. So there are probably 20 large apps all interconnected and 250 users. Actually the performance is pretty good - EXCEPT that it is mission critical to update the main app with updating 30,000 Open Order lines and say 15,000 Orders every few hours. That is done with QuNect every 2-3 hours in the day and the eco-system slows down during those reloads. We use some kind of feature called chunking with those updates so that the update process does not hog all the QuickBase cycles. It does a batch of a few thousand or hundreds of records, takes a pause and then starts again, so that way other users can get requests queued up and they maybe wait 10-15 seconds but at least they are moving.
3. Can someone confirm for sure if the report link too causes apps to be connected ? It feels like that should not be the case. That is my understanding from Support when I as trying to unhook app from the eco-system. They have diagnostic tools to tell if an app is connected to other apps. You an put in a support ticket and update this post here when you get an answer.
Performance is inversely related to # of concurrent users times # of records times complexity of summary fields being used on reports and records. The "times factor" is not scientifically knowable, it is mainly through experience.
If you have tables with a few thousand records, there will not be any problems. If you have tables with 200,000+ records involved with summary fields a records, then you have to be very careful about Performance pitfalls.