프로젝트에 너무 많은 페이지가 있으면 IIS가 시작되고, 처음 열 때 웹사이트가 매우 느려집니다. 이는 프로젝트가 출시 시점에 사전 컴파일되지 않고, 사용자가 웹페이지를 방문할 때 동적으로 컴파일되기 때문입니다. 기존 사이트의 성능을 개선하고 오류 검사를 수행하고 싶다면, 프로젝트를 게시할 때 "릴리스 중 프리컴파일"을 선택해야 합니다.
소개
작은 프로젝트의 경우, 기본 설정에 따른 게시는 기본적으로 정상 동작을 충족할 수 있습니다. 첫 페이지는 서버 구성에 따라 56초 만에 열리고, 다른 페이지의 첫 번째 열음은 기본적으로 12초 만에 완료되며, 첫 순간 열림은 아닙니다.
프로젝트 기능이 복잡해지고 파일 수가 증가하면, 출판 후 첫 번째 페이지 열기에는 30초 이상이 걸리며, 다른 페이지의 첫 번째 열 시간에는 약 10초가 걸리며, 첫 번째 즉각적인 열음은 아닙니다.
이는 프로젝트가 출시 시점에 사전 컴파일되지 않고, 사용자가 웹페이지에 접속할 때 동적으로 컴파일되기 때문이며, 애플리케이션 풀이 재활용되거나 프로젝트 파일이 변경되면 다시 컴파일되어 다시 느린 '첫 번째' 과정을 거치기 때문에 참을 수 없습니다.
사전 컴파일의 장점
- 공연. 컴파일된 코드는 ECMAScript나 VBScript와 같은 스크립팅 언어보다 훨씬 빠르게 실행되는데, 이는 기계어에 더 가까운 표현이며 추가 분석이 필요 없기 때문입니다.
- 보안요원. 컴파일된 코드는 고수준 언어가 가진 가독성과 추상화가 부족하기 때문에 컴파일되지 않은 소스 코드보다 역설계가 더 어렵습니다. 또한, 퍼징 도구는 컴파일된 코드가 역설계 처리에 저항하는 능력을 향상시킵니다.
- 안정성. 컴파일 시 코드의 문법 오류, 타입 안전 문제 등 다른 문제를 점검하세요. 빌드 시점에 이러한 오류를 포착함으로써 코드에서 많은 오류를 제거할 수 있습니다.
- 상호운용성. MSIL 코드는 모든 .NET 언어를 지원하기 때문에, 원래 다른 언어로 작성된 어셈블리를 코드에 사용할 수 있습니다. 예를 들어, C#ASP.NET 웹 페이지를 작성할 때는 Visual Basic으로 작성된 .dll 파일에 대한 참조를 추가할 수 있습니다.
ASP.NET 코어 사전 컴파일
사전 컴파일
사전 컴파일은 ASP .Net Core의 기본 방식입니다. 게시 시점에는 시스템 내 모든 Razor 뷰가 기본적으로 사전 컴파일되어 있습니다. 컴파일된 뷰 DLL은 일관되게 xxx.PrecompiledViews.dll 또는 xxx.Views.dll로 명명됩니다
동적 컴필레이션
전체 프로젝트를 동적 컴파일로 쉽게 설정할 수 있으며, 값이 false인 MvcRazorCompileOnPublish라는 구성 프로젝트를 추가하면 됩니다
ASP.NET 웹사이트 사전 컴파일
우리는 Visual Studio를 사용하여 웹사이트를 다음과 같은 방식으로 게시합니다:
"이 사전 컴파일된 사이트에 대한 업데이트 허용" 옵션의 의미 .Net 웹 프로젝트를 게시할 때, 일반적으로 모든 . CS 파일은 자동으로 DLL 동적 링크 라이브러리를 생성하여 웹사이트의 소스 코드를 매우 잘 보호할 수 있습니다. 서버 측 코드는 일반적으로 에 위치하기 때문입니다. CS 파일 내 DLL 파일은 모두 생성된 후 서버에 업로드되기 때문에, 다른 사람들이 쉽게 열기 어렵습니다!
하지만 ashx, aspx 등 다른 파일들은 그 안에 있는 것이 그대로 존재하며, 다른 사람들은 이 파일들을 열어 볼 수 있지만, 다른 사람들은 CS 코드를 볼 수 없지만 ASPX 파일 내 HTML 코드나 서버 제어 및 관련 속성은 볼 수 있습니다; ashx와 같은 파일은 CS 파일과 동등하며, 그 안의 코드는 쉽게 볼 수 있습니다;
따라서, . CS 파일은 안전하지만, ASPX, ashx 및 기타 파일은 안전하지 않습니다; 그럼, 서버에 업로드된 웹 파일을 안전하게 만들 수 있는 방법이 있을까요? 한 가지 방법이 있는데, 바로 게시 시 "이 사전 컴파일된 사이트에 대한 업데이트 허용"을 체크하지 않는 것입니다;
이 사전 편집된 사이트에 업데이트를 허용하기 확인
웹을 게시할 때 "이 사전 컴파일된 사이트를 업데이트할 수 있도록 허용"을 체크하면 결과는 다음과 같습니다: CDL 파일로 컴파일된 모든 CS 파일, 기타 파일, 그리고 원본 파일을 제외한 전체 웹사이트 파일 전체에는 변경 사항이 없고, 다른 사람들이 메모장으로 열기만 하면 코드나 HTML 코드 등이 한눈에 볼 수 있습니다.
또한, 사용자가 특정 페이지를 처음 방문할 때 버그를 찾기 위해 컴파일되어야 하며, 오류가 없으면 정상적으로 접근할 수 있어 속도가 상대적으로 느려집니다. 그 이후의 방문은 정상입니다;
"이 사전 컴파일된 사이트에 업데이트를 허용하기" 체크를 해제합니다
웹을 게시할 때 "이 사전 컴파일된 사이트를 업데이트할 수 있도록 허용"을 체크하지 않으면, 결과는 다음과 같습니다: 1. 웹사이트 내 모든 CS 파일은 DLL 파일로 컴파일됩니다; 2. cs 파일 외에도 ASPX, ASHX 등 다른 파일들도 함께 컴파일되며, 각 파일은 BIN 디렉터리에 대응하는 *.compiled 파일을 생성합니다;
그 후 메모장에서 ASPX, ASHX 및 기타 파일을 보면 코드 자체가 보이지 않고, HTML 코드 마크업도 보이지 않습니다. 그런 파일을 열면 텍스트가 한 줄뿐이며, 내용은 "이것은 사전 컴파일된 도구로 생성된 마크업 파일입니다. 삭제해서는 안 됩니다!"라고 적혀 있고, 파일 크기는 1kb입니다;
웹사이트 페이지를 열어보면, 프로젝트 시작 후 첫 페이지(여전히 1~2초 정도 걸리지만, EF 없음)를 제외하고는 다른 페이지가 즉시 열립니다(EF의 첫 느림은 이 글의 범위를 벗어납니다). 이거 보니 미리 컴파일된 걸 늦게 본 것 같아요!
여기서 몰래 말하는데, 뷰 디렉터리를 삭제해도 웹페이지가 정상적으로 열리는 데 영향이 없다는 거야~ 왜 삭제하지 않느냐고, 우리는 감히 묻지도 못하고 삭제도 못 한다.
목표는 달성되었고, 빈 디렉터리의 혼잡함 같은 후속 문제도 해결해야 했습니다.
"병합하지 않음"을 선택하세요. 각 페이지와 컨트롤별로 별도의 어셈블리를 생성하면, 그 결과 빈에 훨씬 더 많은 App_Web_*.dll 파일이 생깁니다.
출시 시점에 프로젝트 루트는 PrecompiledApp.config 파일을 생성합니다. 내용은 다음과 같습니다:
PrecompiledApp.config 파일은 애플리케이션이 어떻게 배포되었는지, 그리고 요청 시점에 파일을 컴파일해야 하는지 추적 ASP.NET 사용됩니다. |
2020-8-22 10:05:17에 게시됨
|
|
|
|
