Speed ​​of use of an app according to the number of users

[Gustavo_Eduardo]

Hello friends, I want to ask you, based on your experience, what is the maximum number of users that is recommended to have in an appsheet app so as not to slow down its use. I think it can go fast at first but over time it can slow down. Tell me if I'm right and how many people would you put at most.

Thanks, good day!!!

[Rafael_ANEIC-PY · Accepted solution]

Hello @Gustavo_Eduardo, the number of users is not a factor in performance, but the data that is loaded and all the calculations that are made with each sync.

That means that an app which takes a minimalistic approach on the use of virtual columns and expensive expressions will be able to use thousands of rows easily without slowing down.

[1minManager · Accepted solution]

Hi @Gustavo_Eduardo I've had an app before where it was used by over a 1000 people on one particular day.  The app didn't slow down.  Though it was a read only app.

If the App operates slowly, its likely to be virtual columns and/or very complex or ineffecient formulas.  If it takes ages to sync it could be all those plus the users internet speed.

[Steve · Accepted solution]

Your question is impossible to answer. The performance of your app is entirely dependent on the complexity of the configuration, the size of the data, and the capabilities of the devices the users are using. There are simply too many variables.

[SkrOYC · Accepted solution]

En general hay una idea de que los Select, Filter y sus equivalentes (como Lookup) analizan toda la tabla a modo de "fuerza bruta", por lo tanto es mejor evitar su uso, sobre todo en columnas virtuales.

Los ShowIf no sé si impactarán mucho considerando que no afectan los datos sino la UI. Esa es otra área en la cual no hay un consenso al respecto

[SkrOYC · Accepted solution]

Actualmente me encuentro analizando conceptos de Clean Code que creo ayudarán acá.

Desde la forma de nombrar las columnas en el worksheet al tipo de funciones usadas.

Te recomiendo echarle un vistazo

[Anthony_Nel · Accepted solution]

Hey Gustavo,  In my experience things get really tight when using G-Drive and G-Sheets as  a data source and you go beyond 50 users or so and do lots of image uploads and or complex queries. I put delays in my automation steps to mitigate G-drive / Appsheet server timeouts , but you really need to use a high performance data source if you want to scale your app.

[Rafael_ANEIC-PY · Accepted solution]

Hello @Gustavo_Eduardo, the number of users is not a factor in performance, but the data that is loaded and all the calculations that are made with each sync.

That means that an app which takes a minimalistic approach on the use of virtual columns and expensive expressions will be able to use thousands of rows easily without slowing down.

[1minManager · Accepted solution]

Hi @Gustavo_Eduardo I've had an app before where it was used by over a 1000 people on one particular day.  The app didn't slow down.  Though it was a read only app.

If the App operates slowly, its likely to be virtual columns and/or very complex or ineffecient formulas.  If it takes ages to sync it could be all those plus the users internet speed.

[Gustavo_Eduardo]

Hola amigos, @1minManager @Rafael_ANEIC-PY , gracias por sus respuestas, ambas son útiles tanto teórico como práctico. 

Tomo sus respuestas, ambas como soluciones. Que tengan buen día.

[Steve · Accepted solution]

Your question is impossible to answer. The performance of your app is entirely dependent on the complexity of the configuration, the size of the data, and the capabilities of the devices the users are using. There are simply too many variables.

[Gustavo_Eduardo]

Ok @Steve entendí que es imposible ya que las variables son las que impactan el performance.

A mi me gusta un estilo de formulario donde los valores se van desplegando y son visibles si se van llenando otros campos y si se cumplen ciertas condiciones. SIn embargo, al terminar de dar la configuración, abajo me indica que la fórmula está bien pero que la expresión puede impactar en el performance de la app. Existen fórmulas que hacen que uno pueda generar shoe_if sin dañar el rendimiento?

Estoy en la etapa de purgar las fórmulas para aumentar la velocidad de la sincronización.

Saludos

[SkrOYC · Accepted solution]

En general hay una idea de que los Select, Filter y sus equivalentes (como Lookup) analizan toda la tabla a modo de "fuerza bruta", por lo tanto es mejor evitar su uso, sobre todo en columnas virtuales.

Los ShowIf no sé si impactarán mucho considerando que no afectan los datos sino la UI. Esa es otra área en la cual no hay un consenso al respecto

[Gustavo_Eduardo]

Claro, @SkrOYC , lo entiendo y agradezco mucho este dato. 

Te comento que en la app que yo estoy haciendo, estos casos son prácticamente inevitables, de otra forma la información (de lo general a lo particular) sería imposible de recopilar dado que para lo que estoy haciendo, es necesario un desglose tipo arbol de familias. Ordena al usuario y todos los datos cargados.

Descartando un cambio por ese lado, sin embargo, existen otros campos que, independientemente de la estructura de la app, pueden demandar mayor rendimiento, esto se debe al mal uso de fórmulas que se traducirían como "consultas sobre consultas". Podría simplificarlas, creando columnas en las que los cálculos sean más simples para dividir los cálculos y no hacer todo en una sola. 

Yo en un principio creía que cuantas menos columnas mejor, puede que así sea para mí, por la legibilidad, sin embargo controversialmente, para los cálculos da la sensación que cuanto menos extensa es la fórmula, mejor. 

Un saludo Amigo gracias por el dato!

[Steve]

That warning about the expression affecting performance is generic; it does nothing to analyze your expression to make that determination. It's up to you alone to consider the potential impact.

Queries with queries are likely to hurt performance as data size grows.

Table-column references (e.g., Table[Column]) within a query are likely to hurt performance as data size grows.

Queries that run against small data sets are unlikely to hurt performance.

Queries that use simple comparisons (=, <>, >, <) are less likely to hurt performance.

Textual comparisons are heavier than numeric comparisons.

When possible, use a conditional statement to bypass a query if you know the result won't be useful, to avoid performing the unnecessary query:

IFS(
  ISNOTBLANK([Name]),
    SELECT(People[Phone], ([Name] = [_THISROW].[Name]))
)

 Those are some tips to get you started.

[Gustavo_Eduardo]

Sí @Steve yo cree formularios basados en esta forma. Los campos van mostrándose a medida que yo voy seleccionando, siempre y cuando se cumpla que el inmediato anterior no sea blanco. Así, el usuario va teniendo un uso bastante intuitivo dado que no puede elegir otra cosa que la que se le va mostrando. Al ser pocos datos, el entendimiento es más simple. Podría haber optado directamente por mostrar todo sin embargo se vuelve engorroso.

En algunos casos (solo en algunos) me sale el mensaje de que la columna podría afectar mi performance, sin embargo creo que son casos solucionables (algunas columnas virtuales no necesarias o algunas consultas sobre consultas).

Intento darle una vuelta de rosca y te cuento sobre mi experiencia Steve. 

Esto último me resultó, aunque parezca obvio para muchos, de muchísima utilidad:

"UTILIZAR UNA DECLARACIÓN CONDICIONAL PARA EVITAR UNA CONSULTA"

MAGISTRAL

Saludos Steve

[Gustavo_Eduardo]

Quiero hacer una aclaración aquí. Notarán que todas son soluciones. Podría no haber elegido ninguna, pero todos los comentarios aquí aportan al enriquecimiento de la respuesta dado que, como dijo @Steve no hay una respuesta para mi pregunta, por lo tanto, los pequeños aportes se pueden considerar pequeñas soluciones. 

[SkrOYC · Accepted solution]

Actualmente me encuentro analizando conceptos de Clean Code que creo ayudarán acá.

Desde la forma de nombrar las columnas en el worksheet al tipo de funciones usadas.

Te recomiendo echarle un vistazo

[Gustavo_Eduardo]

Conceptos de Clean Code! Excelente dato para que me siente a estudiar. Sin dudas Oscar, los pondré en práctica. 

[Anthony_Nel · Accepted solution]

Hey Gustavo,  In my experience things get really tight when using G-Drive and G-Sheets as  a data source and you go beyond 50 users or so and do lots of image uploads and or complex queries. I put delays in my automation steps to mitigate G-drive / Appsheet server timeouts , but you really need to use a high performance data source if you want to scale your app.

[Gustavo_Eduardo]

Hola @Anthony_Nel !! buen día.

Me gusta este dato ya que es muy práctico. Pienso en mudar la base a MySQL porque creo que el tiempo de sincronización es muchísimo más rápido. después dime que te parece. Mientras tanto voy lanzando la app para 50 usuarios. En la ap habrá solamente datos cargados desde la app a G-Sheet pero no tendrá imágenes. Se que puede resultar más atractiva una app con imágenes sin embargo a los fines prácticos de la app resulta exagerado. Te agradezco mucho el comentario y dese ya, creo que se acerca mucho a lo que yo pregunté, claro desde la experiencia.

[Anthony_Nel · Accepted solution]

Hola Gustavo, Unfortunately spanish is not a language i speak 😞 but google translate is always on 🙂 Anyway the gist of this for our english speaking friends, a Mysql source is far better suited for large volumes of data and many concurrent users, and in addition it offers a very rich set of query functions. Sync times become less important, as you can do more with each sync (like delete 1000's of records with a single MYSQL query or stored procedure in just 1 sync). Be aware that these data sources while require an Enterprise Account . HTH Anthony

[Gustavo_Eduardo]

Anthony, es lo que tengo planificado; sé que mi app va a dar resultado, con lo cual debo pensar en algo así, por supueso a mediano plazo. Agradezco mucho tus comentarios. Tengo entendido que cuesta bastante caro, pero con muchos usuarios, esto se vuelve accesible. Saludos desde Argentina.