ASP를 한 번 적어 주세요.NET MVC 성능 최적화(실제 프로젝트)

전언
개발 과정에서 프로젝트의 진도를 다그치기 위해 성능에 관심을 가지지 않았던 문제가 프로젝트가 점차 안정된 후에 성능이 좀 슬프다는 것을 발견하고 이 부분에 관심을 가지기 시작했다. 본 편은 개발 과정에서 겪은 문제를 기록하고 해결하기 위해 불쾌한 마음을 털어놓지 않았다.주의: 아래의 문제는 모두 모바일 단말기에 나타나기 때문에 사이트에서도 마찬가지로 나타날지 확인할 수 없습니다.
질문
요청 방식
프로젝트는 이동단에 속한다. 핸드폰에서 어떤 목록을 볼 때 아래로 미끄러질 때 자주 끊긴다. 굴러가는 플러그인은 iscroll을 사용한다. 물론 이 플러그인 문제가 아닌지 의심스럽지만 곧 이 문제를 배제했다. 다른 페이지에서는 이 문제가 나타나지 않았다. 나중에 스크립트에서 Ajax 요청 시간 초과를 30초로 설정했기 때문에인터페이스를 요청하는 데 시간이 걸릴 수도 있지 않을까요? 테스트를 하고 로그 파일을 보는 것도 이 문제가 아닙니다. 그래서 저는 쓴 스크립트 파일을 보기 시작했습니다. 깜짝 놀랐습니다. 데이터 목록을 요청할 때 요청 방식이 POST를 썼습니다. 이것은 동료의 소행입니다. 제가 GET로 바꾼 후에 이런 문제가 크게 개선되었습니다.동료에게 왜 GET를 사용하지 않는지 물었더니 GET 요청을 하는 데 문제가 생겼다고 말했다. 이때 나는 그가 가리키는 것이 무엇인지 알게 되었다. MVC에서 GET 요청을 해서 JSON 데이터를 얻을 때 다음과 같은 설정을 해야 한다.

 return Json("",JsonRequestBehavior.AllowGet);

건의:Ajax청구를 할 때 어떤 청구방식인지, 대응하는 방식으로 청구를 하세요. 그렇지 않으면 다른 청구방식을 주세요. 왜, 배불러서 버티고 있어요!
경로 문제
상기 요청 방식을 개선한 후에 문제가 어느 정도 개선되었다(평론에서도 이것이 빠른 문제를 초래하는 것이 아니라고 지적했다. 평론의 관점에 동의하고 다른 원인으로 인해 발생한 것이냐, 대응하는 요청이 대응하는 방식을 취해야 한다고 생각하는 것이냐) 그러나 문제가 존재한다. 우리는 계속 스크립트를 살펴보자.우리는 자주 이렇게 할 수 있다. 포맷 날짜 변환, 쿠키 가져오기 등 공용 스크립트에 봉인된 스크립트 방법이 필요할 것이다.다음은 우리가 시범을 보여 드리겠습니다.
스크립트에서 요청할 때는 일반적으로 다음과 같이 합니다.

        $(function () {
                type: 'get',
                url: "/home/Info",
                data: {},
                success: function () { },
                dataType: "application/json"
            });
        });

그러나 동료는 이렇게 해서 요청 경로를 공용 스크립트에 다음과 같이 썼다.

var path = "/"

이때 우리의 요구는 이렇게 변했다.

       $(function () {
            $.ajax({
                type: 'get',
                url: path + "home/Info",
                data: {},
                success: function () { },
                dataType: "json"
            });
        });

이렇게 쓰면 틀림없지만 사실은 우리가 첫 번째 방식으로 바뀌었을 때 효율이 바로 올라왔다. 두 번째 방식으로 썼을 때 시간이 오래 걸리고 방식이 다르지만 별 차이가 없는 것 같다. 그 이유는 나도 왜 동료처럼 쓰면 안 되는지 모르겠다.
건의: 요청을 할 때 상술한 것처럼 경로를 직접 쓰십시오. 때로는 당신이 보기에 방식이 같지만 다른 결과를 초래할 수도 있습니다.
이로써 휴대전화에서 미끄러질 때 끊기는 문제도 대체적으로 해결됐고, 스크립트에 문제가 있는 경우도 배제할 수 없다.
캐시 문제
페이지가 요청할 때 변경되지 않는 스크립트나 데이터를 위해 페이지의 불러오는 속도를 높이기 위해 우리는 보통 캐시를 사용합니다.
스크립트, 스타일 캐시
요청할 때 변경되지 않는 일부 스크립트는 요청할 때마다 다시 불러오는 것이 아니라 캐시를 해야 한다. 물론 이 때 스크립트를 어떻게 캐시하는지 생각해 낸 사람이 있다. 예를 들어 다음과 같다.

 <script src="~/Scripts/video.js?2016040901"></script>

스크립트 파일 뒤에 숫자를 더하면 ok입니다. 그렇습니다. 그렇습니다. 저희가 스크립트 파일을 수정한 다음에 뒤에 있는 숫자를 바꾸면 됩니다. 그런데 프로젝트에 스크립트 파일이 셀 수 없이 많고 대량의 스크립트 파일을 수정하면 페이지에 가서 대량의 변경을 해야 한다고 생각해 보셨나요? 피곤하지 않으세요?어차피 나 피곤해 죽겠어.내가 생각한 것은 일부 도입된 스크립트를 뒤에 숫자를 직접 붙이는 것은 틀림없이 문제가 없을 것이다. 왜냐하면 이런 스크립트는 우리가 거의 움직이지 않기 때문이다. 예를 들어 jquery 스크립트를 도입하는 경우(어떤 사람들은 빈틈을 파고들 수도 있고 수정할 수도 있다) 그래.그러면 우리는 통일적으로 승낙한다. 우리는 설정 파일에서 그 뒤의 숫자를 우리가 수정할 스크립트로 삼을 수 있다. 우리가 스크립트를 수정하면 설정 파일의 버전을 직접 바꾸면 된다. 이렇게 하면 관리하기 편하고 일로영일하니 기꺼이 하지 않을 수 없다.우리 다음에 한번 봅시다.
(1) 설정 파일에 수정된 스크립트 버전을 추가합니다. (물론 숫자를 마음대로 쓸 수 있습니다. 다음에 수정되면 스크립트의 숫자를 직접 바꾸면 됩니다.)

  <add key="version" value="2016040901"/>

(2) 이어서 HtmlHelper의 확장 방법을 다음과 같이 쓰겠습니다.

    public static class FileHtmlHelper
    {
        private static readonly string s_version = ConfigurationManager.AppSettings["version"].ToString();
        private static readonly string s_root = HttpRuntime.AppDomainAppPath.TrimEnd('\\');
        public static MvcHtmlString RefFileHtml(this HtmlHelper htmlHelper, string path)
        {

            string filePath = s_root + path.Replace("/", "\\");
            return new MvcHtmlString(string.Format("<script type=\"text/javascript\" src=\"{0}?{1}\"></script>\r
", path, s_version));
        }
    }

(3) MVC 보기 페이지에서 다음과 같은 스크립트를 호출합니다.

  @Html.RefFileHtml("/Scripts/video.js")

이렇게 하면 우리는 스크립트 캐시와 관리하기 편리한 문제를 해결할 수 있다.
권장: 스크립트 캐시를 진행하고 있습니다. 설정 파일을 통해 수정된 버전을 읽을 수 있도록 스크립트 파일의 캐시를 관리할 수 있습니다.스타일 캐시도 마찬가지다.
페이지 출력 캐시
MVC에서는 다음과 같이 Action 캐시를 사용할 수 있습니다.

        [OutputCache(Duration = 30)]
        public ActionResult Cache()
        {
            return View();
        }

캐시에 도달할 수 있는 파라미터가 있다면 어떻게 해야 합니까?전체 페이지에서 요청한 모든 매개 변수를 다음과 같이 캐시합니다.

        [OutputCache(Duration = 30,VaryByParam="*")]
        public ActionResult Cache()
        {
            return View();
        }

JsonResult에 대해서도 마찬가지입니다. 매개 변수를 통해 변하지 않는 목록을 선별할 때, 우리는 그것을 캐시할 수 있습니다. 이 때 우리의 명확한 매개 변수 유형은 바로 사용자 정의 캐시입니다.
구성 파일을 통해 다음과 같이 구성할 수 있습니다.

     <caching>
      <outputCacheSettings>
        <outputCacheProfiles>
          <add name="customProfile" duration="900" location="Server" varyByParam="UserId" />
        </outputCacheProfiles>
      </outputCacheSettings>
    </caching>

상술한 많은 매개 변수를 선택할 수 있습니다. 필요한 캐시 매개 변수를 선택하면 됩니다.
컨트롤러에 사용자 정의 캐시 이름만 추가하면 됩니다.

        [OutputCache(CacheProfile="customProfile"]
        public JsonResult Info()
        {
            return Json(new { result = "ok" }, JsonRequestBehavior.AllowGet);
        }

주의: 상기 캐싱 노드는 시스템에 있습니다.시스템이 아닌 웹 노드 아래.웹 서버 노드 아래.
구성 파일 수정 및 기타
(1) 필요하지 않은 http Modules를 다음과 같이 삭제합니다.

<httpModules>
    <remove name="Session"/>
    <remove name="RoleManager"/>
    <remove name="PassportAuthentication"/>
    <remove name="Profile"/>
    <remove name="ServiceModel"/>
</httpModules>

(2) 폼 검증을 이용하여 다음과 같은 httpModules를 삭제할 수 있다

<httpModules>
    <remove name="WindowsAuthentication"/>
    <remove name="FileAuthorization"/>
</httpModules>

(3) IIS에서 압축을 사용하면 응답 결과를 압축하여 네트워크 전송 시간을 줄일 수 있습니다.
애플 날짜 문제 주의
데이터가 데이터베이스에 저장되었을 때 안드로이드에 저장된 것이 성공했고 애플에 저장된 것이 실패했다. 이 문제는 오랫동안 고민을 했고 로그 파일을 보니 애플에서 날짜에 대한 특별한 포맷이 전달된 것이 발견되었다. 그렇지 않으면 비어 있었다. 그래서 js의 Replace 방법을 이용하여 교체했다.

 date.replace("-", "/");

이때 Replace 방법을 이용하여 첫 번째 횡선만 교체할 수 있음을 발견하였으며, 최종적으로 정규 표현식으로 모두 교체하여 해결하였다

 date.replace(/-/g, "/");

주의: 애플에서 날짜를 전달할 때는'2016/04/09'와 같아야 하며'2016-04-09'가 될 수 없습니다.
결어
부분 참조 출처: 코드를 수정하지 않고 ASP를 최적화할 수 있습니다.NET 웹 사이트의 성능에 대한 몇 가지 방법.
문제의 발생과 해결에 약간의 시간을 들인 결과 휴대전화에서 데이터를 요청하는 데 소모되는 시간이 크게 개선되었고 페이지의 마운트 속도가 많이 높아졌으며 슬라이딩 데이터가 원활해져 일단락되었다.어떤 사소한 문제들은 평소에 주의를 기울이지 않아서 여러 가지 방식이 모두 실현될 수 있을 것 같아서 이렇게 한 결과가 같은지, 실현된 결과가 같은지 모르겠다. 그러나 나타난 효과는 천양지차이다. 실제 개발에서 작은 세부 사항이 전체 프로젝트의 성패에 얼마나 중요한지 발견했다.
검토: 문장의 평론 관점에 대해 인정한다. 첫 번째는 청구 방식에 대해 다른 원인으로 인해 발생한 것이고, 두 번째는 협의에 대해 더욱 깊이 있게 이해하고 공부해야 한다. 평론 중의 멋진 대답에 감사하고 지식을 늘렸다. 여기에 감사를 표한다.