Problemas e resolucións comúns de rendemento da aplicación de lenzo

Pode crear aplicacións de lenzo cunha gran variedade de orixes de datos. Elixa a orixe de datos e un conector en función das necesidades empresariais e dos escenarios para os que está deseñando a aplicación. Para aplicacións empresariais, Microsoft Dataverse é o orixe de datos recomendado porque proporciona varios beneficios de rendemento. Para aplicacións cun pequeno número de transaccións, pode escoller calquera outra orixe de datos dispoñible no seu ambiente.

Para consideracións de rendemento dunha aplicación, pense no número de usuarios que usarán a aplicación cando a publique; o volume de transaccións de creación, recuperación, actualización e eliminación (CRUD); o tipo de interaccións de datos; o acceso xeográfico e o tipo de dispositivos dos usuarios.

Neste artigo, aprenderá sobre algúns dos problemas de rendemento máis comúns que poden facer que as aplicacións de lenzo funcionen lentamente e como resolvelos. Esta información axudaralle a mellorar o rendemento da aplicación tendo en conta o seu plan de negocio e o seu crecemento.

Comezaremos con algúns dos problemas de rendemento máis comúns que se producen independentemente do conector que se estea a usar. Nas seccións posteriores, aprenderá sobre os problemas de rendemento e as resolucións específicas de varios conectores.

Antes de comezar, asegúrese de entender as fases de execución das aplicacións de lenzo e o fluxo de chamadas de datos. Ademais, lea Orixes comúns de rendemento lento para unha aplicación de lenzo para obter información sobre dificultades comúns que pode evitar ao deseñar ou actualizar aplicacións de lenzo.

Conxuntos de datos grandes que cargan lentamente en diferentes plataformas

O rendemento dunha aplicación pode variar ao cargar grandes conxuntos de datos en diferentes plataformas como iOS ou Android. Esta variación ocorre debido ás limitacións de solicitudes de rede diferentes en cada plataforma. Por exemplo, o número de solicitudes de rede simultáneas permitidas pode ser diferente segundo as plataformas. Esta diferenza pode ter un impacto importante no tempo de carga de datos para conxuntos de datos grandes.

Recomendámoslle que cargue só os datos que necesita para mostrar de inmediato na pantalla. Para outros datos, paxine e garde na caché os seus datos. Máis información: Consellos e prácticas recomendadas para mellorar o rendemento da aplicación de lenzo

Recuperáronse demasiadas columnas

Recoméndase seleccionar só as columnas necesarias para a aplicación. Se engade máis ou todas as columnas da orixe de datos, descárganse todos os datos das columnas. Esta acción produce un alto número de chamadas adicionais de rede e, polo tanto, un alto uso de memoria no dispositivo cliente. Este problema pode afectar aínda máis aos usuarios con dispositivos móbiles se o ancho de banda da rede é limitado ou se un dispositivo ten memoria limitada ou un procesador antigo.

Por exemplo, se usa Dataverse como orixe de datos da súa aplicación, asegúrese de ter activada a función Selección explícita de columnas. Esta función permite a Power Apps restrinxir a recuperación de datos só para as columnas empregadas na aplicación.

Para activar a función de selección de columnas explícita na aplicación de lenzo, vaia a Configuración > Próximas funcións > Versión preliminar e, a continuación, active o alternador Selección explícita de columnas.

Navegadores antigos ou non compatibles

Os usuarios que usan navegadores non compatibles ou antigos poden experimentar problemas de rendemento. Asegúrese de que os usuarios só usan os navegadores compatibles para executar aplicacións de lenzo.

Rendemento lento debido á distancia xeográfica

A localización xeográfica do ambiente e a distancia da orixe de datos aos usuarios poden influír no rendemento.

Recomendamos que o seu ambiente estea situado preto dos usuarios. Aínda que Power Apps usa a rede de entrega de contido de Azure para o contido; as chamadas de datos seguen obtendo os datos da orixe de datos. Unha orixe de datos situada noutra situación xeográfica pode afectar negativamente o rendemento da aplicación.

Unha distancia xeográfica excesiva afecta o rendemento de diferentes formas, como a latencia, o rendemento reducido, a largura de banda menor ou a perda de paquetes.

Permitir lista non configurada

Asegúrese de que non se bloquearon os URL de servizo requiridos ou que se engadiron á lista de permitidos da súa devasa. Para obter unha lista completa de todos os URL de servizo que se deben permitir para Power Apps, vaia a Servizos necesarios.

O uso de funcións non delegables e límites de filas de datos inadecuado para consultas non delegables

As funcións delegables delegan o procesamento de datos na orixe de datos, minimizando a sobrecarga no lado do cliente. Cando non é posible delegar, pode restrinxir o límite de filas de datos para consultas non delegables de xeito que o número de filas devoltas desde unha conexión baseada no servidor siga sendo óptimo.

O uso de funcións non delegables e límites de filas de datos para consultas non delegables inadecuados engade sobrecarga adicional na transferencia de datos. Esta sobrecarga resulta na manipulación dos datos recibidos para a área de datos dinámicos de JS no lado do cliente. Asegúrese de usar funcións delegables para a aplicación sempre que estean dispoñibles e o límite óptimo de filas de datos para consultas non delegables.

Máis información: Usar a delegación, Visión xeral da delegación

O evento OnStart precisa de axuste

O evento OnStart execútase cando se carga a aplicación. Chamar grandes cantidades de datos mediante as funcións da Propiedade OnStart da aplicación fará que a aplicación se cargue lentamente. Unha pantalla con forte dependencia dos controis e valores definidos noutra pantalla verase afectada pola navegación lenta na pantalla.

As seguintes seccións describen algúns dos problemas máis comúns experimentados nestas situacións.

Gran número de chamadas no evento OnStart que fai que a aplicación se inicie lentamente

Nunha empresa, o volume de chamadas de datos a unha orixe de datos central pode provocar o atoamento do servidor ou a contención de recursos.

Use un mecanismo de caché para optimizar as chamadas de datos. Moitos usuarios poden usar unha única aplicación, dando lugar a moitas chamadas de datos por usuario que chegan aos extremos do servidor. Estas chamadas de datos poden ser un punto onde pode ocorrer o atoamento ou a limitación.

Latencia no evento OnStart por mor de scripts pesados

Os scripts pesados no evento OnStart son un dos erros máis comúns ao deseñar aplicacións de lenzo. Só debe obter os datos necesarios para que a aplicación se inicie.

Optimice a fórmula nun evento OnStart. Por exemplo, pode mover algunhas funcións á propiedade OnVisible no seu lugar. Deste xeito, pode deixar que a aplicación se inicie rápido e outros pasos poden continuar mentres a aplicación se abre.

Máis información: Optimice a propiedade OnStart

Presión da memoria no lado do cliente

É importante comprobar o consumo de memoria dunha aplicación de lenzo porque a maioría das veces a aplicación funciona en dispositivos móbiles. As excepcións de memoria na área de datos dinámicos son a causa máis probable detrás dunha aplicación de lenzo que se bloquea ou conxela ("colga") en certos dispositivos.

A área de datos dinámicos de JavaScript (JS) pode chegar ao límite debido a que hai scripts pesados que se executan no lado do cliente para engadir columnas, unir filtrar, ordenar ou agrupar. Na maioría dos casos, a excepción de falta de memoria na área de datos dinámicos do cliente pode provocar o fallo da aplicación ou o bloqueo.

Cando se empregan datos procedentes de orixes como Dataverse ou SQL Server, pode usar un obxecto de Visualización para garantir que a unión, a filtraxe, o agrupamento ou a clasificación ocorre no servidor en lugar do cliente. Este enfoque reduce a sobrecarga de scripts do cliente para tales accións.

Se as operacións pesadas no cliente como UNIR ou Agrupar por aconteceron no lado do cliente cun conxunto de datos con 2000 rexistros ou máis, os obxectos da área de datos dinámicos aumentarán, o que provocará que se superen os límites da memoria.

As ferramentas de desenvolvemento da maioría dos navegadores permiten perfilar a memoria. Axuda a visualizar o tamaño da área de datos dinámicos, documentos, os nós e os oíntes. Faga un perfil do rendemento da aplicación mediante un navegador, como se describe en Descrición xeral das ferramentas para desenvolvedores Microsoft Edge (Chromium). Comprobe os escenarios que superan o limiar de memoria da área de datos dinámicos de JS. Máis información: Solucione problemas de memoria

Consideracións sobre o rendemento para o conector de SQL Server

Pode usar o conector de SQL Server para Power Apps para conectarse a SQL Server local ou Azure SQL Database. Esta sección describe problemas e resolucións comúns relacionados co rendemento para usar este conector para unha aplicación de lenzo. Máis información: Conéctese a SQL Server desde Power Apps, Cree unha aplicación de lenzo desde Azure SQL Database

Vexamos os problemas e resolucións de rendemento comúns cando se usa o conector de SQL Server para aplicacións de lenzo.

Consulta N+1

As galerías que xeran demasiadas solicitudes aos servidores provocan problemas de consulta N+1. O problema de consulta N+1 é un dos problemas máis frecuentes ao usar o control de Galería.

Para evitar o problema, use ver obxectos no back-end de SQL ou cambie os escenarios da interface de usuario.

Escaneo de táboas no canto da busca de índice

Unha aplicación pode ralentizarse se as funcións empregadas pola aplicación executan consultas na base de datos que provocan análises de táboas en lugar de buscar índices. Máis información: Consellos, ANALISE de táboas e BUSCA de índices

Para resolver estes problemas, use StartsWith en lugar de IN na fórmula. Ao usar unha orixe de datos de SQL, o operador StartsWith resulta nunha busca de índices; pero o operador IN dá como resultado unha análise de índices ou táboas.

Consultas lentas

Pode perfilar e axustar consultas e índices lentos na base de datos de SQL. Por exemplo, se hai unha fórmula que obtén datos con orde descendente (DESC) nunha determinada columna, esa columna de clasificación debería ter un índice con orde descendente. A clave de índice crea unha orde ascendente (ASC) por defecto.

Tamén pode comprobar o enderezo URL das solicitudes de datos. Por exemplo, o seguinte fragmento da solicitude de datos (chamada de OData parcial) solicita a SQL que devolva 500 rexistros que coincidan coa columna para o Valor e a ordenen por ID en orde descendente.

Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500

Isto axuda a comprender os requisitos do índice para cubrir condicións de solicitude similares. Neste exemplo, se a columna de ID ten un índice con orde descendente, a consulta realizarase máis rápido.

Comprobe o plan de execución de consultas lentas para ver se existe algunha análise de táboas ou índices. Supervise os custos excesivos da busca de claves no plan de execución.

Máis información:

• Supervisar e axustar o rendemento
• Supervisión do rendemento mediante o Query Store
• Vista xeral de eventos ampliada

Contención dos recursos da base de datos

Asegúrese de que a—base de datos SQL—da orixe de datos non ten contencións de recursos como o atoamento do procesador, a contención de E/S, a presión da memoria ou a contención de tempDB. Comprobe tamén se hai bloqueos, esperas, bloqueos mutuos e tempos de espera para a consulta.

Cliente pesado ou solicitudes excesivas

Unha aplicación que executa as operacións Agrupar por, Filtrar por ou UNIR no lado do cliente, utiliza o procesador e os recursos de memoria dos dispositivos cliente. Dependendo do tamaño dos datos, estas operacións poden requirir máis tempo de scripts no lado do cliente, aumentando o tamaño da área de datos dinámicos de JS no cliente. Este problema aumenta ao usar unha orixe de datos local, xa que cada chamada de datos de busca viaxa á orixe de datos a través da pasarela de datos.

Nestas situacións, use o obxecto Ver na base de datos SQL para as operacións Grupo By, Filter By ou JOIN. As vistas poden usar columnas selectivas e eliminar columnas innecesarias con tipos de datos grandes como NVARCHAR (MAX), VARCHAR (MAX) e VARBINARY (MAX).

Tamaño dos datos transferidos ao cliente

De xeito predeterminado, unha aplicación de lenzo mostra datos empregando as táboas ou as vistas dos obxectos de base de datos dispoñibles. A recuperación de todas as columnas dunha táboa pode producir unha resposta lenta, especialmente cando se usan tipos de datos grandes como NVARCHAR (MAX).

A transferencia de grandes cantidades de datos aos clientes leva tempo. Esta transferencia tamén resulta en máis tempo de script cando hai grandes cantidades de datos na área de datos dinámicos JS no lado do cliente, como se describiu anteriormente neste artigo.

Para reducir o tamaño dos datos que se están a transferir ao cliente, use vistas coas columnas específicas necesarias para a aplicación e asegúrese de que a selección explícita de columnas está activada, como se describiu anteriormente neste artigo.

Consideracións específicas para SQL Server local

O rendemento dunha aplicación de lenzo usando o conector de SQL Server cunha pasarela de datos local pode verse afectado de varias maneiras. Esta sección enumera os problemas de rendemento comúns e as resolucións específicas para usar unha orixe de base de datos local.

Pasarela de datos local en mal estado

As organizacións poden definir varios nós para as pasarelas de datos locais. Mesmo se un dos nós non é accesible, as solicitudes de datos ao nó pouco en mal estado non devolverán o resultado nun prazo de tempo decente nin causarán mensaxes de erro "inalcanzable" despois de agardar un tempo.

Asegúrese de que todos os nós da pasarela de datos local estean en bo estado e configurados cunha latencia de rede mínima entre os nós e a instancia de SQL.

Localización dunha pasarela de datos local

A pasarela de datos require chamadas de rede a orixes de datos locais para interpretar as solicitudes de OData. Por exemplo, a pasarela de datos precisa comprender o esquema da táboa de datos para traducir as solicitudes OData a instrucións de linguaxe de manipulación de datos SQL (DML). Engádese unha sobrecarga extra cando a pasarela de datos está configurada nunha localización separada con alta latencia de rede entre a pasarela de datos e a instancia SQL.

Nun ambiente empresarial, recoméndase ter un clúster de pasarelas de datos escalable cando se esperan solicitudes de datos pesadas. Comprobe cantas conexións se establecen entre os nós da pasarela de datos e a instancia de SQL.

Ao comprobar as conexións simultáneas nunha pasarela de datos local ou nunha instancia de SQL, a súa organización pode identificar o momento en que a pasarela de datos necesita escalarse e con cantos nós.

Escalabilidade da pasarela de datos

Se espera acceder a un gran volume de datos desde a pasarela de datos local, un único nó da pasarela de datos local pode converterse nun atoamento para cubrir un volume tan grande de solicitudes.

Un só nó da pasarela de datos local pode ser suficiente para traballar con 200 ou menos conexións simultáneas. Non obstante, se todas estas conexións simultáneas executan consultas activamente, outras solicitudes acaban esperando por unha conexión dispoñible.

Para obter información sobre como garantir que a súa pasarela de datos local escala de acordo co volume de datos e solicitudes, acceda a Supervisar e optimizar o rendemento da pasarela de datos local.

Consideracións específicas de Azure SQL Database

As aplicacións de lenzo poden conectarse a Azure SQL Database usando o conector de SQL Server. Unha causa común de problemas de rendemento cando se usa Azure SQL Database é seleccionar o nivel incorrecto para os requisitos da súa empresa.

Azure SQL Databasee está dispoñible en diferentes niveis de servizo, con capacidades variadas para coincidir cos diferentes requisitos empresariais. Para obter máis información sobre os niveis, vaia á Documentación de Azure SQL Database.

Coas solicitudes de datos pesadas, os recursos do nivel que seleccione poden limitarse unha vez que se alcance o valor de limiar. Esta limintación afecta o rendemento do seguinte conxunto de consultas.

Comprobe o nivel de servizo de Azure SQL Database. Un nivel inferior tería algunhas limitacións e restricións. Desde a perspectiva do rendemento, a CPU, o rendemento de E/S e a latencia son importantes. Polo tanto, recomendamos comprobar o rendemento da base de datos de SQL periodicamente e comprobe se o uso de recursos supera o limiar. Por exemplo, SQL Server local normalmente establece o limiar de uso da CPU ao redor do 75 por cento.

Consideracións sobre o rendemento para o conector de SharePoint

Pode usar o conector de SharePoint para crear aplicacións usando datos de Microsoft Lists. Tamén pode crear aplicacións de lenzo directamente desde a vista de lista. Vexamos os problemas e resolucións de rendemento comúns cando se usa unha orixe de datos de SharePoint con aplicacións de lenzo.

Demasiadas columnas de busca dinámicas

SharePoint admite varios tipos de datos, incluídas as buscas dinámicas como Persoa, Grupo e Calculado. Se unha lista define demasiadas columnas dinámicas, leva máis tempo manipular estas columnas dinámicas con SharePoint antes de devolver os datos ao cliente que executa a aplicación de lenzo.

Non use en exceso as columnas de busca dinámica de SharePoint. Este uso excesivo pode provocar unha sobrecarga evitable e adicional en SharePoint para a manipulación de datos. No seu lugar, pode usar columnas estáticas para manter os alias de correo electrónico ou os nomes das persoas, por exemplo.

Columna de imaxe e anexo

O tamaño dunha imaxe e o ficheiro anexado poden contribuír a unha resposta lenta mentres se recupera ao cliente.

Revise a lista e asegúrese de que só se definiron as columnas necesarias. O número de columnas da lista afecta o rendemento das solicitudes de datos. Este efecto débese a que os rexistros coincidentes ou os rexistros ata os límites de filas de datos definidos recupéranse e transmítense ao cliente con todas as columnas definidas na lista—, tanto se a aplicación as usa todas coma se non.

Para consultar só as columnas usadas pola aplicación, active a función de selección de columnas explícita, tal e como se describiu antes neste artigo.

Grandes listas

Se ten unha lista grande con centos de miles de rexistros, considere particionar a lista ou dividila en varias listas en función de parámetros como as categorías ou a data e a hora.

Por exemplo, os seus datos poderían almacenarse en diferentes listas anualmente ou mensualmente. En tal caso, pode deseñar a aplicación para que un usuario seleccione unha xanela de tempo para recuperar os datos dentro dese rango.

Dentro dun ambiente controlado, o punto de referencia de rendemento demostrou que o rendemento das consultas de OData en Microsoft Lists ou SharePoint está moi relacionado co número de columnas da lista e co número de filas que se recuperan (limitado polo límite de filas de datos para consultas non delegables). Un número inferior de columnas e unha configuración inferior do límite de filas de datos poden facer que unha aplicación de lenzo teña un mellor rendemento.

No mundo real, pola contra, as aplicacións están deseñadas para cumprir certos requisitos empresariais. Pode non ser rápido nin sinxelo reducir o límite de filas de datos ou o número de columnas nunha lista. Non obstante, recoméndase supervisar as solicitudes de OData no lado do cliente e axustar o límite de filas de datos para consultas non delegables e o número de columnas nunha lista.

Consideracións sobre o rendemento ao usar Dataverse como orixe de datos

Cando usa Microsoft Dataverse como orixe de datos, as solicitudes de datos van á instancia do ambiente directamente, sen pasar pola xestión da API de Azure. Máis información: Fluxo de chamadas de datos ao conectarse a Microsoft Dataverse

A aplicación de lenzo conectada a Dataverse pode funcionar lentamente se executa scripts pesados para o cliente como Filtrar por ou UNIR no cliente no canto do servidor.

Use as vistas de Dataverse cando sexa posible. Unha vista cos criterios de unión ou filtro requiridos axuda a reducir a sobrecarga do uso de toda unha táboa. Por exemplo, se precisa unir táboas e filtrar os seus datos, pode definir unha vista xuntándoas e definir só as columnas que precisa. A continuación, pode usar esta vista na aplicación que crea esta sobrecarga no lado do servidor para unir ou filtrar o funcionamento no canto do lado do cliente.Este método reduce non só as operacións extra, senón tamén a transmisión de datos. Para obter información sobre filtros de edición e criterios de clasificación, vaia a Editar criterios de filtro.

Consideracións sobre o rendemento para o conector de Excel

O Conector de Excel proporciona conectividade desde unha aplicación de lenzo aos datos dunha táboa dentro dun ficheiro Excel. Este conector ten limitacións, en comparación con outras orixes de datos—por exemplo, funcións delegables limitadas—que restrinxen á aplicación de lenzo cargar datos da táboa só ata 2000 rexistros. Para cargar máis de 2000 rexistros, particione os seus datos en diferentes táboas de datos como outras orixes de datos.

Vexamos os problemas e resolucións de rendemento comúns cando se usa Excel como a orixe de datos de aplicacións de lenzo e como resolver eses problemas.

Hai demasiadas táboas de datos e tamaño de datos grande

Pode que unha aplicación funcione con lentitude cando usa un ficheiro Excel con demasiadas táboas de datos ou táboas de datos cunha cantidade inmensa de datos en varias columnas. Un ficheiro Excel non é unha base de datos relacional nin unha orixe de datos que fornece funcións delegables. Power Apps ten que cargar primeiro as táboas de datos definidas e despois empregar funcións como Filtrar, Ordenar, UNIR, Agrupar por e Buscar.

Ter demasiadas táboas de datos cun número elevado de filas e columnas afecta ao rendemento da aplicación e á sobrecarga do cliente porque cada táboa de datos debe manipularse na área de datos dinámicos de JS. Este efecto tamén leva a que a aplicación consome máis memoria do cliente.

Para asegurarse de que a súa aplicación non se vexa afectada por este problema, defina só as columnas necesarias na táboa de datos dun ficheiro Excel.

Transaccións pesadas

Excel non é un sistema de base de datos relacional. Excel xestiona calquera cambio dunha aplicación do mesmo xeito que un usuario que cambia datos nun ficheiro Excel. Se a aplicación ten un número elevado de lecturas, pero menos operacións CRUD, pode ter un bo rendemento. Non obstante, se a aplicación realiza transaccións pesadas, pode afectar negativamente ao rendemento da aplicación.

Non hai un valor limiar específico para o número de transaccións, xa que tamén depende dos datos que se manipulan. Hai outros aspectos que tamén afectan o rendemento da aplicación, como a sobrecarga da rede ou o dispositivo do usuario.

Se ten datos de só lectura, pode importalos localmente na aplicación en lugar de cargalos desde a orixe de datos. Para aplicacións empresariais, use fontes de datos como Dataverse, SQL Server ou SharePoint no seu lugar.

Tamaño do ficheiro

Pode escoller entre unha gran variedade de opcións de almacenamento na nube con capacidade de almacenamento variable—ou configurable—para o ficheiro Excel. Non obstante, un único ficheiro Excel grande con todas as táboas definidas nun ficheiro engade unha sobrecarga adicional para a aplicación mentres descarga o ficheiro e le os datos para cargar no cliente.

En vez de usar un ficheiro grande, divida os datos en varios ficheiros Excel con táboas de datos mínimas. Despois conéctese a cada ficheiro só cando o necesite. Deste xeito, a carga dos datos da táboa de datos ocorre en fragmentos, reducindo a sobrecarga de moitas táboas ou un conxunto de datos grande.

Localización do ficheiro

A localización xeográfica da orixe de datos e a súa distancia das localizacións do cliente pode producir un atoamento do rendemento común para a aplicación e inducir a latencia da rede. Este efecto pódese amplificar cun cliente móbil cunha anchura de banda limitada para a conectividade.

É mellor manter o ficheiro preto dos seus usuarios finais (ou, a maioría dos usuarios, para un público global) para que o ficheiro se poida descargar rapidamente.

Pasos seguintes

Consellos e prácticas recomendadas para mellorar o rendemento das aplicacións de lenzo

Consulte tamén

Comprender o fluxo de chamadas de datos e as fases de execución das aplicacións de lenzo
Orixes comúns de rendemento lento para unha aplicación de lenzo
Problemas frecuentes e resolucións de Power Apps
Resolución de problemas de inicio de Power Apps