Firestore Latency

[James Spivey]

As promised, getting a simple Angular demo app with some basics. I included several ways and types of data to grab. First is the way the docs show, second two or ways that came from AngularFirebase and his tutorials, last two just duplicate the AngularFirebase methods but instead grab the detailed collection in full. I tried to generically match my data setup which was to have a simple collection that references a detailed collection. I had to strip a ton from the detailed for demo purposes. I am seeing the 3000 or so rows I added for testing take generally 3 seconds to return, and have seen as high as 6 seconds.

Source: https://github.com/myspivey/firestorelatency

Demo: https://firestorelatency.firebaseapp.com

I would love to have an open dialog on this one. Totally understand that this is a beta product with the usual caveat of use at your own risk, not advised for production yet but interested to see how quickly we can get this in our customers hands and small things like these can become big issues quick if we were to try. Let me know if you have any questions or see any glaring stupid mistakes.

[Samuel Stern]

Hi James,

Thanks for taking the time to put this together.  I can confirm that when I run this demo I see 1.5-4.5s latency, which is in line with what you're seeing.  Are you noticing a big difference between using AngularFire versus the "simple" method?

- Sam

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/7c99c7b7-e9e1-42d0-b327-8f6f07260a28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Samuel Stern]

For others reading this thread, I believe this is in response to a previous thread.  Linking for context:

https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/firebase-talk/MpS6C-ZxdZ0/EYNWdveIAwAJ

[Michael Lehenbauer]

Hey James,

Thanks for setting this up!  FWIW- I'm seeing ~5s for the first load and ~2s for subsequent loads (once the persisted cache is populated) of each query.  I think there's optimization work we can do to improve this, but I'm curious what your expectations are.  Is this a use case from an existing app against RTDB? What kind of performance are you seeing there? Is there a specific real world use case this is emulating? While 3000 documents is definitely within the realm of what we support, I have a general assumption that most app queries will typically be for a ~small numbers of documents (e.g. that fit on a single screen or page), so I'm curious what the use case here is.

I would also be interested in seeing the results with persistence disabled. Since RTDB doesn't support persistence, that would be a more fair comparison, and I believe persistence could be contributing quite a bit here.

Thanks!

-Michael

On Thu, Nov 30, 2017 at 10:16 AM, 'Samuel Stern' via Firebase Google Group <fireba...@googlegroups.com> wrote:

For others reading this thread, I believe this is in response to a previous thread.  Linking for context:

https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/firebase-talk/MpS6C-ZxdZ0/EYNWdveIAwAJ

On Thu, Nov 30, 2017 at 10:15 AM Samuel Stern <sams...@google.com> wrote:

Hi James,

Thanks for taking the time to put this together.  I can confirm that when I run this demo I see 1.5-4.5s latency, which is in line with what you're seeing.  Are you noticing a big difference between using AngularFire versus the "simple" method?

- Sam

On Wed, Nov 29, 2017 at 2:08 PM James Spivey <spi...@zentostudios.com> wrote:

As promised, getting a simple Angular demo app with some basics. I included several ways and types of data to grab. First is the way the docs show, second two or ways that came from AngularFirebase and his tutorials, last two just duplicate the AngularFirebase methods but instead grab the detailed collection in full. I tried to generically match my data setup which was to have a simple collection that references a detailed collection. I had to strip a ton from the detailed for demo purposes. I am seeing the 3000 or so rows I added for testing take generally 3 seconds to return, and have seen as high as 6 seconds.

Source: https://github.com/myspivey/firestorelatency

Demo: https://firestorelatency.firebaseapp.com

I would love to have an open dialog on this one. Totally understand that this is a beta product with the usual caveat of use at your own risk, not advised for production yet but interested to see how quickly we can get this in our customers hands and small things like these can become big issues quick if we were to try. Let me know if you have any questions or see any glaring stupid mistakes.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/7c99c7b7-e9e1-42d0-b327-8f6f07260a28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAHafJBpHb4MDwy-nySyV1R4%3D0JBMww96vO2KE2ePWPLoDr-B9w%40mail.gmail.com.

[James Spivey]

I would expect our initial load to be somewhere between 1-2 seconds as I generally do not think that level of records would be a killer. This is basically an emulation of a real world app I am working on now. I would much prefer to only be asking for 15-30 records at a time but right now Firebase as a whole does not really support the type of pagination that would be needed to do something like that. We put everything into a grid and infinite scroll is not really an option which is what cursors are more setup for. It might that we are trying to shoehorn in Firebase where it is not the best suited but cost wise it is what we have for now. I can try building out an RTDB version of this to see how it does, but from my working experience over the last couple years, I have never seen return times like this. Also happy to play around with persistence off although I think that is a major value add for this product as the internet for this particular client can be incredibly spotty.

[Kato Richardson]

James, I'm a bit lost about pagination, considering that Firestore does pagination with cursors. Would love to get feedback on why that's not working for you.

--

You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/622c8368-8965-4314-8c80-b78a991f4125%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[James Spivey]

The issue with trying to do actual pagination is you need to know how many pages you have which means you need total count. My understanding is that you can't do that with cursors. Cursors are more ideal for something like infinite scroll where you aren't trying to hit a specific page. If there is a way to look at total pages and move through the set that would be awesome to know.

On Friday, December 1, 2017 at 12:46:08 PM UTC-7, Kato Richardson wrote:

James, I'm a bit lost about pagination, considering that Firestore does pagination with cursors. Would love to get feedback on why that's not working for you.

On Fri, Dec 1, 2017 at 5:55 AM, James Spivey <spi...@zentostudios.com> wrote:

I would expect our initial load to be somewhere between 1-2 seconds as I generally do not think that level of records would be a killer. This is basically an emulation of a real world app I am working on now. I would much prefer to only be asking for 15-30 records at a time but right now Firebase as a whole does not really support the type of pagination that would be needed to do something like that. We put everything into a grid and infinite scroll is not really an option which is what cursors are more setup for. It might that we are trying to shoehorn in Firebase where it is not the best suited but cost wise it is what we have for now. I can try building out an RTDB version of this to see how it does, but from my working experience over the last couple years, I have never seen return times like this. Also happy to play around with persistence off although I think that is a major value add for this product as the internet for this particular client can be incredibly spotty.

On Wednesday, November 29, 2017 at 3:07:55 PM UTC-7, James Spivey wrote:

As promised, getting a simple Angular demo app with some basics. I included several ways and types of data to grab. First is the way the docs show, second two or ways that came from AngularFirebase and his tutorials, last two just duplicate the AngularFirebase methods but instead grab the detailed collection in full. I tried to generically match my data setup which was to have a simple collection that references a detailed collection. I had to strip a ton from the detailed for demo purposes. I am seeing the 3000 or so rows I added for testing take generally 3 seconds to return, and have seen as high as 6 seconds.

Source: https://github.com/myspivey/firestorelatency

Demo: https://firestorelatency.firebaseapp.com

I would love to have an open dialog on this one. Totally understand that this is a beta product with the usual caveat of use at your own risk, not advised for production yet but interested to see how quickly we can get this in our customers hands and small things like these can become big issues quick if we were to try. Let me know if you have any questions or see any glaring stupid mistakes.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/622c8368-8965-4314-8c80-b78a991f4125%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Lehenbauer]

Hey James,

I experimented with your repro and found that with persistence off, the 3000 docs load in ~2 seconds for me, and ~1.3 seconds of that is just streaming the docs over the network (the rest is initial latency and some client overhead I think).  I did identify some potential perf optimizations and have logged a bug to track investigating deeper and making improvements. I am not sure how far we'll get by GA, but I suspect we should be able to make some improvements.

Thanks again for the feedback!

-Michael

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/086f7e30-8f2e-48c4-b8fa-bd8021aeed0b%40googlegroups.com.

[Michael Lehenbauer]

To be clear, the "potential perf optimizations" I mentioned were with persistence enabled, which is I think where we have the most room for improvement here.

-Michael

[James Spivey]

I just wanted to update this with some new info, I created a demo using the exact same data using RTDB and am getting .059's load times. https://fir-latency-9f524.firebaseapp.com/ https://github.com/myspivey/firebaselatency

This is clearly the sort of speed we would hope for out of Firestore as when faced between 3 seconds and .059 it means there is little reason to use Firestore for anything other than immensly small or heavily filtered data sets. Thanks again for looking into all of this and looking forward to seeing the improvements over time!

On Wednesday, November 29, 2017 at 3:07:55 PM UTC-7, James Spivey wrote:

[Michael Lehenbauer]

Thanks James,

.059s sounds a bit too good to be true, and indeed I'm seeing between 0.4 and 1 second, so I think RTDB is ~2-4 times as fast for a raw query without persistence enabled (which isn't an option on RTDB anyway)... so we clearly have some work cut out for us. :-)

Thanks for collecting the data and pushing on us! It's appreciated.

-Michael

--

You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/6bc8fdbb-5a39-4a21-a5e3-4ad08af2b1db%40googlegroups.com.