Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

제니퍼: 9. 성능 관리 퀴즈 세 번째 문제 (닷넷 개발자 컨퍼런스)


제니퍼: 7. 성능 관리 퀴즈 첫 번째 문제 (닷넷 개발자 컨퍼런스)
; https://www.sysnet.pe.kr/2/0/875

제니퍼: 8. 성능 관리 퀴즈 두 번째 문제 (닷넷 개발자 컨퍼런스)
; https://www.sysnet.pe.kr/2/0/876

위의 문제에 이어서!




[퀴즈 3] 왜 100개까지만 요청이 제한되는가?


ASP.NET으로 웹 페이지를 하나 만들고, 코드는 단지 "Thread.Sleep(20 * 1000);"만 넣은 상태입니다. 클라이언트 응용 프로그램에서는 스레드 120개를 만들어서 해당 웹 페이지에 요청을 동시에 보냅니다.

이때 ASP.NET을 호스팅하는 환경은 "Windows 서버 + IIS 6/7/7.5 + CLR 2.0"입니다.

정상적이라면 120개 정도의 동시 요청이 처리되고 있어야 하는데, 확인해 보면 100까지만 동시 요청이 처리됩니다. 그 이유는? (환경만 일치한다면, 직접 확인해 보실 수 있습니다.)




위의 문제들에서 알 수 있는 점은, 기본 상태의 윈도우 서버 시스템에서 처리가 긴 작업(Long-running process)이 일시에 몰리는 경우 해당 시스템이 그 이상의 작업을 할 수 있는데도 불구하고 서비스가 제한된다는 것을 보여주고 있습니다.

물론, 스레드가 100개 이상이 될 수 있도록 시스템을 만드느냐에 대해서는 고려 사항이 있을 수 있습니다. 단지 여기서 중요한 점은, 서버가 적절하게 모니터링 되고 있어야 그에 대한 적절한 판단을 할 수 있다는 점입니다.

모니터링하고 있는 시스템이 공유 리소스에 대한 접근을 하는 aspx들에 대한 요청이 몰리게 되고 잠금으로 인해 시간이 걸리는 상황에서는 100개까지의 제한을 둘 필요는 없습니다. 왜냐하면, 공유 리소스를 접근하지 않는 다른 aspx 페이지들까지도 요청을 못 받아들이기 때문입니다. (혹은, 제니퍼의 PLC(Peak Load Control) 기능같은 방법도 해결책이 될 수 있습니다.)

혹시, 지금 여러분들의 웹 서버를 한 대 더 늘려야겠다고 판단하고 계시지 않은가요?
그렇다면, 정말 그 웹 서버를 늘려야 할 이유가 어떤 것인지 정확하게 모니터링이 된 걸까요?







[최초 등록일: ]
[최종 수정일: 6/12/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  5  6  7  8  9  10  11  12  13  [14]  15  ...
NoWriterDateCnt.TitleFile(s)
13712정성태8/14/202412600개발 환경 구성: 720. Synology NAS - docker 원격 제어를 위한 TCP 바인딩 추가
13711정성태8/13/202413698Linux: 77. C# / Linux - zombie process (defunct process) [1]파일 다운로드1
13710정성태8/8/202414863닷넷: 2294. C# 13 - (6) iterator 또는 비동기 메서드에서 ref와 unsafe 사용을 부분적으로 허용파일 다운로드1
13709정성태8/7/202412697닷넷: 2293. C# - safe/unsafe 문맥에 대한 C# 13의 (하위 호환을 깨는) 변화파일 다운로드1
13708정성태8/7/202413533개발 환경 구성: 719. ffmpeg / YoutubeExplode - mp4 동영상 파일로부터 Audio 파일 추출
13707정성태8/6/202413123닷넷: 2292. C# - 자식 프로세스의 출력이 4,096보다 많은 경우 Process.WaitForExit 호출 시 hang 현상파일 다운로드1
13706정성태8/5/202412258개발 환경 구성: 718. Hyper-V - 리눅스 VM에 새로운 디스크 추가
13705정성태8/4/202412832닷넷: 2291. C# 13 - (5) params 인자 타입으로 컬렉션 허용 [2]파일 다운로드1
13704정성태8/2/202414353닷넷: 2290. C# - 간이 dotnet-dump 프로그램 만들기파일 다운로드1
13703정성태8/1/202412735닷넷: 2289. "dotnet-dump ps" 명령어가 닷넷 프로세스를 찾는 방법
13702정성태7/31/202413935닷넷: 2288. Collection 식을 지원하는 사용자 정의 타입을 CollectionBuilder 특성으로 성능 보완파일 다운로드1
13701정성태7/30/202415455닷넷: 2287. C# 13 - (4) Indexer를 이용한 개체 초기화 구문에서 System.Index 연산자 허용파일 다운로드1
13700정성태7/29/202414638디버깅 기술: 200. DLL Export/Import의 Hint 의미
13699정성태7/27/202415285닷넷: 2286. C# 13 - (3) Monitor를 대체할 Lock 타입파일 다운로드1
13698정성태7/27/202413953닷넷: 2285. C# - async 메서드에서의 System.Threading.Lock 잠금 처리파일 다운로드1
13697정성태7/26/202412455닷넷: 2284. C# - async 메서드에서의 lock/Monitor.Enter/Exit 잠금 처리파일 다운로드1
13696정성태7/26/202413134오류 유형: 920. dotnet publish - error NETSDK1047: Assets file '...\obj\project.assets.json' doesn't have a target for '...'
13695정성태7/25/202412737닷넷: 2283. C# - Lock / Wait 상태에서도 STA COM 메서드 호출 처리파일 다운로드1
13694정성태7/25/202412647닷넷: 2282. C# - ASP.NET Core Web App의 Request 용량 상한값 (Kestrel, IIS)
13693정성태7/24/202412287개발 환경 구성: 717. Visual Studio - C# 프로젝트에서 레지스트리에 등록하지 않은 COM 개체 참조 및 사용 방법파일 다운로드1
13692정성태7/24/202414335디버깅 기술: 199. Windbg - 리눅스에서 뜬 닷넷 응용 프로그램 덤프 파일에 포함된 DLL의 Export Directory 탐색
13691정성태7/23/202413149디버깅 기술: 198. Windbg - 스레드의 Win32 Message Queue 정보 조회
13690정성태7/23/202411401오류 유형: 919. Visual C++ 리눅스 프로젝트 - error : ‘u8’ was not declared in this scope
13689정성태7/22/202415159디버깅 기술: 197. Windbg - PE 포맷의 Export Directory 탐색
13688정성태7/21/202412157닷넷: 2281. C# - Lock / Wait 상태에서도 일부 Win32 메시지 처리파일 다운로드1
13687정성태7/19/202413999닷넷: 2280. C# - PostThreadMessage로 보낸 메시지를 Windows Forms에서 수신하는 방법파일 다운로드1
1  2  3  4  5  6  7  8  9  10  11  12  13  [14]  15  ...