안에 Mendix 앱에서 대부분의 작업은 단일 스레드이므로 예를 들어 정의한 작업은 시작에서 시작하여 끝에서 끝나고 그 사이에는 지정한 순서대로 지정한 작업을 따릅니다. 이렇게 하면 정의한 작업이 예상대로 수행되는지 여부에 대해 너무 걱정할 필요가 없고 작업 내에 종속성이 있는 경우 종속성이 무엇인지 명확하게 볼 수 있으므로 모든 것이 깔끔하고 단순해집니다.

반면, 큐는 여러 스레드와 노드에 프로세스 실행을 분산하는 데 사용할 수 있기 때문에 앱에 유용할 수 있습니다. 완료해야 할 특정 작업이 있는 경우 큐는 작업의 여러 부분을 동시에 수행할 수 있도록 하여 도움이 될 수 있으며, 전반적으로 프로세스에 걸리는 시간이 줄어듭니다. 그러면 어떻게 할 수 있을까요?

이는 효율성에 대한 일련의 블로그 게시물 중 세 번째입니다. Mendix 앱. 시리즈의 첫 번째(건강과 효율성 Mendix), 저는 로우코드의 효율성을 개선할 수 있는 간단한 방법 중 몇 가지를 강조했고 두 번째(In Mendix 문자열의 길이는 얼마인가요?), 나는 Java 액션을 사용하면 좁은 코너에서 성능을 높이는 데 어떻게 도움이 될 수 있는지 보여주었습니다. 이번에는 어떻게 Mendix 작업 대기열 앱의 효율성을 높이는 데 사용될 수 있습니다.

작업 대기열

Mendix 작업 대기열 에 소개되었다 Mendix 9는 Process Queue 마켓플레이스 모듈의 현대적 대체품이며, 그 기능은 잘 문서화되어 있습니다. 이 게시물에서는 특정하고 간단한 사용 사례를 취하고 어떻게 작업 대기열 될 수 있습니다 필요한 프로세스를 수행하는 데 걸리는 경과 시간을 크게 단축하는 데 사용됩니다..

자세한 문서가 있습니다 작업 대기열 페이지 당신이 할 수 있는 일을 포함합니다 작업 대기열, 그리고 실패한 작업의 자동 재시도 및 특정 시간에 실행을 시작하도록 작업 스케줄링과 같은 새로운 기능을 포함하여 이를 수행하는 방법에 대해 설명합니다. 기억해야 할 중요한 점 하나는 직접 관리하지 않는 한 프로세스의 '하위 작업' 간에 종속성이 없도록 주의해야 한다는 것입니다. 여기에 표시된 예제 사용 사례에는 간단한 종속성이 있으며 저는 이를 제어하는 ​​방법을 설계했습니다.

큰 삭제

내 앱은 정의된 외부 데이터 소스에서 데이터를 가져오는 데 사용됩니다. 사용자가 요청할 때. 해당 데이터는 간단한 분석을 거쳐 사용자가 데이터를 어떻게 사용해야 할지 결정할 수 있습니다. 사용자가 만족하고 작업을 완료한 시점에, 데이터를 삭제해야 합니다.

테스트 앱은 다음과 같은 방법을 보여주기 위해 만들어졌습니다. 작업 대기열 삭제 프로세스를 가속화할 수 있습니다: GitHub – Adrian-Preston/QueueingCanBeAGoodThing

초기 설정에서 도메인 모델은 자동 삭제를 위해 구성되었으므로 소스 객체를 삭제하면 자동으로 트리를 따라 내려가 모든 연관된 객체(도메인 모델의 연관 상자가 빨간색 테두리로 강조 표시됨)가 삭제됩니다. 이는 '고아' 객체가 남지 않도록 방지하고 개발자가 소스만 삭제하면 나머지 모든 것이 그대로 진행되므로 안전한 옵션입니다. 그러나 단일 스레드 작업이기 때문에 트리에 많은 데이터가 있는 경우 시간이 걸릴 수 있습니다.

이것은 비교적 간단한 도메인 모델이므로 특정 엔티티에 대한 객체를 동시에 안전하게 삭제할 수 있다는 것을 쉽게 알 수 있습니다. 따라서 ItemValue, ItemAttachment, ItemLink, AnalysedValue 및 AnalysedAttachment(하나를 설정) 특정 소스에 대한 항목은 동시에 삭제해도 안전합니다. 마찬가지로 Item 및 AnalysedItem(2세트)은 동시에 삭제될 수 있지만 레코드가 삭제된 후에만 가능합니다. 하나를 설정 모두 삭제되었습니다. 마지막으로 Source, DocumentType 및 Document는 올바른 순서로 삭제되어야 합니다. 하나를 설정 2세트 삭제되었습니다. 이것이 제가 앞서 언급한 종속성입니다.

그러면 어떻게 이것을 할 수 있을까?

앱 UI에는 현재 로드된 소스를 나열하는 페이지가 있습니다. 거기에서 사용자는 삭제할 소스를 식별하고 해당 행에서 '스마트 삭제 소스' 버튼을 누릅니다.

여기서는 'ACT_SmartDeletion'이라는 나노플로우를 호출하는데, 이 나노플로우의 두 가지 주요 작업이 포함됩니다. 첫째는 백그라운드에서 삭제 프로세스를 시작하고, 둘째는 작업이 완료되었음을 나타내는 소스 레코드가 데이터베이스에서 사라질 때까지 기다립니다.

나노플로우는 'SUB_StartSmartDeletion'이라는 마이크로플로우를 호출합니다. 이 마이크로플로우는 각 엔터티 유형에 대해 하위 마이크로플로우를 호출합니다. 하나를 설정 그러나 이것들은 각각 작업 대기열에 넣어서 호출되는데, 이는 이것들이 직접 실행되는 것이 아니라 대기열에 쌓여서 백그라운드에서 실행된다는 것을 의미합니다.. 또한 각 하위 마이크로플로우가 수신할 수 있는 특수 DeletionControl 객체를 만듭니다. 아래에서 이에 대해 자세히 설명합니다. 이 마이크로플로우가 완료되면 나노플로우로 돌아갑니다.

그런 다음 나노플로는 소스 레코드가 데이터베이스에 여전히 있는지 확인하기 위해 루프에 들어가고, 소스 레코드가 있는 동안 나노플로는 잠시 멈췄다가 다시 확인합니다. 소스 레코드가 더 이상 데이터베이스에 없으면 나노플로는 사용자에게 알리고 완료합니다.

다섯 개의 하위 마이크로플로는 모두 동일합니다(추가 코드가 있는 하나를 제외하고). 하위 마이크로플로는 특정 유형의 Entity의 Source에 대한 모든 레코드를 삭제한 다음 마지막으로 위에 제공된 DeletionControl 객체를 삭제합니다.

'SUB_DeleteItemValue'의 추가 코드는 모든 것이 완료될 때까지 기다립니다. 하나를 설정 is (모든 DeletionControl 개체가 삭제되었는지 확인하여) 완료된 후 동일한 하위 마이크로흐름을 시작합니다. 작업 대기열 엔터티 삭제를 실행하려면 2세트, 그렇게 할 때 하나를 설정 완성 됐습니다 2세트 삭제는 동일한 메커니즘을 사용하여 자동으로 시작됩니다.

마찬가지로 'SUB_DeleteItem'은 모든 항목을 삭제한 후 대기합니다. 2세트 완료되고 마지막으로 Source 레코드를 삭제하여 프로세스를 완료합니다. DocumentType 및 Document 레코드는 수가 적으므로 도메인 모델 '삭제 시' 동작을 사용하여 삭제합니다.

이 둘을 비교하면 어떻습니까?

테스트 앱에는 소스에 'Simple Delete Source' 버튼도 있는데, 이 버튼은 소스를 직접 삭제하고 도메인 모델을 그대로 두고 종속 객체도 삭제되도록 합니다. 따라서 테스트 데이터 세트에 대해 Simple 또는 Smart Deletion을 실행할 수 있습니다. 또한 앱에는 새 테스트 데이터 세트를 만들고, 테스트 데이터 세트를 내보내고, 테스트 데이터 세트를 다시 가져올 수 있는 기능이 있습니다. 이런 식으로, 앱을 사용하면 새로운 세트를 생성할 수 있으며 이를 내보내거나 가져올 수 있으므로 Simple 및 Smart Deletion 옵션을 동일한 데이터로 반복해서 사용할 수 있습니다..

저는 리소스 디렉토리에 'Source-36e63c07–9a8a-4c94–8f87–0fbf9b7dd39f'라는 앱에 포함된 테스트 데이터 세트를 가지고 있으며, 이것은 제 머신에서 삭제를 비교하는 데 사용된 세트입니다. 이것을 사용하거나 직접 만들 수 있습니다.

테스트 앱을 실행했습니다 Mendix 9.18.0은 로컬 Postgres 10 데이터베이스에 액세스하도록 구성되었습니다. 각 유형의 삭제를 테스트하기 전에 앱을 처음부터 시작했습니다. 그런 다음 테스트 데이터 세트를 가져와서 삭제를 XNUMX번 실행했습니다. XNUMX번 중 가장 좋고 가장 나쁜 결과는 무시하고 나머지 XNUMX번의 타이밍을 평균했습니다.

그렇다면 결과는 어땠을까요? 간단한 삭제 옵션은 평균적으로 163.9 초. 스마트 삭제 옵션은 평균적으로 29.4 초 — 5분의 1 미만 Simple Delete에 걸린 경과 시간의. 이제 사용자가 삭제가 완료되기를 기다리고 있다면 이것은 가치 있는 절약처럼 들립니다.

이 작업으로 사용자 경험을 개선하는 다른 방법도 있습니다. 예를 들어, 소스 레코드에 부울 플래그를 두고 소스 레코드와 그렇게 표시된 종속 항목을 삭제하는 별도의 주기적 예약 이벤트 프로세스를 갖는 방식으로 소스를 삭제됨으로 표시할 수 있습니다. 문제에 대한 해결책은 결코 하나뿐이 아닙니다.

또한, 한 사용자를 위해 여러 개의 스레드가 열심히 작업하면 다른 사용자의 앱 속도가 느려질 수 있으므로 정확한 사용 사례의 요구 사항과 솔루션의 효과를 충분히 이해하고 균형을 맞춰야 합니다.

수평적으로 확장되는 프로덕션 환경이 있는 경우 다음 작업을 잊지 마십시오. 작업 대기열 클러스터 내의 사용 가능한 노드에 분산되므로 더욱 시간을 절약할 수 있습니다(하지만 여기에서 제시하는 시나리오는 항상 공유 리소스인 데이터베이스에 초점을 맞추고 있습니다).

하나 더

현재 상황에서는 사용자에게 상당한 시간 절약을 제공하여 앱을 사용하는 동안 사용자의 경험을 개선할 수 있기를 바랍니다. 하지만 한 가지 빠진 것이 있습니다.

도메인 모델에서 Item, ItemValue, ItemAttachment, ItemLink, AnaysedItem, AnalysedValue, AnalysedAttachment 간의 연결은 여전히 ​​자동 삭제 옵션이 구성되어 있습니다. 이제 Smart Delete 옵션을 사용하면 도메인 모델에서 이러한 객체를 자동으로 삭제해도 대상 데이터가 이미 삭제되었기 때문에 실제로는 아무것도 삭제되지 않습니다. 그러나 Mendix 런타임에서는 삭제할 레코드가 있는지 확인해야 하며, 이에 시간이 걸립니다.

마지막으로 도메인 모델에서 자동 삭제 옵션을 제거하고 스마트 삭제를 다시 실행하여 어떤 효과가 있는지 살펴보겠습니다.

이 변경을 한 후 이전과 같이 Smart Delete를 5번 실행하면 평균 경과 시간이 다음과 같이 생성됩니다. 10.0 초에 비해 29.4 초. 그래서 우리는 이제 '일반적인' 경과 시간을 줄였습니다. 163 몇 초 만에 10 초. 저에게는 승리처럼 들리지만, 소스를 삭제해도 종속성이 더 이상 계단식으로 내려가지 않으므로 앱의 다른 곳에서 이 데이터에 삭제를 적용해야 하는 경우 해당 솔루션도 설계해야 합니다.

결론

사용 작업 대기열 적절한 사용 사례에 신중하게 적용하면 경과 시간 성능을 크게 개선할 수 있습니다. 이 경우 테스트 결과는 사용자에게 상당한 절감을 보여줍니다.

마일리지는 다를 수 있습니다

아마 이 말은 필요 없겠지만, 이 기술을 사용하는 것의 이점(대규모 삭제뿐만 아니라 모든 유형의 프로세스)은 수행하는 작업의 복잡성과 도메인 모델, 환경에 여유 리소스가 얼마나 있는지, 그리고 모델을 얼마나 복잡하게 만들고 싶은지에 따라 크게 달라집니다. 다시 한번, 이전 블로그에서 코드를 읽기 쉽고 유지 관리하기 쉽게 유지하는 것에 대한 의견을 언급하겠습니다.

또한, 두 명 이상의 사용자가 동시에 소스 레코드를 삭제하는 경우 대기열 리소스가 공유되므로 각자가 절약하는 양이 줄어들 수 있습니다.

나는 이와 같은 기술을 실제 프로덕션 환경에서 사용했습니다(이전Mendix 9 그래서 ProcessQueue Marketplace 모듈을 사용했고) 저를 놀라게 하고 제품 소유자를 기쁘게 한 성능 향상을 이루었습니다. 그러니 브랜치를 만들어서 시도해 보세요.

즐거운 줄 서기를 바랍니다!