일반적인 캔버스 앱 성능 문제 및 해결 방법
다양한 데이터 원본 배열을 사용하여 캔버스 앱을 빌드할 수 있습니다. 앱을 설계한 비즈니스 요구 사항 및 시나리오에 따라 데이터 원본 및 커넥터를 선택합니다. 엔터프라이즈 앱의 경우 Microsoft Dataverse는 몇 가지 성능상의 이점이 있기 때문에 데이터 원본으로 권장합니다. 트랜잭션이 적은 앱의 경우 환경에서 사용 가능한 다른 데이터 원본을 사용할 수 있습니다.
앱의 성능을 고려하려면 앱이 게시되었을 때 사용할 사용자 수를 생각하세요. 생성, 검색, 업데이트 및 삭제(CRUD) 트랜잭션의 양 데이터 상호 작용 유형; 지리적 접근; 사용자가 가지고 있는 장치의 종류.
이 문서에서는 캔버스 앱을 느리게 실행할 수 있는 가장 일반적인 성능 문제와 이를 해결하는 방법에 대해 알아봅니다. 이 정보는 비즈니스 플랜 및 성장을 염두에 두고 앱 성능을 개선하는 데 도움이 됩니다.
사용되는 커넥터에 관계없이 발생하는 몇 가지 일반적인 성능 문제부터 시작하겠습니다. 이후 섹션에서는 기준 커넥터와 관련된 성능 문제 및 해결 방법에 대해 알아봅니다.
시작하기 전에 캔버스 앱 실행 단계 및 데이터 호출 흐름을 이해하는지 확인하십시오. 또한, 캔버스 앱 성능 저하의 일반적인 원인을 읽고 캔버스 앱을 디자인하거나 업데이트하는 동안 피할 수 있는 일반적인 문제에 대해 알아보십시오.
다른 플랫폼에서 느리게 로드되는 대용량 데이터 집합
iOS 또는 Android와 같은 다른 플랫폼에서 대규모 데이터 집합을 로드할 때 앱 성능이 달라질 수 있습니다. 이러한 변화는 각 플랫폼의 다양한 네트워크 요청 제한으로 인해 발생합니다. 예를 들어, 허용되는 동시 실행 네트워크 요청 수는 플랫폼에 따라 다를 수 있습니다. 이 차이는 대용량 데이터 집합의 데이터 로드 시간에 큰 영향을 미칠 수 있습니다.
화면에 즉시 표시해야 하는 데이터만 로드하는 것이 좋습니다. 다른 데이터의 경우 페이지를 매기고 데이터를캐시에 저장합니다. 추가 정보: 캔버스 앱 성능을 개선하기 위한 팁 및 모범 사례
검색된 열이 너무 많음
앱에 필요한 열만 선택하는 것이 좋습니다. 데이터 원본에서 더 많은(또는 모든) 열을 추가하면 열의 모든 데이터가 다운로드됩니다. 이 작업으로 인해 많은 네트워크 오버헤드 호출이 발생하므로 클라이언트 디바이스에서 높은 메모리 사용량이 발생합니다. 이 문제는 네트워크 대역폭이 제한적이거나 디바이스에 제한된 메모리 또는 레거시 프로세서가 있는 경우 모바일 디바이스를 사용하는 사용자에게 더 많은 영향을 미칠 수 있습니다.
예를 들어 Dataverse를 앱의 데이터 원본으로 사용하는 경우 명시적 열 선택 기능을 활성화했는지 확인합니다. 이 기능을 통해 Power Apps는 앱에서 사용되는 열에 대해서만 데이터 검색을 제한할 수 있습니다.
캔버스 앱에서 명시적 열 선택 기능을 켜려면 설정 > 예정된 기능 > 프리뷰로 이동한 다음 명시적 열 선택 토글을 켭니다.
지원되지 않는 브라우저 또는 레거시 브라우저
지원되지 않는 브라우저나 레거시 브라우저를 사용하면 사용자에게 성능 문제가 발생할 수 있습니다. 사용자가 캔버스 앱을 실행할 때는 지원되는 브라우저만 사용하도록 합니다.
지리적 거리로 인해 성능 저하
환경의 지리적 위치와 사용자에 대한 데이터 원본 거리는 성능에 영향을 미칠 수 있습니다.
환경이 사용자 가까이에 있는 것이 좋습니다. Power Apps은 콘텐츠의 경우 Azure 콘텐츠 배달 네트워크(CDN)를 사용하지만, 데이터 호출은 여전히 데이터 원본에서 데이터를 가져옵니다. 지리적으로 다른 위치에 있는 데이터 원본은 앱 성능에 부정적인 영향을 미칠 수 있습니다.
과도한 지리적 거리는 대기 시간, 처리량 감소, 대역폭 감소 또는 패킷 손실과 같이 다양한 방식으로 성능에 영향을 미칩니다.
허용 목록이 구성되지 않았습니다
필수 서비스 URL이 차단되지 않았는지 또는 방화벽의 허용 목록에 추가되었는지 확인하십시오. Power Apps에 대해 허용되어야 하는 모든 서비스 URL의 전체 목록을 보려면 필수 서비스로 이동하십시오.
위임할 수 없는 쿼리에 대해 위임할 수 없는 함수 및 부적절한 데이터 행 한도의 사용
위임 가능한 함수는 데이터 원본에서 데이터 처리를 위임하여 클라이언트 측의 오버헤드를 최소화합니다. 위임이 불가능한 경우 서버 기반 연결에서 반환된 행의 수가 최적으로 유지되도록 위임할 수 없는 쿼리에 대한 데이터 행 한도를 제한할 수 있습니다.
위임할 수 없는 함수 및 위임할 수 없는 쿼리에 대한 부적절한 데이터 행 한도를 사용하면 데이터 전송에 추가 오버헤드가 추가됩니다. 이 오버헤드로 인해 클라이언트 측에서 수신된 데이터가 JS 힙으로 조작됩니다. 가능한 경우 앱에 대해 위임 가능한 함수를 사용하고 위임할 수 없는 쿼리에 대해 최적의 데이터 행 한도를 사용하십시오.
OnStart 이벤트 조정 필요
OnStart 이벤트는 애플리케이션이 로드될 때 실행됩니다. 앱의 OnStart 속성에서 함수를 사용하여 대량의 데이터를 호출하면 앱이 느리게 로드됩니다. 다른 화면에 정의된 컨트롤 및 값에 매우 종속적인 화면은 느린 화면 탐색의 영향을 받습니다.
다음 섹션에서는 이러한 상황에서 발생하는 가장 일반적인 문제 중 일부를 설명합니다.
OnStart 이벤트의 많은 호출로 인해 앱이 느리게 시작됨
기업에서는 중앙 데이터 원본에 대한 대량의 데이터 호출로 인해 서버 병목 현상 또는 리소스 경합이 발생할 수 있습니다.
캐시 메커니즘을 사용하여 데이터 호출을 최적화합니다. 하나의 앱을 여러 사용자가 사용할 수 있으므로 사용자당 서버의 엔드포인트에 도달하는 데이터 호출이 많이 발생할 수 있습니다. 이러한 데이터 호출은 병목 현상이나 제한이 발생할 수 있는 지점이 될 수 있습니다.
과도한 스크립트로 인한 OnStart 이벤트 지연
OnStart 이벤트의 과도한 스크립트는 캔버스 앱을 디자인하는 데 있어 가장 일반적인 실수 중 하나입니다. 앱을 시작하는 데 필요한 데이터만 가져와야 합니다.
OnStart 이벤트에서 공식을 최적화합니다. 예를 들어, 일부 함수를 OnVisible 속성으로 이동시킬 수 있습니다. 이렇게 하면 앱이 빠르게 시작되고 앱이 열리는 동안 다른 단계를 계속할 수 있습니다.
추가 정보: OnStart 속성 최적화
팁
App.StartScreen 속성을 사용하는 것이 좋습니다. 앱 실행을 단순화하고 앱의 성능을 향상시키기 때문입니다.
클라이언트 쪽의 메모리 부족
대부분의 경우 앱이 모바일 디바이스에서 실행되므로 캔버스 앱의 메모리 사용량을 확인하는 것이 중요합니다. 힙의 메모리 예외는 캔버스 앱이 특정 디바이스에서 충돌하거나 동결("중단")하는 가장 가능성이 높은 원인입니다.
열 추가, 결합, 필터링, 정렬 또는 그룹화를 위해 클라이언트 쪽에서 실행되는 과도한 스크립트로 인해 JavaScript(JS) 힙이 한도에 도달할 수 있습니다. 대부분의 경우 클라이언트 힙의 메모리 부족 예외로 인해 앱이 충돌하거나 중단될 수 있습니다.
Dataverse 또는 SQL Server 같은 소스에서 데이터를 사용하는 경우 보기 개체를 사용하여 결합, 필터링, 그룹화 또는 정렬이 클라이언트 쪽 대신 서버 쪽에서 발생하도록 할 수 있습니다. 이 방식은 이러한 작업에 대한 스크립팅의 클라이언트 오버헤드를 줄입니다.
2,000개가 넘는 레코드를 가진 데이터 집합을 통해 결합 또는 그룹화 기준 같은 과도한 클라이언트 작업이 발생하면 힙의 개체가 증가하여 메모리 한도를 초과합니다.
대부분의 브라우저용 개발자 도구를 사용하면 메모리를 프로파일링할 수 있습니다. 이를 통해 힙 크기, 문서, 노드 및 수신기를 시각화합니다. Microsoft Edge(Chromium) 개발자 도구 개요에 설명된 대로 브라우저를 사용하여 앱의 성능을 프로파일링합니다. JS 힙의 메모리 임계값을 초과하는 시나리오를 확인합니다. 추가 정보: 메모리 문제 해결
SQL Server 커넥터에 대한 성능 고려 사항
Power Apps용 SQL Server 커넥터를 사용하여 SQL Server 온-프레미스 또는 Azure SQL 데이터베이스에 연결할 수 있습니다. 이 섹션에서는 캔버스 앱에 이 커넥터를 사용하기 위한 일반적인 성능 관련 문제 및 해결을 설명합니다. 추가 정보: Power Apps에서 SQL Server에 연결, Azure SQL 데이터베이스에서 캔버스 앱 만들기
참고
이 섹션에서는 성능 문제 및 해결에 대해 SQL Server 커넥터를 참조하지만, 대부분의 권장 사항은 —MySQL 또는 PostgreSQL과 같은—데이터베이스 유형을 데이터 원본으로 사용할 때도 적용됩니다.
캔버스 앱용 SQL Server 커넥터를 사용할 때 일반적인 성능 문제와 해결을 살펴보겠습니다.
N+1 쿼리
서버에 너무 많은 요청을 생성하는 갤러리로 인해 N+1 쿼리 문제가 발생했습니다. N+1 쿼리 문제는 갤러리 컨트롤을 사용할 때 가장 일반적으로 발생하는 문제 중 하나입니다.
문제를 방지하려면 SQL 백엔드에서 개체 보기를 사용하거나 사용자 인터페이스 시나리오를 변경합니다.
인덱스 검색 대신 테이블 검색
앱에서 사용하는 함수가 데이터베이스에서 쿼리를 실행하여 인덱스 검색 대신 테이블 검색이 발생하면 앱 속도가 느려질 수 있습니다. 추가 정보: 힌트, 테이블 검색 및 인덱스 검색
이러한 문제를 해결하려면 수식에서 IN 대신 StartsWith를 사용하십시오. SQL 데이터 원본을 사용할 때 StartsWith 연산자는 인덱스 검색을 수행하지만 IN 연산자는 인덱스 또는 테이블 검색을 수행합니다.
느린 쿼리
SQL 데이터베이스에서 느린 쿼리 및 인덱스를 프로파일링하고 조정할 수 있습니다. 예를 들어 특정 열에 수식이 내림차순(DESC)으로 특정 데이터를 가져오는 경우 해당 정렬 열에는 내림차순 인덱스가 있어야 합니다. 인덱스 키는 기본적으로 오름차순(ASC)을 만듭니다.
데이터 요청의 URL 주소를 확인할 수도 있습니다. 예를 들어, 다음 데이터 요청 코드 조각(부분 OData 호출)은 값에 일치하는 500개의 레코드를 반환하고 ID를 내림차순으로 정렬하도록 SQL에 요청합니다.
Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500
이는 유사한 요청 조건을 처리하기 위한 인덱스 요구 사항을 이해하는 데 도움이 됩니다. 이 예에서 ID 열에 내림차순 인덱스가 있는 경우 쿼리는 더 빠르게 수행합니다.
느린 쿼리의 실행 계획을 확인하여 테이블 또는 인덱스 검색이 있는지 확인하십시오. 실행 계획에서 키 조회의 과도한 비용을 모니터링합니다.
추가 정보:
데이터베이스 리소스 경합
데이터 원본—SQL 데이터베이스—에는 프로세서 병목 현상, I/O 경합, 메모리 부족 또는 tempDB 경합과 같은 리소스 경합이 없도록 합니다. 또한 잠금, 대기, 교착 상태 및 쿼리 시간 제한을 확인합니다.
팁
자동 조정을 사용하여 잠재적인 쿼리 성능 문제, 권장 해결 방법에 대한 통찰력을 얻고 식별된 문제를 자동으로 수정합니다.
씩(Thick) 클라이언트 또는 과도한 요청
클라이언트 쪽에서 Group By, Filter By, 또는 JOIN 작업을 실행하는 앱은 클라이언트 디바이스의 프로세서 및 메모리 리소스를 사용합니다. 데이터 크기에 따라 이러한 작업은 클라이언트 쪽에서 스크립팅 시간이 더 오래 걸릴 수 있으며 클라이언트의 JS 힙 크기가 증가합니다. 각 조회 데이터 호출이 데이터 게이트웨이를 통해 데이터 원본으로 이동하기 때문에 온-프레미스 데이터 원본의 경우 이 문제가 증가합니다.
이러한 상황에서는 Group By, Filter By, 또는 JOIN 작업에 SQL 데이터베이스의 View 개체를 사용합니다. 보기는 선택적 열을 사용할 수 있으며 NVARCHAR(MAX), VARCHAR(MAX), 및 VARBINARY(MAX) 와 같은 빅 데이터 유형이 있는 불필요한 열을 제거할 수 있습니다.
팁
이 접근 방식은 N+1 쿼리 문제 를 해결하는 데 도움이 됩니다.
클라이언트로 전송되는 데이터 크기
기본적으로 캔버스 앱은 사용 가능한 데이터베이스 개체의 테이블 또는 보기를 사용하여 데이터를 표시합니다. 특히 NVARCHAR(MAX) 와 같은 빅 데이터 유형을 사용하는 경우 테이블에서 모든 열을 검색하면 응답이 느려질 수 있습니다.
많은 양의 데이터를 클라이언트로 전송하는 데는 시간이 걸립니다. 이 전송으로 인해 클라이언트 쪽의 JS 힙에 많은 양의 데이터가 있을 때 이 문서의 앞부분에서 설명한 것과 같이 스크립팅 시간이 늘어납니다.
클라이언트로 전송되는 데이터의 크기를 줄이려면 앱에 필요한 특정 열이 있는 보기를 사용하고 이 기사의 앞부분에서 설명한 것과 같이 명시적 열 선택이 사용 설정되어 있는지 확인하십시오.
SQL Server 온-프레미스 관련 고려 사항
온-프레미스 데이터 게이트웨이를 통해 SQL Server 커넥터를 사용하는 캔버스 앱의 성능은 다양한 방식으로 영향을 받을 수 있습니다. 이 섹션에서는 온-프레미스 데이터베이스 소스 사용과 관련된 일반적인 성능 문제 및 해결 방법을 나열합니다.
비정상 온-프레미스 데이터 게이트웨이
조직은 온-프레미스 데이터 게이트웨이에 대해 여러 노드를 정의할 수 있습니다. 노드 중 하나에도 연결할 수 없는 경우 비정상 노드에 대한 데이터 요청은 허용되는 시간 프레임 내에 결과를 반환하지 않거나 잠시 기다린 후 "연결할 수 없음" 오류 메시지를 발생시킵니다.
모든 온-프레미스 데이터 게이트웨이 노드가 정상이고 노드와 SQL 인스턴스 사이에 최소 네트워크 지연 시간으로 구성되었는지 확인합니다.
온-프레미스 데이터 게이트웨이 위치
데이터 게이트웨이는 OData 요청을 해석하기 위해 온-프레미스 데이터 원본에 대한 네트워크 호출이 필요합니다. 예를 들어 데이터 게이트웨이는 OData 요청을 SQL DML(데이터 조작 언어) 문으로 변환하기 위해 데이터 테이블 스키마를 이해해야 합니다. 데이터 게이트웨이가 데이터 게이트웨이와 SQL 인스턴스 사이에 높은 네트워크 대기 시간이 있는 별도의 위치에 구성되면 추가 오버헤드가 추가됩니다.
엔터프라이즈 환경에서는 과도한 데이터 요청이 예상되는 경우 확장성 있는 데이터 게이트웨이 클러스터를 사용하는 것을 권장합니다. 데이터 게이트웨이 노드와 SQL 인스턴스 간에 설정된 연결 수를 확인하십시오.
온-프레미스 데이터 게이트웨이 또는 SQL 인스턴스에서 동시 연결을 확인하면 조직에서 데이터 게이트웨이를 확장해야 하는 시점과 노드 수를 식별할 수 있습니다.
데이터 게이트웨이 확장성
온-프레미스 데이터 게이트웨이에서 대량의 데이터에 액세스할 것으로 예상되는 경우 온-프레미스 데이터 게이트웨이의 단일 노드만 이러한 대량 요청을 처리하는 데 병목이 될 수 있습니다.
온-프레미스 데이터 게이트웨이의 단일 노드는 200개 이하의 동시 연결을 처리하기에 충분할 수 있습니다. 하지만 이러한 모든 동시 연결이 쿼리를 적극적으로 실행하면 다른 요청이 사용 가능한 연결을 기다리게 됩니다.
온-프레미스 데이터 게이트웨이가 데이터 및 요청의 양에 따라 확장되는지 확인하는 방법에 대한 자세한 내용은 온-프레미스 데이터 게이트웨이 성능 모니터링 및 최적화로 이동하십시오.
Azure SQL 데이터베이스 관련 고려 사항
캔버스 앱은 SQL Server 커넥터를 사용하여 Azure SQL Database에 연결할 수 있습니다. Azure SQL Database를 사용할 때 성능 문제의 일반적인 원인은 비즈니스 요구 사항에 대해 잘못된 계층을 선택하는 것입니다.
Azure SQL 데이터베이스는 다양한 비즈니스 요구 사항을 충족하기 위한 다양한 기능과 함께 다양한 서비스 계층에서 사용할 수 있습니다. 계층에 대한 자세한 내용을 위해 Azure SQL 데이터베이스 설명서로 이동하십시오.
과도한 데이터 요청으로 임계값에 도달하면 선택한 계층의 리소스가 제한될 수 있습니다. 이러한 제한은 다음 쿼리 집합의 성능을 손상시킵니다.
Azure SQL 데이터베이스의 서비스 계층을 확인하십시오. 하위 계층에는 몇 가지 제한 사항이 있습니다. 성능 측면에서 CPU, I/O 처리량 및 대기 시간이 중요합니다. 따라서 주기적으로 SQL 데이터베이스의 성능을 확인하고 리소스 사용량이 임계값을 초과하는지 확인하는 것이 좋습니다. 예를 들어 온-프레미스 SQL Server는 일반적으로 CPU 사용량 임계값을 약 75 %로 설정합니다.
SharePoint 커넥터에 대한 성능 고려 사항
SharePoint 커넥터를 사용하여 Microsoft Lists의 데이터를 사용하여 앱을 만들 수 있습니다. 목록 보기에서 캔버스 앱을 직접 만들 수도 있습니다. 캔버스 앱을 통해 SharePoint 데이터 원본을 사용하는 것에 대한 일반적인 성능 문제와 해결 방법을 살펴보겠습니다.
너무 많은 동적 조회 열
SharePoint는 사람, 그룹, 및 계산과 같은 동적 조회를 포함한 다양한 데이터 유형을 지원합니다. 목록에 너무 많은 동적 열이 정의되어 있으면 캔버스 앱을 실행하는 클라이언트에 데이터를 반환하기 전에 SharePoint 내에서 이러한 동적 열을 조작하는 데 더 많은 시간이 걸립니다.
SharePoint의 동적 조회 열을 과도하게 사용하지 마십시오. 이러한 남용은 데이터 조작을 위한 SharePoint 쪽에서 피할 수 있는 오버헤드가 추가 발생할 수 있습니다. 대신 예를 들어 정적 열을 사용하여 이메일 별칭이나 사람 이름을 유지할 수 있습니다.
그림 열 및 첨부
이미지 및 첨부 파일의 크기는 클라이언트에서 검색하는 동안 응답이 느려지는 원인이 될 수 있습니다.
목록을 검토하여 필요한 열만 정의되었는지 확인하십시오. 목록의 열 수는 데이터 요청의 성능에 영향을 줍니다. 이는 일치하는 레코드 때문이거나 정의된 데이터 행 한도까지의 레코드가 검색되어 앱이 모두 사용하지 않는 경우에도—목록에 정의된 모든 열과 함께 클라이언트로 다시 전송됩니다.
앱에서 사용하는 열만 쿼리하려면 이 문서에서 앞서 설명한 것과 같이 명시적 열 선택 기능을 사용 설정합니다.
큰 목록
수십만 개의 레코드가 있는 큰 목록이 있는 경우 목록을 분할하거나 범주, 날짜 및 시간과 같은 매개 변수를 기반으로 여러 목록으로 분할합니다.
예를 들어 데이터는 연간 또는 월간 기준으로 다른 목록에 저장될 수 있습니다. 이 경우 사용자가 시간 창을 선택하고 해당 범위 내의 데이터를 검색할 수 있도록 앱을 설계할 수 있습니다.
통제된 환경 내에서 성능 벤치마크는 Microsoft Lists 또는 SharePoint에 대한 OData 요청의 성능이 목록의 열 수 및 검색되는 행 수와 밀접한 관련이 있음을 입증했습니다(위임할 수 없는 쿼리에 대한 데이터 행 제한). 열 수가 적고 데이터 행 한도 설정이 낮으면 캔버스 앱의 성능이 향상될 수 있습니다.
하지만 실제 세계에서 앱은 특정 비즈니스 요구 사항을 충족하도록 설계되었습니다. 데이터 행 한도 또는 목록의 열 수를 줄이는 것이 빠르거나 간단하지 않을 수 있습니다. 그러나 클라이언트 쪽에서 OData 요청을 모니터링하고 위임할 수 없는 쿼리에 대한 데이터 행 한도와 목록의 열 수를 조정하는 것이 좋습니다.
데이터 원본으로 Dataverse 사용에 대한 성능 고려 사항
Microsoft Dataverse를 데이터 원본으로 사용하는 경우, 데이터 요청은 환경 인스턴스로 직접 이동하며 Azure API Management를 통하지 않습니다. 추가 정보: Microsoft Dataverse 연결 시 데이터 호출 흐름
팁
Dataverse에서 사용자 정의 테이블이 사용되는 경우, 사용자가 캔버스 앱으로 레코드를 볼 수 있으려면 추가 보안 구성이 필요할 수 있습니다. 추가 정보: Dataverse의 보안 개념, 환경의 리소스에 대한 사용자 보안 구성, 및 보안 역할 및 권한
Dataverse에 연결된 캔버스 앱은 서버 쪽 대신 클라이언트 측에서 Filter By 또는 JOIN과 같은 과도한 클라이언트 스크립팅을 실행하는 경우 느리게 수행될 수 있습니다.
가능한 경우 Dataverse 뷰를 사용하십시오. 필수 결합 또는 필터 기준이 있는 뷰는 전체 테이블 사용에 따른 오버헤드를 줄이는 데 도움이 됩니다. 예를 들어 테이블에 참가하고 데이터를 필터링해야 하는 경우 테이블에 참가하여 필요한 열만 정의함으로써 보기를 정의할 수 있습니다. 그런 다음 클라이언트 쪽 대신 결합/필터를 위해 서버 쪽에서 이 오버헤드를 만드는 앱에서 이 보기를 사용할 수 있습니다. 이 방법은 추가 작업을 줄일 뿐만 아니라 데이터 전송도 줄여줍니다. 필터 및 정렬 기준 편집에 대한 자세한 내용은 필터 기준 편집을 참고하십시오.
Excel 커넥터에 대한 성능 고려 사항
Excel 커넥터는 캔버스 앱에서 Excel 파일 내 테이블의 데이터로의 연결을 제공합니다. 이 커넥터는—예를 들어 제한된 위임 가능한 함수 같은—다른 데이터 원본에 비해 제한이 있습니다. 이는 캔버스 앱이 테이블에서 데이터를 최대 2,000개 레코드까지만 로드할 수 있도록 제한합니다. 2,000개 이상의 레코드를 로드하려면 데이터를 다른 데이터 원본으로 다른 데이터 테이블에 분할하십시오.
Excel을 캔버스 앱의 데이터 원본으로 사용할 때 일반적인 성능 문제와 이를 해결하는 방법을 살펴보겠습니다.
너무 많은 데이터 테이블 및 큰 데이터 크기
너무 많은 데이터 테이블이 있는 Excel 파일을 사용하거나 여러 열에 걸쳐 엄청난 양의 데이터를 가진 데이터 테이블을 사용할 때 앱의 속도가 느려질 수 있습니다. Excel 파일은 관계형 데이터베이스가 아니거나 위임 가능한 함수를 제공하는 데이터 원본이 아닙니다. Power Apps는 먼저 정의된 데이터 테이블에서 데이터를 로드한 다음 Filter, Sort, JOIN, Group By, 및 Search와 같은 함수를 사용합니다.
행과 열이 많은 데이터 테이블이 너무 많으면 각 데이터 테이블을 JS 힙 내에서 조작해야 하므로 앱 성능과 클라이언트 쪽 오버헤드에 영향을 미칩니다. 이 효과는 또한 앱이 더 많은 클라이언트 쪽 메모리를 소비하게 합니다.
앱이 이러한 문제에 영향을 받지 않도록 하려면 Excel 파일의 데이터 테이블에 필요한 열만 정의하십시오.
과도한 트랜잭션
Excel은 관계형 데이터베이스 시스템이 아닙니다. 앱의 모든 변경 내용은 사용자가 Excel 파일에서 데이터를 변경하는 것과 동일한 방식으로 Excel에서 관리됩니다. 앱의 읽기 횟수는 많지만, CRUD 작업이 적으면 제대로 수행될 수 있습니다. 하지만, 앱이 과도한 트랜잭션을 할 경우 앱 성능에 악영향을 미칠 수 있습니다.
조작되는 데이터와도 관련이 있으므로 트랜잭션 수에 대한 특정 임계값이 없습니다. 네트워크 오버헤드 또는 사용자 디바이스와 같은 여러 다른 측면도 앱 성능에 영향을 미칩니다.
읽기 전용 데이터가 있는 경우 해당 데이터를 데이터 원본에서 로드하는 대신 로컬로 앱에 가져올 수 있습니다. 엔터프라이즈 앱의 경우 대신 Dataverse, SQL Server 또는 SharePoint와 같은 데이터 원본을 사용하십시오.
파일 크기
Excel 파일에 대해 다양한—또는 구성 가능한—저장소 용량이 있는 다양한 클라우드 저장소 옵션 중에서 선택할 수 있습니다. 그러나 하나의 파일에 모든 테이블이 정의된 하나의 큰 Excel 파일은 파일을 다운로드하고 클라이언트 쪽에서 로드할 데이터를 읽는 동안 앱에 추가 오버헤드를 추가합니다.
하나의 큰 파일을 사용하는 대신 최소한의 데이터 테이블을 사용하여 데이터를 여러 Excel 파일로 분할합니다. 그런 다음 필요할 때만 각 파일에 연결합니다. 이렇게 하면 데이터 테이블에서 데이터를 로드하는 작업이 조각으로 이루어지므로 많은 테이블 또는 큰 데이터 집합의 오버헤드가 줄어듭니다.
파일 위치
데이터 소스의 지리적 위치와 클라이언트 위치와의 거리는 앱에 성능 병목 현상을 일으키고 네트워크 대기 시간을 유발할 수 있습니다. 이 효과는 연결 대역폭이 제한된 모바일 클라이언트를 통해 증폭될 수 있습니다.
파일을 빠르게 다운로드할 수 있도록 사용자(또는 전역 대상 그룹이 있는 경우 대부분의 사용자) 가까이에 파일을 보관하는 것이 좋습니다.
다음 단계
참조
캔버스 앱 실행 단계 및 데이터 호출 흐름 이해하기
캔버스 앱 성능 저하의 일반적인 원인
Power Apps의 공통 문제 및 해결
Power Apps의 시작 문제 해결
참고
귀사의 설명서 언어 기본 설정에 대해 말씀해 주시겠습니까? 간단한 설문 조사에 응해주세요. (이 설문 조사는 영어로 되어 있습니다.)
이 설문 조사는 약 7분 정도 걸립니다. 개인 데이터는 수집되지 않습니다(개인정보처리방침).
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기