Salesforce를 사용하면 한 번에 특정 수의 진술/레코드를 처리하거나 실행할 수 있습니다. 실행하거나 처리할 DML 문, Apex 클래스 등에는 몇 가지 제한이 있습니다. 이러한 제한을 거버너 제한이라고 합니다. 이 자습서에서는 주지사 제한이 무엇이며 어떻게 처리할 수 있는지 알아봅니다. 또한 Salesforce Apex는 콜아웃, Apex 클래스, 번개 웹 구성 요소, SOSL 및 SOQL 문과 관련된 제한을 알 수 있도록 '제한' 클래스를 제공합니다.
주지사 제한
Alish와 Subash가 Salesforce 조직을 사용하는 두 사람인 시나리오를 고려하십시오. Alice는 하나의 트랜잭션에서 1000개의 DML 문을 처리하거나 실행하려고 합니다. 동시에 Subash는 한 번에 5000개의 레코드를 로드하려고 합니다. 병렬로 수행하면 Salesforce는 수락하지 않고 바빠집니다. 따라서 주지사 제한이 적용됩니다. 이 경우 Alish는 한 번에 100개의 DML을 처리할 수 있고 Subash는 한 번에 500개의 레코드를 처리할 수 있습니다. 그들은 AsynchronousBatch Apex를 사용하여 각각을 방해하지 않고 별도의 스레드에서 각 트랜잭션을 수행하고 작업을 완료할 수 있습니다.
기본적으로 Salesforce의 주지사 제한은 여러 트랜잭션에서 처리 및 실행을 제한합니다. '거래당 Apex 제한'은 각 거래에 대해 계산되며 '크기별 Apex 제한'은 코드의 크기를 처리합니다. Salesforce는 동기 및 비동기 프로세스의 두 가지 프로세스를 지원합니다. 동기식 프로세스에서는 Apex 스크립트가 한 번에 실행되는 반면 비동기식 프로세스에서는 Apex 스크립트가 여러 작업으로 분할되어 실행됩니다.
허용된 한도
다양한 시나리오에 대한 제한 수에 대해 논의해 보겠습니다.
- 동기식 Apex에서 100개의 SOQL 쿼리와 비동기식 Apex에서 200개의 SOQL 쿼리를 처리/실행할 수 있습니다.
- 동기 및 비동기 apex 모두에 대해 SOQL 쿼리에서 50,000개의 레코드만 반환됩니다.
- Database.getQueryLocator()를 사용하는 경우 동기 및 비동기 Apex 모두에 대해 한 번에 10,000개만 반환됩니다.
- 두 시나리오 모두에서 발행된 SOSL 쿼리 수는 20입니다.
- 동기 Apex를 처리하는 데 필요한 힙 크기는 6MB입니다. 비동기 Apex의 경우 필요한 힙 크기는 두 배이므로 12MB가 됩니다.
- 동기 Apex에 허용되는 최대 CPU 시간은 10,000밀리초이고 비동기 Apex의 경우 60,000밀리초입니다.
- 두 Apex 모두 실행에 10분만 허용됩니다.
- 두 경우 모두 수신자가 100명인 경우 10개의 sendEmail() 메서드만 사용할 수 있습니다.
- Apex 클래스 또는 Apex 트리거에 있는 문자는 100만 이내여야 합니다.
- Batch Apex(비동기)에서 크기는 200입니다. '데이터베이스' 클래스의 QueryLocator()는 트랜잭션당 5천만 개의 레코드를 반환합니다.
- 5개의 Apex 작업만 대기열에 있거나 활성화됩니다.
LIMIT 클래스 예:
Apex는 'LIMIT' 클래스에서 거버너 제한을 지정할 수 있습니다. 이 클래스는 주지사 제한을 알려주는 몇 가지 방법을 제공합니다. 일부 거버너 제한을 표시하는 다음 예를 살펴보겠습니다.
System.debug('처리할 수 있는 집계 쿼리 수: '+ Limits.getLimitAggregateQueries());
System.debug('처리할 수 있는 웹 서비스 문 수: '+ Limits.getLimitCallouts());
System.debug('처리할 수 있는 레코드 수: '+ Limits.getLimitDmlRows());
System.debug('호출할 수 있는 DML 문 수: '+ Limits.getLimitDmlStatements());
System.debug('총 메모리 양(바이트): '+ Limits.getLimitHeapSize());
System.debug('실행할 수 있는 SOQL 쿼리 수: '+ Limits.getLimitQueries());
System.debug('발급 가능한 레코드 수: '+ Limits.getLimitQueryRows());
System.debug('실행할 수 있는 SOSL 쿼리 수: '+ Limits.getLimitSoslQueries());
산출:
또한 'LIMIT' 클래스에 있는 'dome' 메서드를 사용하여 얼마나 많은 DML 문/행을 반환할 수 있는지 확인할 수 있습니다.
- Limits.getDMLStatements() 인스턴스에서 사용된 총 DML 문을 반환합니다.
- Limits.getDMLRows() DML 문에서 반환된 총 행 수를 반환합니다.
- Limits.getCpuTime() 현재 트랜잭션의 CPU 사용 시간을 밀리초 단위로 반환합니다.
사용 예:
'WorkOrder' 개체에서 두 개의 레코드를 반환하는 SOQL 쿼리를 작성해 보겠습니다. 그런 다음 'delete' DML을 사용하여 이 두 레코드를 삭제합니다.
System.debug('DML 문:'+Limits.getDMLStatements());System.debug('행: '+Limits.getDmlRows());
System.debug('CPU 시간 '+Limits.getCpuTime());
// WorkOrder 개체에서 2개의 행을 선택하는 SOQL 쿼리
List
//delete DML을 사용하여 두 개의 행을 삭제합니다.
계정 삭제
System.debug('**SOQL 후:**');
System.debug('DML 문:'+Limits.getDMLStatements());
System.debug('행: '+Limits.getDmlRows());
System.debug('CPU 시간 '+Limits.getCpuTime());
산출:
주어진 예에는 DML 문이 없고 행이 없습니다. 기존 CPU 시간은 1밀리초입니다. SOQL 쿼리에서 2개의 행을 반환하고 이 두 행을 삭제한 후 Limits.getDMLStatements()에서 반환된 총 DML 문의 수는 1이고 Limits.getDMLRows()에서 반환된 총 행은 2이며 CPU 이 트랜잭션을 실행하는 데 필요한 시간은 51밀리초입니다.
모범 사례: '루프 내에서 DML을 사용하지 마십시오.'
거버너 제한 없이 코드를 실행할 수 있는 방법을 살펴보겠습니다. 먼저 'for' 루프 자체의 '제품 이름'에 'WorkOrder' 주제를 할당하여 'WorkOrder' 개체에서 '제품' 개체(API – Product2)에 대한 레코드를 만듭니다. 다음 코드를 보자:
제품2 prod_obj;for (WorkOrder wo_object : [작업 주문에서 제목 선택])
{
prod_obj = new Product2(Name = wo_object.Subject);
삽입 prod_obj;
}
목록(prod_s)을 선언한 다음 목록에 prod_obj를 저장하여 더 나은 방법으로 이 작업을 수행할 수 있습니다. 이 목록을 루프 외부의 제품에 삽입할 수 있습니다.
List<제품2> prod_s = new List<제품2>();제품2 prod_obj;
for (WorkOrder wo_object : [작업 주문에서 제목 선택])
{
prod_obj = new Product2(Name = wo_object.Subject);
prod_s.add(prod_obj);
}
삽입 prod_obj;
결론
이제 자세한 설명과 함께 Salesforce의 Apex 제한이 무엇인지 배웠습니다. 동기식 Apex와 비교할 때 더 나은 거버너 제한을 얻으려면 비동기식 Apex 프로세스를 사용하는 것이 좋습니다. 또한 다양한 시나리오에 대한 거버너 한도에 대해 알아보고 '한도' 클래스의 한도 수에 대한 샘플 데모를 제공했습니다. 또한 하나의 DML 문을 실행하여 DML 문, 행 및 CPU 시간의 수를 확인했습니다. 하나의 모범 사례에 대해 논의하면서 이 가이드를 마무리했습니다.