정리하며 배우다.

.NET 8 버전이 Preview 상태에서 장기지원 버전으로 상향됬다는 소식에, .NET 8.0 을 설치했는데요.

첫 설치 후 Visual Studio 2022에서 ASP.NET Core 웹앱 (MVC 모델) 템플릿을 이용해서 프로젝트를 생성 하고 기본적인 실행을 했는데요.

정상적으로 실행이 되지 않고, 

• /Views/Home/Index.cshtml
• /Views/Shared/Index.cshtml

파일을 찾지 못한다는 에러가 발생해서 원인을 찾아봤습니다. 

01. 프로젝트 생성, MVC 템플릿

.NET 8.0 을 설치 한 후, ASP.NET Core 웹앱 (Model - View - Controller) 템플릿을 이용해서 프로젝트를 생성하였습니다. 

아직은 Preview 로 보여지는거 같지만, 프레임워크 버전을 8.0 으로 선택을하고 프로젝트를 정상적으로 만들었는데요.

이후 컴파일 후 실행을 하였습니다. 

02. /Views/Home/Index.cshtml not found 에러 발생

An unhandled exception occurred while processing the request.
InvalidOperationException: The view 'Index' was not found. The following locations were searched:
/Views/Home/Index.cshtml
/Views/Shared/Index.cshtml
Microsoft.AspNetCore.Mvc.ViewEngines.ViewEngineResult.EnsureSuccessful(IEnumerable<string> originalLocations)

빌드 후 첫 실행을 진행했는데요. "An unhandled exception occurred while processing the request." 에러가 발생을 하였습니다.  거기다가 Index 를 찾지 못한다는 에러였는데요. 

설마.. 기본적으로 Razor RuntimeCompilation 이 빠진건가요;

실행은 되게끔 템플릿 구성을 해줘야 하는게 아닌지 싶었지만, 일단 오류를 잡아봅니다.

03. Razor.RuntimeCompilation Nuget 설치

해당 오류를 수정하기 위해서는 별도의 Nuget 패키지를 설치해야 하는데요. 

정확한 명칭은 아래와 같습니다.  

Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation

해당 패키지를 검색해서 설치를 진행해 줬고요. .NET 8.0 버전을 사용하고 있으니, 같은 버전으로 설치를 진행하였습니다. 

04. 서비스 컨테이너 부분 수정.

internal class Program
{
    private static void Main(string[] args)
    {
        var builder = WebApplication.CreateBuilder(args);

        // Add services to the container.
        builder.Services.AddControllersWithViews();

        var app = builder.Build();

        // Configure the HTTP request pipeline.
        if (!app.Environment.IsDevelopment())
        {
            app.UseExceptionHandler("/Home/Error");
            // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
            app.UseHsts();
        }

        app.UseHttpsRedirection();
        app.UseStaticFiles();

        app.UseRouting();

        app.UseAuthorization();

        app.MapControllerRoute(
            name: "default",
            pattern: "{controller=Home}/{action=Index}/{id?}");

        app.Run();
    }
}

builder.Services.AddControllersWithViews().AddRazorRuntimeCompilation();

설치 후, 컨테이너 부분에 RazorRuntimeCompilation 을 추가적으로 붙여줘야 하는데요. 

위 처럼 AddControllersWithViews() 뒤에 붙여주시면 정상적으로 동작하는 것을 확인 하실 수 있습니다. 

Footer 에 해당하는 부분이 상단에 붙어 있는데요. 해당 부분이 왜 이런지는 추가적으로 확인해 봐야겠네요.

아직 미흡한 부분이 있는 것인지, 호환이 되지 않는 것인지 확인이 필요해 보이지만

템플릿에 해당하는 예시적인 화면이다보니, 크게 중점을 두지는 않아도 될것 같습니다. 

참조

https://www.reddit.com/r/dotnet/comments/14zd7zp/brand_new_default_aspnet_core_mvc_8_project/

https://learn.microsoft.com/ko-kr/aspnet/core/mvc/views/view-compilation?view=aspnetcore-8.0&tabs=visual-studio

END

Jenkins의 보안상의 이슈로 Jenkins 버전을 2.3xx 에서, 2.4xx 이상의 버전으로 업데이트를 진행 하였습니다. 그 과정에서 예전에 사용하던 GitLab API PlugIn에 UI가 변경이 되었는데요. 

아직 2.3xx 대의 버전을 사용하시는 분들이라면, 이전 글을 참고 하시면 좋을 것 같습니다. 

2023.06.05 - [CI] - [Jenkins] GitLab Webhooks를 이용한 젠킨스 연동 및 빌드유발

01. Jenkins 버전 업그레이드

Jenkins의 버전 업그레이드는, 관리 메뉴에서 진행하면 손쉽게 진행할 수 있어서 넘어가도록 하겠습니다. 

02. 2.4 버전의 업그레이드 이후 PlugIn 변경

어떠한 이유인지는 모르겠으나, 2.3xx 버전에서 사용중이던 GitLab Plugin이 2.4xx 버전대에서는 검색이 안되고, 

다른 GitLab API Plugin 이 검색이 되었습니다. 한참을 검색하였지만 찾지 못해서, 해당 Plugin을 설치 하였는데요.

※ 단, 기존 GitLab Plugin이 설치된 상태에서 업그레이드를 했을 경우에는 기존 Plugin을 사용할 수 있었습니다. 

03. 빌드유발 변경하기

GitLab Plugin과는 다르게, 빌드유발 탭에서는 Generic Webhook Trigger 의 체크박스로 표현이 되고 있었습니다. 

호출 URL도 

http://JENKINS_URL/generic-webhook-trigger/invoke

로 기존의 형태와는 다르게 표현이 되었습니다. 

하지만 호출 방식이 크게 어렵지는 않고, Token 생성시, 하단의 Token 입력상자에 입력해주시면 됩니다. 

04. 토큰 생성하기

해당 API 토큰은, 유저를 관리하는 메뉴에서 해당 프로젝트에 권한이 있는 계정에 설정 메뉴에서 만드실 수 있습니다. 

05. 외부호출 URL 만들기

http://localhost:8080/generic-webhook-trigger/invoke?token=110a56287a6bdcd9a3b3055e9b6af3cdc7

이제 위에서 언급한 URL을 이용해서, 외부에서 호출할 URL을 만들면 되는데요. 
http://JENKINS_URL/generic-webhook-trigger/invoke

해당 정보에, 위에서 만든 token 값을 추가해서 get 형식으로 URL을 작성해서 호출하면 

정상적으로 빌드가 동작합니다. 

END

Windows Server 계열에서 IIS를 설치하는 여러가지 방법이 있는데요. 지난번 포스팅에서는 PKGMGR (패키지매니저)를 이용했다면, 이번 포스팅은 DISM 배포 이미지 서비스를 이용해서 IIS 워크로드를 설치 및 설정하는 방법을 정리하였습니다. 

이전글

https://holjjack.tistory.com/226

01. DISM 이란?

배포 이미지 서비스 및 관리(DISM.exe)는 Windows PE, Windows RE(Windows 복구 환경) 및 Windows 설치 프로그램에 사용되는 이미지를 포함하여 Windows 이미지를 제공 및 준비하는 데 사용할 수 있는 명령줄 도구입니다. 

DISM은 Windows 이미지(.wim) 또는 가상 하드 디스크(.vhd 또는 .vhdx)를 제공하는 데 사용할 수 있습니다.

DISM은 Windows에 기본 제공되며 명령줄 또는 Windows PowerShell을 통해 사용할 수 있습니다. 

02. PowerShell 에서 목록 확인하기

PS> dism /online /get-features

PowerShell 에서 해당 명령어를 이용해서 DISM으로 설치 가능한 목록을 확인 할 수 있습니다. 

03. CMD 창에서 확인하기

/>  dism /online /get-features | find "IIS"

명령 프롬프트 이용시에는 find 명령어를 사용할 수 있기 때문에, PowerShell 보다는 목록을 확인하는데 유용했습니다.

04. DISM 스크립트

DISM.EXE /enable-feature /online /featureName:IIS-WebServerRole /featureName:IIS-WebServer 
/featureName:IIS-CommonHttpFeatures /featureName:IIS-StaticContent /featureName:IIS-DefaultDocument 
/featureName:IIS-DirectoryBrowsing /featureName:IIS-HttpErrors /featureName:IIS-HttpRedirect 
/featureName:IIS-ApplicationDevelopment /featureName:IIS-ASPNET /featureName:IIS-NetFxExtensibility 
/featureName:IIS-ASPNET45 /featureName:IIS-NetFxExtensibility45 /featureName:IIS-ASP /featureName:IIS-CGI 
/featureName:IIS-ISAPIExtensions /featureName:IIS-ISAPIFilter /featureName:IIS-ServerSideIncludes 
/featureName:IIS-HealthAndDiagnostics /featureName:IIS-HttpLogging /featureName:IIS-LoggingLibraries 
/featureName:IIS-RequestMonitor /featureName:IIS-HttpTracing /featureName:IIS-CustomLogging 
/featureName:IIS-ODBCLogging /featureName:IIS-Security /featureName:IIS-BasicAuthentication 
/featureName:IIS-WindowsAuthentication /featureName:IIS-DigestAuthentication 
/featureName:IIS-ClientCertificateMappingAuthentication /featureName:IIS-IISCertificateMappingAuthentication 
/featureName:IIS-URLAuthorization /featureName:IIS-RequestFiltering /featureName:IIS-IPSecurity 
/featureName:IIS-Performance /featureName:IIS-HttpCompressionStatic /featureName:IIS-HttpCompressionDynamic 
/featureName:IIS-WebDAV /featureName:IIS-WebServerManagementTools /featureName:IIS-ManagementScriptingTools 
/featureName:IIS-ManagementService /featureName:IIS-IIS6ManagementCompatibility /featureName:IIS-Metabase 
/featureName:IIS-WMICompatibility /featureName:IIS-LegacyScripts /featureName:IIS-FTPServer /featureName:IIS-FTPSvc 
/featureName:IIS-FTPExtensibility /featureName:NetFx4Extended-ASPNET45 /featureName:IIS-ApplicationInit 
/featureName:IIS-WebSockets /featureName:IIS-CertProvider /featureName:IIS-ManagementConsole /featureName:IIS-LegacySnapIn

위 스크립트를 이용하면, DISM 매니저를 이용해서 IIS 워크로드를 손쉽게 구성할 수 있습니다. PKGMGR 보다는 조금더 길이가 늘어났지만, 다른점이라고는 /featureName을 하나씩 명시적으로 입력해줘야 하네요.

해당 스크립트를 원격으로 실행시, 재시작을 대기하는 상황이 발생하는데요. 

이럴경우에는 /NoRestart 옵션을 사용해주면 재시작하지 않고 설치가 가능합니다.

DISM.EXE /enable-feature /online /NoRestart /featureName:IIS-WebServerRole /featureName:IIS-WebServer
...
...

참조

END

동일한 웹서버에 같은 환경의 IIS 를 여러대 설정해야할 경우, 스크립트를 사용해서 설치하는 방법이 매우 유용합니다.

Cloud 환경에 웹서버를 구성할 경우 용이하게 이용하실 수 있습니다.

아래의 설치 방법은 Pkgmgr.exe 를 이용한 방법이며, IIS 8.5 이상에서는 DISM.exe 를이용한 설치방법을 권장하고 있으나,Pkgmgr.exe 로도 설치는 가능하니 참고하세요.

스크립트를 이용한 IIS 설치

스크립트를 사용하여 IIS 7.5를 설치할 수도 있습니다. 이 스크립트를 사용하면 사용 가능한 모든 기능 패키지를 설치하는 전체 IIS 설치를 얻게 됩니다. 필요하지 않은 기능 패키지가 있는 경우 필요한 패키지만 설치하도록 스크립트를 편집해야 합니다.

스크립트를 사용하여 IIS 설치를 자동화하는 것은 여러 웹 서버를 배포해야 하고 각 웹 서버가 동일한 구성 요소와 서비스로 설정되어 있는지 확인하려는 경우에 매우 유용합니다.

Windows Server 2008 및 Windows Vista 운영 체제에서 Pkgmgr.exe는 무인 스크립트에 사용되므로 명령 프롬프트 또는 스크립트에서 선택적 기능을 설치하거나 제거할 수 있습니다. (참고: Pkgmgr.exe는 Windows Server® 2003에서 사용된 Sysocmgr.exe를 대체합니다.)

스크립트

CMD /C START /w PKGMGR.EXE /l:log.etw /iu:IIS-WebServerRole;IIS-WebServer;
IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;
IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASP;IIS-CGI;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;
IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;
IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;
IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;
IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;
IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementScriptingTools;
IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;
WAS-WindowsActivationService;WAS-ProcessModel;IIS-ASPNET;IIS-NetFxExtensibility;
WAS-NetFxEnvironment;WAS-ConfigurationAPI;IIS-ManagementService;MicrosoftWindowsPowerShell;
IIS-ASPNET;IIS-ASPNET45;IIS-NetFxExtensibility45;NetFx4Extended-ASPNET45;IIS-ApplicationInit;
%windir%\system32\inetsrv\appcmd set config /section:httpLogging /dontLog:True

위 내용을 bat 파일로 만드셔서 이용하시면 편리합니다.

또한 추가적으로 설치가 필요한 부분은 IIS-xxx 형태의 옵션을 찾으셔서 포함하면 됩니다.

예를 들어 웹소켓 설치시,

IIS-WebSockets;

를 추가 하면 됩니다.

참고

https://docs.microsoft.com/en-us/iis/install/installing-iis-7/installing-iis-7-and-above-on-windows-server-2008-or-windows-server-2008-r2

이 포스트는 아래의 Blog를 번역한 글이며, 영어공부 겸, 지식을 전달하기 위한 목적으로 작성된 글입니다.

보시기 불편하시거나, 해당글의 무분별한 포스팅이 문제가 된다면, 삭제하겠습니다.

https://stackify.com/w3wp-high-cpu-usage/

w3wp.exe IIS 작업자 프로세스의 높은 CPU 점유율은 많은 이유가 있습니다.

6개의 공통된 원인을 이 포스트에서 선택했습니다. 

• ASP.NET 어플리케이션의 높은 에러율
• 높은 CPU의 원인이 되는 웹 트래픽 증가.
• 어플리케이션의 의존성 문제
• GC (Garbage collection)
• ASP.NET 파이프 라인에서 요청이 차된되거나, 중단된 경우
• 최적화가 필요한 비효율적인 .NET 코드

Microsoft.NET 은 가비지 수집을 활용해서 메모리 할당 및 해제를 관리합니다.

어플리케이션이 수행하는 작업에 따라, 어플리케이션의 메모리 할당 및 정리에 많은 GC 활동이 발생 할 수 있습니다. 

예를들어, 대형 개체 힙에 대형 문자열 변수를 많이 사용하면, 가비지 수집에 문제가 발생합니다. 

가비지 컬렉션이 어플리케이션에 문제를 일이킬 수 있는지 측정하려면, Windows의 성능 모니터를 확인하세요.

.NET CLR Memory -> % Time in GC

이 카운터는 어플리케이션이 가비지 컬렉션을 수행하는데 소요되는 시간 (%) 을 반영합니다. 만약 이 수치가 5~10%를 넘게 급증하면 메모리 사용량을 더 자세히 조사해야 합니다. 

.NET Framework 2.0 버전을 사용중이라면, 서버모드를 활성화 해야 할 수도 있습니다. 

<configuration
   <runtime>
      <gcServer enabled="true"/>
   </runtime>
</configuration>

ASP.NET request 의 lifecycle 에는 여러 단계가 있습니다. 여기에는 요청시작, 인증, 권한 부여, 올바른 HTTP 핸들러 평가 및 요청완료와 같은 기본적인 단계가 포함됩니다. 그 일환으로 사용 가능한 표준 및 사용자 정의 HTTP 모듈이 많이 있습니다.

성능문제가 있는 경우 모든 요청이 특정 HTTP모듈에 정지된 것처럼 보이는지 살펴보는 것이 좋습니다. 

HTTP 모듈은 네이티브 코드이거나 관리되는 .NET 코드일 수 있습니다. 

FormsAuthenticaion 또는 SessionStateModule과 같은 표준 .NET 모듈일 수 있습니다. 많은 애플리케이션은 타사 또는 사용자 정의 HTTP 모듈도 사용합니다.

세션을 사용하고 있습니까?
대부분의 사람들은 ASP.NET 세션으로 인해 얼마나 많은 성능 오버헤드가 발생하는지 알지 못합니다.
페이지를 로드할 때마다 IIS 작업자 프로세스가 세션 개체를 검색하고 잠근 다음 요청이 끝나면 해제합니다.
세션으로 인해 잠금이 발생하고 애플리케이션 내에서 병목 현상이 발생할 수 있습니다.
Redis 또는 SQL과 같은 세션 공급자를 사용하는 경우 성능 저하가 애플리케이션 성능에 영향을 미칩니다.

다른 일반적인 원인중 어느것도 문제가 되지 않는 경우, 코드를 자세히 살펴보고 개선해야 할 수 도 있습니다.

코드에서 호출되는 메서드와 소요시간을 캐처하려면 .NET 코드 프로파일러를 사용해야 합니다.

프로파일러는 코드에서 속도가 매우 느린 특정 메서드를 식별하는데 도움이 됩니다.

경고: 프로파일러는 어플리케이션의 오버헤드를 추가합니다. 따라서 어플리케이션의 CPU 사용량이 이미 매우 높으면 (90%+) 프로파일링이 매우 느려지고 어플리케이션 성능이 저하됩니다.

이로 인해 수행중인 프로파일링의 세부수준과 프로파일링을 시작하기 전의 CPU 사용량에 따라 어플리케이션을 사용 할 수 없게 될 수 있습니다. 

.NET 프로파일러는 RedGate의 ANTS 성능프로파일러가 있습니다. 

https://www.red-gate.com/products/ants-performance-profiler/

https://stackify.com/w3wp-high-cpu-usage/

END

이 포스트는 아래의 Blog를 번역한 글이며, 영어공부 겸, 지식을 전달하기 위한 목적으로 작성된 글입니다.

보시기 불편하시거나, 해당글의 무분별한 포스팅이 문제가 된다면, 삭제하겠습니다.

https://stackify.com/w3wp-high-cpu-usage/

w3wp.exe IIS 작업자 프로세스의 높은 CPU 점유율은 많은 이유가 있습니다.

6개의 공통된 원인을 이 포스트에서 선택했습니다. 

• ASP.NET 어플리케이션의 높은 에러율
• 높은 CPU의 원인이 되는 웹 트래픽 증가.
• 어플리케이션의 의존성 문제
• GC (Garbage collection)
• ASP.NET 파이프 라인에서 요청이 차된되거나, 중단된 경우
• 최적화가 필요한 비효율적인 .NET 코드

응용프로그램에서 응용프로그램의 에러가 발생할 수 있으며, 사용자는 알지 못합니다. 일부 오류는 당신의 유저가 특정형식의 오류 메시지를 받는 원인이 될것입니다. 다른 오류가 발생할 수 있고, 그것에 대해 아무도 알지 못합니다.

당신이 에러 모니터링 또는 응용프로그램 성능 관리 툴을 사용한다면, 높은 에러율을 체크할 수 있습니다

윈도우즈 Event Viewr, IIS 로그 등에서 응용프로그램 에러율과 실제 에러를 찾을 수 있는 몇가지 위치가 있습니다.

에러율을 위한 윈도우즈 성능 카운터

높은 에러율을 검토할 것을 권장하는, 두가지 특정 성능 카운터를 추천한다. 윈도우즈에서 성능 모니터를 열고, 챠트보기에서 카운터를 추가하여야 합니다.

• .NET CLR Exceptions -> # of Exceps Thrown / Sec : 이것은 당신의 응용프로그램의 많은 예외 상황을 보여줄 겁니다. 당신의 응용프로그램에 큰 성능 문제의 원인이 되는 숨겨진 많은 오류가 있을 수 있습니다. 예외는 않좋으나, 그것을 피할 수는 없습니다.
• W3SVC_W3WP -> %500 HTTP Response Sent : 상태 코드가 500인 모든 요청은 내부 서버코드 에러 입니다. 이 확율이 매우 낮은지 확인하세요. 0~1% 여야 합니다.

w3wp.exe 의 높은 CPU 사용량에 대한 가장 간단한 설명 중 하나는 웹 트래픽 증가 입니다. 그러나 정상적인 트래픽 양에 대한 기준이 없는 경우, 트래픽이 증가했는지 알기 어려울 수 있습니다.

트래픽을 추적하는 응용프로그램 모니터링 툴을 사용하는 경우, 이를 확인하고 트래픽 레벨이 변경되었는지 확인하십시오.

트레픽 레벨이 변경되었는지 알수있는 방법이 없는 경우, IIS 로그 파일을 사용해서 알아 볼 수 있습니다.

VisualLogParser 또는 Log Parser Lizard를 이용해서 질의할 수 있습니다.

또는 Requests / Sec 와 Requests Corrent 에 대한 윈도우 성능 카운터가 있어서 현재 트래픽 속도를 실시간으로 확인 할 수 있습니다. 

웹 트래픽 증가에 대한 가능한 이유

트레픽 레벨이 높은경우, 당신은 그 수준이 높아야 하는지 평가해야 합니다. 트래픽 레벨 증가와 관련하여 고려해야 할 몇가지 사항은 다음과 같습니다.

• 고객 또는 유저 : 특별한 고객, 유저, 또는 자원으로 부터 트래픽이 급증했습니까? 아마도 가끔 당신의 사이트에 접속하는 것이 작동하지 않을 수 있습니다. 특정 IP 주소를 차단이 필요할 수 있습니다.
• Bots : 비슷한 특별한 유저가 많은 트래픽의 원인이라면, 그것은 봇일 수 있습니다. IIS 로그에서 당신의 사이트 접속하는데 사용되는 사용자 에이전트를 확인하세요. 
• 오프라 효과 : 오프라(오프라윈프리)나 누군가가 당신의 제품을 언급했나요? 방금 입소문을 냈나요? 엄청나게 많은 관심을 받는 것은 좋은 일이지만, 이를 처리하기 위해 성능을 확장해야 할 수 있습니다.

당신의 사이트가 많은 트래픽을 받을 경우, 대용량 서버(스케일업) 또는 다수의 서버(스케일아웃)이 필요할 수 있습니다.

그러나 초당 많은 요청을 받지 않을 경우, 트래픽이 문제가 되지 않을 수 있습니다.

많은 ASP.NET 어플리케이션은 초당 10-30개 요청이 있습니다. 그러나 바쁜 앱에서 초당 100개 이상의 요청을 수행하는 가벼운 요청도 보았습니다.

하나의 웹앱에서 다른 웹 앱으로의 트래픽 양과 관련해서, CPU 사용량은 크게 다릅니다.

요즘의 웹 어플리케이션은 다양한 유형의 외부 서비스 및 종속성을 활용합니다. SQL, NoSQL, 대기열, 캐싱 및 다양한 외부 HTTP 웹 서비스가 포함됩니다.

어플리케이션 종속송으로 인한 속도 저하로 인해 어플리케이션 성능문제가 발생할 수 있습니다. 

가장 일반적인 문제는 느린 SQL 쿼리문 또는 외부 HTTP 웹 서비스 입니다. 

https://stackify.com/w3wp-high-cpu-usage/

END