다음을 통해 공유


기타 성능 고려 사항

네 가지 핵심 성능 원칙 외에도 일반적으로 외부 요인으로 인해 성능이 저하되는 데는 몇 가지 다른 이유가 있을 수 있습니다.

클라이언트 브라우저, 디바이스, 위치의 차이점 고려

캔버스 앱은 다양한 네트워크 조건을 가진 여러 디바이스, 브라우저 및 위치에서 사용할 수 있습니다. Power Apps 클라이언트가 실행될 때 최신 업데이트된 지원되는 브라우저를 사용하는지 확인합니다. iOS 또는 Android와 같은 다른 플랫폼에서 대규모 데이터 집합을 로드할 때 앱 성능이 달라질 수 있습니다. 이러한 변화는 각 플랫폼의 다양한 네트워크 요청 제한으로 인해 발생합니다. 예를 들어, 허용되는 동시 실행 네트워크 요청 수는 플랫폼에 따라 다릅니다. 이러한 차이는 대용량 데이터 세트의 데이터 로드 시간에 큰 영향을 미칠 수 있습니다.

온-프레미스 데이터 게이트웨이와 환경의 지리적 위치 차이 고려

사용자는 전 세계적으로 캔버스 앱에 액세스할 수 있습니다. 그러나 대부분의 최종 사용자 근처에서 데이터 원본을 사용하는 것이 좋습니다. 예를 들어 앱이 온-프레미스 데이터 게이트웨이에 액세스하는 경우 앱에 가장 자주 액세스하는 사용자 근처에 게이트웨이를 배치하는 것이 가장 좋습니다.

일반 서버 측 문제

성능 저하는 데이터 서버 소스의 문제로 인해 발생할 수 있습니다. 다양한 이유로 이와 같은 현상이 발생할 수 있습니다. 모니터링 도구를 사용하면 데이터 호출 타이밍을 측정하여 특정 문제를 평가할 수 있습니다.

데이터 원본에서 가능한 병목 현상 문제

데이터 원본에는 병목 현상의 원인이 많이 있습니다. 일반적으로 데이터 원본에 있는 몇 개의 테이블은 많은 쿼리에 대한 활동의 ​​중심에 있습니다. 다음과 같은 경우 쿼리가 느려질 수 있습니다.

  • 데이터 원본이 없거나 잘못된 색인이 있습니다.
  • 쿼리는 서버에 있는 엄청나게 많은 양의 데이터를 결합하고 있습니다.
  • 쿼리에는 StartsWith와 같은 인덱스를 사용하는 대신 In 연산자와 같은 테이블 검색이 필요합니다.
  • 데이터 원본을 호스팅하는 백 엔드 머신에 리소스가 부족합니다.
  • 백 엔드 SQL 인스턴스에 차단, 교착 상태 또는 리소스 경합이 있습니다.
  • 온-프레미스 데이터 게이트웨이는 비정상입니다.
  • 온-프레미스 데이터 게이트웨이를 확장해야 합니다.

이러한 문제가 발생할 때 앱의 성능 저하를 방지하기 위해 백 엔드 데이터 원본을 조정합니다.

특정 데이터 원본

Azure SQL Database

비즈니스 요구 사항에 적합한 계층을 선택하는 것이 중요합니다. 자세한 내용은 Azure SQL 데이터베이스 설명서를 참조하십시오. 하위 계층에는 몇 가지 제한 사항이 있습니다. 성능 측면에서 CPU, I/O 처리량 및 대기 시간이 중요합니다. 따라서 주기적으로 SQL 데이터베이스의 성능을 확인하고 리소스 사용량이 임계값을 초과하는지 확인하는 것이 좋습니다. 예를 들어 온-프레미스 SQL Server는 일반적으로 CPU 사용량 임계값을 약 75%로 설정합니다.

SharePoint

SharePoint 커넥터를 사용하면 SharePoint 목록의 데이터를 사용하는 앱을 만들 수 있습니다. 다음은 SharePoint의 몇 가지 일반적인 성능 문제 및 해결 방법입니다.

동적 조회 열이 너무 많지 않도록 방지: SharePoint는 개인, 그룹, 계산과 같은 동적 조회를 포함한 다양한 데이터 유형을 지원합니다. 목록에 너무 많은 동적 열이 정의되어 있으면 캔버스 앱을 실행하는 클라이언트에 데이터를 반환하기 전에 SharePoint 내에서 이러한 동적 열을 조작하는 데 더 많은 시간이 걸립니다. 이를 방지하려면 SharePoint에서 동적 조회 열을 과도하게 사용하지 마십시오. 예를 들어 이메일 별칭이나 사람 이름을 유지하려면 정적 열을 사용하세요.

사진란과 첨부파일을 주의 깊게 사용: 이미지 및 첨부 파일의 크기는 클라이언트에서 검색하는 동안 응답이 느려지는 원인이 될 수 있습니다. 목록을 검토하여 필요한 열만 정의되었는지 확인하십시오. 목록의 열 수는 데이터 요청의 성능에 영향을 줍니다. 이는 일치하는 레코드 때문이거나 정의된 데이터 행 한도까지의 레코드가 검색되어 앱이 모두 사용하지 않는 경우에도목록에 정의된 모든 열과 함께 클라이언트로 다시 전송됩니다.

대량 목록 분할 고려: 수십만 개의 레코드가 있는 큰 목록이 있는 경우 목록을 분할하거나 범주, 날짜 및 시간과 같은 매개 변수를 기반으로 여러 목록으로 분할합니다. 예를 들어 데이터는 연간 또는 월간 기준으로 다른 목록에 저장될 수 있습니다. 이 경우 사용자가 시간 창을 선택하고 해당 범위 내의 데이터를 검색할 수 있도록 앱을 설계할 수 있습니다.

Dataverse

Microsoft Dataverse를 데이터 원본으로 사용하는 경우, 데이터 요청은 환경 인스턴스로 직접 이동하며 Azure API Management를 통하지 않습니다. 따라서 다른 데이터 원본보다 빠른 경향이 있습니다. 자세한 내용은 Microsoft Dataverse 연결 시 데이터 호출 흐름을 참조하세요.

사용자 지정 테이블 구성 확인: Dataverse에서 사용자 지정 테이블을 사용하는 경우 사용자가 캔버스 앱으로 레코드를 보려면 추가 보안 구성이 필요할 수 있습니다. 자세한 내용은 Dataverse의 보안 개념, 환경의 리소스에 대한 사용자 보안 구성, 및 보안 역할 및 권한을 참조하세요.

Excel

Excel 커넥터를 사용하면 캔버스 앱이 Excel 파일의 테이블에 연결할 수 있습니다. 하지만 이 커넥터는 다른 데이터 원본에 비해 한계가 있습니다. 예를 들어, 위임 가능한 기능이 제한되어 캔버스 앱이 테이블에서 최대 2,000개의 레코드까지만 데이터를 로드하도록 제한합니다. 2,000개 이상의 레코드를 로드하려면 데이터를 다른 데이터 원본으로 다른 데이터 테이블에 분할하십시오.

새로운 Excel 커넥터 사용: 새로운 Excel 커넥터 - Excel Business Online을 꼭 이용해 보세요. 다중 사용자 액세스를 허용하고 경합 문제를 더 잘 처리합니다.

Excel의 대량 데이터 목록에서 필요한 열만 사용: Excel 파일에 데이터 테이블이 너무 많거나 여러 열에 걸쳐 막대한 양의 데이터가 포함된 데이터 테이블이 있는 경우 앱이 느리게 작동할 수 있습니다. 앱이 이러한 문제에 영향을 받지 않도록 하려면 Excel 파일의 데이터 테이블에 필요한 열만 정의하십시오.

데이터베이스로서 Excel의 제한 사항에 유의하세요. Excel은 관계형 데이터베이스 시스템이 아닙니다 : 앱의 모든 변경 사항은 마치 사용자가 Excel 파일에서 직접 데이터를 변경하는 것과 같은 방식으로 Excel에서 관리됩니다. 앱의 읽기 횟수는 많지만, 업데이트 작업이 적으면 제대로 수행될 수 있습니다. 그러나 앱에 과도한 트랜잭션이 필요한 경우 앱 성능에 부정적인 영향을 미칠 수 있습니다. 거래 수에 대한 특정 임계값은 없습니다. 또한 조작되는 데이터에 따라 다릅니다. 네트워크 오버헤드 또는 사용자 디바이스와 같은 여러 다른 측면도 앱 성능에 영향을 미칩니다.

지리적 위치의 차이 고려: 데이터의 지리적 위치와 고객 위치와의 거리가 성능 문제가 될 수 있습니다. 모바일 클라이언트의 대역폭이 제한된 경우 이 문제가 증폭될 수 있습니다.