Firebase report "XHR finish loading :POST <URL>" more times than all requests on a page.

[eliataylor]

(Rally/Meeting pages](https://democraseeclub.web.app/rally/giGKQ4XvOq4504l6ICbE) are extremely slow, presumably because of how were are querying reference fields from their parent Firebase Documents.

We can verify that our normalizeRally and normalizeMeeting functions are only called once. However, it seems the Firebase .get() and .ref() methods require many additional requests.

How can we get a full Rally document, along with labels / image of some referenced fields without all the extra weight?

[eliataylor]

I find it interesting that FIreCMS appears to do something similar with their createEntityFromSchema - https://github.com/Camberi/firecms/blob/760bced63a25f80831ce3a6ff05c610d72f42986/src/models/firestore.ts#L265 - but their CMS is much faster at loading even larger numbers of documents and references.

I've created this separate repository of just FireCMS and our collections - https://github.com/DemocraseeClub/cms - for more isolated testing.

[Branyer]

@eliataylor cree una rama (no-fireCMS) donde elimine fireCMS de la app, seria chevere que lo probaras y me dijeras que tal te va

[eliataylor]

@Branyer , no veo una diferencia sin fireCMS. ~10 segundos para mostrar http://localhost:3000/rally/giGKQ4XvOq4504l6ICbE

[fgatti675]

Hola chicos, He echado un vistazo rapido al metodo https://github.com/DemocraseeClub/website/blob/ac3f0ee384c7f140f23c11327770a5717f6b39c1/src/redux/entityDataReducer.js#L229 y he visto que teneis muchas llamadas asincronas realizadas de forma secuencial. Eso hace que para completar una tengais que esperar a la anterior. Yo cambiaria el codigo para poder hacer el maximo de cosas posibles en paralelo: El metodo que necesitais para hacer esto es: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all Decidme si os funciona :)

[Branyer]

@eliataylor he implementado Promise.all en esta rama implementPromiseAll, creo que ha mejorado bastante el rendimiento, por favor pruebalo y me comentas.

[eliataylor]

@Branyer / @fgatti675 , yo subé los cambios y esta mejor, un poquito (por 2 segundos?).

Todavía se siente muy lento; y hay 37 mensajes de XHR: Post ""

Mas raro es Profiling con Chrome dice "4887 ms Idle".

Que piensa ustedes?

[Branyer]

@eliataylor lo único que se me ocurre es cambiar las funciones para que absolutamente todas las promesas entren en un solo Promise.all, también podriamos jugar con el cache de firestore, pero no estoy seguro de que sea recomendable, no sé, si @fgatti675 nos puedes dar consejos sobre esto.

[fgatti675]

Parece que todavia hay sitios donde se ejecutan llamadas asincronas de forma secuencial, como en este loop: https://github.com/DemocraseeClub/website/blob/fbaf5d6b465143bbd280b4b83a9f752e1452bee5/src/redux/entityDataReducer.js#L68 Echad un ojo a ver si podeis hacer refactor para que se ejecuten de forma paralela y vereis como mejora el rendimiento :)

[eliataylor]

@Branyer / @fgatti675 , sabes porque hay tantas solicitudes como:

curl 'https://firestore.googleapis.com/google.firestore.v1.Firestore/Listen/channel?database=projects%2Fdemocraseeclub%2Fdatabases%2F(default)&VER=8&gsessionid=aieX6Tp9pG4tL02OXh5PmPzXr4RfWymCAJBdkJyeDuU&SID=UE4m9q_Ch0Ycryur3ULdvQ&RID=90341&AID=53&zx=bhj65lhtiqzx&t=1' \ -H 'authority: firestore.googleapis.com' \ -H 'pragma: no-cache' \ -H 'cache-control: no-cache' \ -H 'sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"' \ -H 'sec-ch-ua-mobile: ?0' \ -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36' \ -H 'content-type: application/x-www-form-urlencoded' \ -H 'accept: */*' \ -H 'origin: https://democraseeclub.web.app' \ -H 'x-client-data: CJa2yQEIpbbJAQjEtskBCKmdygEIttDKAQigoMsBCK3yywEI3PLLAQjv8ssBCIv4ywEItPjLAQie+csB' \ -H 'sec-fetch-site: cross-site' \ -H 'sec-fetch-mode: cors' \ -H 'sec-fetch-dest: empty' \ -H 'referer: https://democraseeclub.web.app/' \ -H 'accept-language: en-US,en;q=0.9,es-US;q=0.8,es;q=0.7,es-419;q=0.6' \ --data-raw 'count=1&ofs=19&req0___data__=%7B%22database%22%3A%22projects%2Fdemocraseeclub%2Fdatabases%2F(default)%22%2C%22addTarget%22%3A%7B%22documents%22%3A%7B%22documents%22%3A%5B%22projects%2Fdemocraseeclub%2Fdatabases%2F(default)%2Fdocuments%2Fusers%2FyyU3NMUnacftaHM6B2V1%22%5D%7D%2C%22targetId%22%3A22%7D%7D' \ --compressed

depronto estan el fuente de la lentitud ?

[fgatti675]

No estoy del todo seguro, esas llamadas las hace Firebase desde el SDK directamente. No deberia ser mucho problema que haya tantas llamadas, simplemente reflejan que estais haciendo muchas llamadas a Firebase. Para reducirlas imagino que es necesario reducir el numero de documentos a los que se accede. En el CMS, en las vistas donde hay referencias a otros documentos, que se cargand e forma asincrona, tambien hay muchas llamadas HTTP.

[eliataylor]

1. La ruta Firestore/Listen/channel indica que Firebase esta escuchando por cambios / analytics, no? No estamos usando Listeners aparte de Functions y Meetings y ciertamente esas llamadas pueden retrasar a otras, entonces toda la pagina, si? La orden de las llamadas indica esto en particular (donde y 2-4 POST por cada imagen)

2. también me preocupa que la respuesta 400 pueda bloquear la página.

[eliataylor]

3. No es un solucion, pero yo subé un cambio - https://github.com/DemocraseeClub/website/commit/2102db36260d9c279341dc99e2a03733ef1f571d?w=1 - así no esperamos los Meetings para ejecutar Render. Por lo menos, ahora vemos algunos datos mientras cargamos los de Meetings.

4. @fgatti675, desde tu experiencia con Firebase es este rendimiento normal? Tal vez estoy esperando demasiado.

[fgatti675]

Firebase puede ser muy rapido! Os sugeriria intentar ir desactivando partes de vuestra aplicacion para identificar las partes mas lentas, o aun mejor, medir los tiempos de cada funcion: https://stackoverflow.com/questions/313893/how-to-measure-time-taken-by-a-function-to-execute