ASP.NET - 서버에서 파일의 압축을 풀라는 웹 페이지 요청

Question

우리는 사용 SharpZipLib.서버에 있는 파일의 압축을 풀고 별도의 폴더에 넣을 수 있어야 합니다.파일 압축 해제 요청은 웹 페이지의 사용자로부터 이루어집니다.파일이 충분히 크면 압축을 푸는 데 시간이 오래 걸릴 것 같아요. 우리는 사용자가 사이트 탐색을 계속하기 위해 압축 해제가 완료될 때까지 기다리는 동안 페이지에 머무르는 것을 원하지 않습니다.

이 시나리오를 처리하는 좋은 방법은 무엇입니까?파일 압축 해제를 처리하기 위해 다른 스레드를 스핀오프하거나, 파일 압축을 해제하는 별도의 Windows 서비스를 생성하거나, 또는 ....무엇을?

별도의 스레드나 창 서비스를 통해 이를 수행할 때의 장단점은 무엇입니까?

Answer 1

별도 공정의 장점
별도의 프로세스에서 수행된 작업은 시간적으로나 물리적으로나 보안 관점에서 페이지 흐름에서 분리될 수 있습니다.시간에 따라 분리됨:원하는 경우 로드가 낮아지고 이를 수행할 여유 CPU 주기가 있을 때 "나중에"까지 압축 해제 요청을 버퍼링할 수 있습니다.

또한 물리적으로 분리되었습니다.대규모 시스템의 경우 여러 작업자 프로세스를 보유할 수 있으며 여러 독립 시스템에 배포하여 이 작업을 비동기식으로 수행할 수 있으며 해당 처리 계층은 웹 페이지 처리와 독립적으로 확장될 수 있습니다.모든 시스템에는 병목 현상이 있으며, 분산 배포의 장점은 별도의 워크로드를 독립적으로 확장하여 병목 현상을 보다 효율적으로 제거할 수 있다는 것입니다.

하지만 후자의 이점은 매우 대규모 시스템에서만 유용하다고 말하고 싶습니다.대부분의 경우 독립적인 물리적 확장 계층의 이점을 누릴 수 있는 종류의 트랜잭션 볼륨이 없습니다.이는 비단 비단 사실이 아니다. 당신의 전체 워크로드의 98%를 차지합니다.YAGNI 원칙은 확장성에도 적용됩니다.

물리적 분리를 통해 서로 다른 워크로드(페이지 흐름 및 zip 압축 풀기)를 독립적으로 개발할 수도 있습니다.즉, 작업 항목이 단순한 "파일 압축 풀기"가 아니라 여러 단계와 결정 지점이 있는 더 복잡한 작업이라고 가정합니다.별도의 프로세스에서 작업 프로세서를 설계하면 작업 항목 처리와 독립적으로 페이지 흐름을 구축하고 테스트할 수 있습니다.독립적으로 진화해야 한다면 이는 좋은 이점이 될 수 있습니다.

이러한 물리적 분리는 작업 항목이 다른 채널을 통해 도착하는 경우에도 유용합니다.웹 페이지가 작업 항목을 도착하는 유일한 방법이 아니라고 가정해 보겠습니다.FTP 드롭, 웹 서비스 또는 작업 항목을 수신할 수 있는 시스템 모니터링 이메일 상자가 있다고 가정해 보세요.그러한 경우 작업 항목 처리를 웹 페이지 처리와 물리적으로 분리하는 것이 합리적입니다.

마지막으로 이러한 것들은 런타임 시 보안 측면에서 분리됩니다.일부 웹앱 서버 배포에서는 보안 규칙에 따라 웹 서버가 디스크에 쓰는 것을 금지합니다. 웹 서버에는 쓰기 가능한 디스크 저장소가 없습니다.별도의 비동기 작업자 프로세스는 충분한 저장 공간을 갖춘 네트워크의 별도 부분에 배포될 수 있으며 아마도 별도의 보안 요구 사항 집합으로 인해 제한될 수 있습니다.이는 귀하에게 적용될 수도 있고 적용되지 않을 수도 있습니다.

스레드 처리의 장점
별도의 스레드에서 작업을 수행하면 훨씬 간단하다는 장점이 있습니다.디커플링으로 인해 복잡성과 비용이 발생합니다.별도의 스레드에서 작업을 관리하면 별도의 프로세스, 잠재적으로 별도의 시스템을 관리하는 데 따른 운영 오버헤드가 없습니다.추가 구성이나 새로운 빌드/배포 단계가 없습니다.추가 백업이 없습니다.유지 관리할 추가 보안 ID가 없습니다.걱정할 통신 교환이 없습니다(스레드 디스패치 외에).

작업 항목 처리에 대해 좀 더 정교하게 선택하고 zip 파일이 충분히 작아 보일 때 선택적으로 작업을 동기식으로 수행하도록 선택할 수 있습니다.응답 시간 임계값을 4초로 설정한다고 가정해 보겠습니다. 그 이상인 경우 비동기 작업 부하가 필요하고, 4초 미만인 경우 "인라인"으로 수행합니다.물론 zip 파일이 얼마나 오래 걸릴지 확실히 알 수는 없지만 파일 크기를 기반으로 좋은 휴리스틱을 설정할 수 있습니다.이 최적화는 비동기 작업을 위해 외부 프로세스를 사용하든, 별도의 스레드를 사용하든 상관없이 사용할 수 있지만, 솔직히 말하면 별도의 스레드를 사용할 때 최적화를 활용하는 것이 더 간단합니다.추가 작업이 줄어듭니다.따라서 이는 스레드 접근 방식의 장점입니다.

비차별화 요소
작업 항목 상태 알림을 위해 AJAX 폴링 메커니즘을 사용하도록 선택한 경우 이는 별도의 프로세스 또는 별도의 스레드에서 작동합니다.작업 항목 추적을 어떻게 수행할지 모르겠지만 특정 작업 항목(zip 파일?)이 완료되면 파일 시스템의 파일, 데이터베이스의 테이블 등 어딘가에서 레코드를 업데이트할 것이라고 가정합니다. .해당 업데이트는 동일한 프로세스의 스레드에서 수행되거나 별도의 프로세스(Windows 서비스)에서 수행되는지 여부에 관계없이 발생합니다.따라서 폴링하는 AJAX 클라이언트는 어떤 경우에도 DB 테이블이나 파일 시스템을 확인하고 아키텍처 결정에 관계없이 동일한 방식으로 작업 항목 상태에 대한 알림을 받습니다.

결정하는 방법
이론은 흥미롭지만 실제 작동 제약이 없으면 궁극적으로 쓸모가 없습니다.

작업량은 실제 핵심 항목 중 하나입니다.이 zip 파일의 크기를 언급하지 않았지만 "보통 크기"라고 추측합니다.약 4GB 이하입니다.일반적으로 이와 같은 zip 파일은 내 노트북에서 압축을 푸는 데 20~60초가 걸리지만 물론 실제 스토리지 시스템과 더 빠른 CPU를 갖춘 서버에서는 그 시간이 더 짧습니다.또한 트랜잭션의 동시성을 특성화하지 않았습니다. 이러한 일이 한 번에 얼마나 많이 일어날 것인지를 지정하지 않았습니다.동시성이 특별히 높지는 않다고 가정합니다.

그렇다면 저는 더 간단한 비동기 스레드 접근 방식을 고수하겠습니다.ASP.NET에서 이 작업을 수행하고 있으며 서버 OS에서 수행한다고 가정합니다.CLR에는 우수한 스레드 관리 기능이 있고 ASP.NET에는 우수한 프로세스 확장 기능이 있습니다.따라서 워크로드가 높은 경우에도 많은 구성 노력 없이도 우수한 CPU 활용도와 확장성을 얻을 수 있습니다.

작업 항목이 더 오래 실행되는 경우(예를 들어 몇 시간 또는 며칠 정도이고 시간을 예측할 수 없는 경우(예: 재고 주문 마감)) 그런 경우에는 비동기 프로세스를 사용하게 됩니다.동시성이 초당 수천 개이거나 다시 예측할 수 없는 경우에도 별도의 프로세스가 권장됩니다.실패 모드가 충분히 복잡하다면 작업 항목을 관리하기 위해 별도의 프로세스에 두기를 원할 수도 있습니다.작업 항목 처리가 정기적으로 변경될 가능성이 있는 경우(변화하는 비즈니스 상황에 따라 추가 단계 추가) 별도의 프로세스를 원할 수도 있습니다.

그러나 귀하의 경우에는 zip 파일의 압축을 푸는 것 중 어느 것도 사실이 아닌 것 같습니다.

Answer 2

별도의 스레드의 단점은 다음과 같습니다.

1. 페이지가 끝나면 다른 스레드가 수행하는 작업에 대한 알림을 쉽게 알 수 없습니다.
2. 응용 프로그램은 언제든지 다시 시작할 수 있습니다.
3. 사용자가 페이지를 빠르게 연속적으로 제출하면 실수로 프로세스를 두 번 시작하는 것이 쉽습니다.
4. 멀티 스레드 코드는 디버그하기 어렵습니다.

별도의 스레드의 장점은 다음과 같습니다.

1. 적은 코드
2. 실선이 완료되면 사용자에게 알릴 필요가없는 경우 잊어 버리고 잊어 버립니다.
3. 설치할 추가 작업이 없습니다.

Windows 서비스의 장점과 단점은 위의 반대입니다.

Answer 3

개인적으로 나는 Return a와 같은 진보를 위해 그들 사이의 메시지와 함께 Windows 서비스 경로를 내려갑니다. handle 상태를 모니터링하는 데 사용할 수있는 압축에.

그러나 당신은 아마도 스레드를 스핀으로 만들어서 그것을 수행하고 행복하게 실행되고 페이지가 돌아올 수 있다고 생각할 수도 있습니다.

Answer 4

Ajax 활성화 페이지에서 쉽게 폴링 할 수있는 비동기 프로세스를 사용합니다. 완료되면 페이지의 Ajax 부분은 사용자가 프로세스가 동기식으로 완료되기를 기다리는 동안 일반적으로 제시했던 세부 사항을 제시 할 수 있습니다.