Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
remote checkpointing generates a high number of requests (regression) #4543
PouchDB 5.0 changed the way that remote checkpoints are saved, using a POST to _bulk_docs instead of an explicit PUT to the checkpoint document. A side effect of this is that each POST request generates a preflight (OPTIONS) request when CORS is used, therefore doubling the number of requests used for checkpointing.
When testing in Chrome, PouchDB 4.3 would generate a preflight request for the first PUT request to a checkpoint but subsequent PUT requests do not require them.
I'd suggest reconsidering the use of _bulk_docs when only one document is being updated and/or reviewing the default frequency of checkpointing.
For comparison, replicating http://188.8.131.52:15984/movies-demo (~5000 docs):
I see two options:
I prefer the latter, since the only benefit was reduced code. (We can keep multipart out as well; it's not buying us much.)
Side question: why do we need the remote checkpoints at all? I think it makes a lot more sense for clients to keep track of their own checkpoints, and it avoids weird situations with read-only databases.
It wasnt just reduced code, it is cleaner code with less bugs due to duplication, we could change the behaviour back to sending PUT requests, but only if we refactor to avoid duplicating the parameter handling.
I think there is a 3rd option, reintroduce browser sniffing, if its only safari that has the caching POST and IE with GETS, removing the nonce from will allow us to use preflight caches more than we do or even did with PUT's (aside from in those browser for those requests)
We do remote checkpoints because it was a very common bug that once people wiped out their databases then replication was broken, it was filed a lot of times in various configurations (we used to only store remote, then only local etc)
@daleharvey I would be down to add browser sniffing. IIRC, IE caches the GET but not the POST; I know Safari caches the POST but can't recall if it also caches the GET. I believe our tests will catch it if it doesn't. You might need to run the map/reduce tests in Safari/IE to be sure; I mostly recall seeing it from the POST to
This sounds totally reasonable to me (you destroyed your DB; what did you expect?), but we can move this discussion to another issue since it's off-topic.