-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve network latency of runTransaction()
routine
#2015
Comments
@tom-andersen I'm pinging you here because of your comment #1994 (comment) quoted below.
While the PR #2002 you mention may improve performance when |
@brettwillis Thank you very much for your interest in this optimization! Everything you describe is absolutely correct. 😍 Our team has discussed this optimization previously. All we need to do is prioritize this SDK work. We rely heavily on community feedback to guide our development priorities, and you just became a data point in favor of this development. |
No worries! Would you be interested in accepting a PR, or would you prefer to keep it within the team? |
For something like this that doesn't require changes to the API surface, we will very happily accept a PR! |
If I correctly understand the routine for
runTransaction()
, as referenced below, then when running a read-write transaction, adocuments:beginTransaction
request is always issued before running theupdateFn
.nodejs-firestore/dev/src/transaction.ts
Lines 593 to 598 in e598b9d
This means we wait for an entire network round trip before beginning the transaction, every attempt.
I also noticed that the
documents:runQuery
anddocuments:batchGet
APIs support anewTransaction
parameter, which would allow the SDK to lazily start a transaction on the first read request, without the additional sequential network round trip.Lazily starting the transaction on the first read would always eliminate one entire sequential network round trip for every read-write transaction. I feel that this is quite a significant impact for high performance applications.
Some implications
documents:beginTransaction
and usenewTransaction
).documents:batchGet
,documents:runQuery
,documents: runAggregationQuery
(i.e. notdocuments:get
) which is fine.getAll()
. The only exception is if there is a mix of document IDs and queries (cannot be batched together in one request). Regardless, currently all reads are queued after thedocuments:beginTransaction
call anyways so there is no downside.documents:commit
is called without a transaction.Thoughts?
The text was updated successfully, but these errors were encountered: