Discussions

 View Only
  • 1.  Try to understand how resources are shared

    Posted 02-18-2022 14:34
    Edited by Mike Tamoush 02-18-2022 15:54
    I know that when you use cross app relationships, resources are shared, where as if something is populated via Pipelines or a Sync table, they are not shared resources.

    However, a table to table import may share resources, and I believe even something like a report link will share resources. My question is this:

    Are the resources only momentarily shared (so for example when someone is looking at the report link, or the table to table import is running at that moment in time the resource is tied up), or is it more significant than that?

    I've had it explained to me that in a sense, my app is being run in one of QuickBases' 'lanes', but if I have cross app relationships, now all my apps 'travel together'. If I have a table to table import, or just a report link, have I now tied all those apps together as well? Does having a single report link do as much damage as a full cross app relationship? Same question for table to table import, etc...

    ------------------------------
    Mike Tamoush
    ------------------------------


  • 2.  RE: Try to understand how resources are shared

    Posted 02-18-2022 15:45
    Edited by Mark Shnier (Your Quickbase Coach) 02-18-2022 15:47
    Having gone through some performance pain in some detail with another client and with the assistance of a QuickBase expert this is what I believe to be true. We asked those exact same questions.
    1. Across app relationship links those two apps into the same server process. 
     
    2. A table to table import links those two apps into the same server process at the moment the import is run and that will persist until the apps go to sleep at night. When they go to sleep at night and then  they wake up in the next morning they will once again load individually, unless of course you run the table to table import then they will join together again.

    3. A simple report link will definitely link the two applications. I cannot say for certain if they will only be linked when a particular record is displayed but I suspect that is the case. I suspect it is like a table to table import so that as soon as the first person runs any record with a  report link then the apps will bind together and it will stay that way all day until the apps go to sleep at night.   

    4. I do know that the only way to separate apps is to either wait for them to go to sleep at night, or a senior technical person at Quickbase does have the ability to manually force the apps to reboot. I don't even know if regular support people have the ability or the technical knowledge to do that - force a reboot of apps.


    ------------------------------
    Mark Shnier (YQC)
    mark.shnier@gmail.com
    ------------------------------



  • 3.  RE: Try to understand how resources are shared

    Posted 02-18-2022 15:51
    Oh well that's a bit of a bummer about the table to table import. So a pipeline or Sync is the only true way to keep apps on different servers and likely increasing performance, unless the table to table import only runs once a month or something insignificant. Though, perhaps I can run the import at like, 11pm each night?? That would probably work? Then they link, and unlink an hour later.

    ------------------------------
    Mike Tamoush
    ------------------------------



  • 4.  RE: Try to understand how resources are shared

    Posted 02-18-2022 15:56
    When I say the apps go to sleep, by that I mean after a certain time out which I think is around 30 minutes but I really have no idea, they take apps which are sitting in live core memory and release that expensive memory in favour of other apps.  So if you run a table to table import when the system is empty of users like at midnight then it will probably go to sleep shortly after that. But if you have some keener like yourself doing development work in the middle of the night then they won't have a chance to go to sleep.

    ------------------------------
    Mark Shnier (YQC)
    mark.shnier@gmail.com
    ------------------------------