The title says it all. I’ve observed some baffling behavior. In both cases below, I’m adding the exact same sync table (which has only two rows):
1. Adding the table to a nearly empty doc (91 KB) and hitting refresh:
“Starting update…”: 0–1s
“Getting updates from [pack name]…”: 3–10s. However, my server logs show the pack only hits my API at the very end, and the actual query/response takes no more than 0.5s. No idea what Coda is doing before that.
2. Adding the table to a large doc (220.1 MB) and hitting refresh::
“Starting update…”: 35–55s !!!
“Getting updates from [pack name]…”: 3–10s. This doesn’t seem to depend much on doc size.
The “Starting update…” phase is slow on both the first run and consecutive runs, so it doesn’t seem like a cold start issue. The same behavior is also observed when sending edits.
I’m just speculating here, but does a pack run involve Coda somehow loading the doc into a headless server environment?
It’s such a shame to spend so much time developing a pack, only to find that it’s practically unusable in real-world docs.
Hi @Nad - I can’t speak with complete certainty as I’m not deeply familiar with the codebase, but my understanding is that sync tables use the same infrastructure as automations. Does that doc have a lot of automations running? I would suspect that small docs with lots of automations may also see the same delays.
Thanks for looking into this. To clarify - the 220.1 MB doc didn’t have any automations in place. I also tested the same sync table with another large doc (~240 MB) and observed the same delays.
I appreciate you chiming in even though you’re not deeply familiar with that part of the codebase. Would it be possible to get a definitive answer on whether this behavior is by design or a bug? This is pretty critical for me in deciding whether to keep investing time in building internal packs - if large docs will always have up to 60s delays just to send a row edit, it’s a significant limitation.
Hi @Nad - I asked an engineer familiar with the infrastructure, and they said that the behavior you are observing is expected. Like other automations, syncs wait for the doc to “snapshot”, which is a regular process by which individual edits are merged into the document model. This snapshotting process takes longer for larger docs, and hence it takes longer for the sync to start.
I would like to add some insight we have gotten over the years. It doesn’t specifically help to solve the delays that @Nad has to deal with, but it might be useful for people that are trying to find best practices when building their doc. I was triggered to write this by the reply from @Eric_Koleda :
Like other automations, syncs wait for the doc to “snapshot”, which is a regular process by which individual edits are merged into the document model. This snapshotting process takes longer for larger docs,
We use a large doc to monitor certain operations, adding a couple hundred of rows per day. Generally we are using up to 8 devices that each need to show the updates done on any of the other devices as quickly as possible - therefore a speedy snapshot process is very important for us. Our devices are connected through mobile internet connections.
Our doc size varies a bit (we just did an optimization), but can easily reach around 175 MB. It has hundreds of tables with the largest table currently containing close to 40K rows. Our CFL logic was adding a row to this table for every operation that took place. The table is continuously monitored by other tables where filtered rows or data is processed. At some point the document slowed down to a point where it might take 10 to 15 secondes for changes to be reflected on other devices, which was not acceptable for our situation. Although I don’t have a clue as to how the snapshotting works or what triggers it, I had a gut feeling it was the table updating that slowed us down.
Our solution was to build some helper tables storing the daily operations (as mentioned earlier: a couple hundred rows per day) and updating the main table with this data once a day (and delete all the rows in the helper tables). We had to adjust some of the monitoring tables to now reflect the data from the big table AND the data from the helper tables, but the end result is that all devices sync within a second of any update (often, is feels like the updates are immediate). This makes me believe the snapshotting of changes and updating the document on the other devices is not the bottleneck. We are located in Europe and theses updates cross half the world back and forward really fast.