ASP.Net 웹 사이트가 왜 느리게로드 될 수 있습니까? [닫은]

일화 적으로, 나는 각 페이지마다 상당한 시간이 걸리는 많은 .aspx 웹 사이트를 방문했다.

내 경험이 독특합니까?

그렇지 않은 경우 왜 ASP.Net 웹 사이트가 느리게로드 될 수 있습니까?

편집 : 이제 약 7 년 후입니다 (2017 년 12 월 29 일). 좋은 소식은 구글이 너무 느리게로드하는 사이트에 벌칙을 부과하기 시작했기 때문에 더 이상이 문제를 더 이상 보지 못한다는 것입니다. ASP.NET MVC를 현재 Vultr 개인 가상 서버에서 실행하고 있으며 ASP.NET MVC를 사용하고 있습니다. 사이트에서 발생하는 트래픽 양에 비해 너무 느리거나 사양이 낮은 하드웨어 -HK1

내가 생각할 수있는 다섯 가지 가능성 (일부 고급 캐싱 기술과는 별도로) :

• ASP.NET 용 웹 서버의 크기가 잘못 되었습니다 (예 : 클래식 ASP 용 서버 는 괜찮을 것이라고 생각했습니다 )

• <compilation debug="true"/>web.config에서 제거 하는 것을 잊어 버렸고 최적의 코드보다 적습니다 .

• 첫 방문을위한 JIT

• JIT 이전 및 추가로 컴파일해야하는 페이지에 포함 된 코드 (컴파일 된 코드 숨김과 반대)

• ASP.NET WebForms 용 ViewState 가 너무 커 집니다.

분명히 이것은 대답 할만한 가치가있을 것입니다.

여러 가지 요인이있을 수 있습니다. 이 순간을 사용하는 사이트는 .NET을 기반으로 구축되며 일반적으로 매우 빠릅니다 (다운 타임 / 유지 보수 기간 빼기).

귀하가 방문하는 해당 사이트의 개발자는 많은 양의 데이터를 제공하거나 연결 속도가 느리거나 서버 과부하 등을 초래할 수 있습니다. 또한 게임에 대한 인식이 될 수도 있습니다. 또한, 아마도 자바 스크립트가 작동하고 IE를 실행하고 있습니까? 아니면 플래시?

실제로 수행중인 작업을 모르는 경우 ASP.NET WebForms를 사용하면 http의 상태 비 저장 속성을 숨기는 한 폼에 컨트롤을 놓아 웹 응용 프로그램을 만들 수 있습니다. 작동하지만 이러한 종류의 개발은 효율적인 코드를 생성하지 않습니다. 특히 데이터 액세스 계층에 인덱스가없는 SQL Express 데이터베이스에서 모든 항목을 선택하는 생성 된 쿼리가 포함 된 경우에는 더욱 그렇습니다.

웹 응용 프로그램의 실제 작동 방식을 이해하는 사람들이 개발 한 빠른 asp.net 웹 사이트가 많이 있습니다. 여기에는이 사이트가 포함됩니다. ASP.NET MVC를 사용하여 개별 요청 처리를보다 강력하게 제어하고 .aspx 확장명을 표시하지 않습니다.

내가 똑같은 것을 보았을 때 여기에 추측하십시오. .asp 사이트 는 데이터 센터 또는 데이터 센터에서 호스팅되는 것이 아니라 회사 서버에서 자체 호스팅되는 경향 이 있습니다 (단어 경향이 있음 ). 따라서 종종 고속 웹 트래픽 용으로 설계되지 않은 하드웨어 및 연결에서 실행됩니다. 콜드 퓨전 기반 사이트도 이것으로 고통 받고 있습니다.

웹 사이트가로드되면 (application.start 이벤트) 모든 것을 메모리에로드하는 데 시간이 걸립니다. IIS 설정에 따라 약 20-30 분 동안 사용하지 않으면 언로드됩니다. 나는 GET10 분마다 서비스를하지 않고도 응용 프로그램을 지속적으로 실행하는 적절한 방법을 찾지 못했습니다 .

백엔드 / 데이터 계층이 잘못 설계되면 컴퓨터가 아무리 빠르게 실행 되더라도 느리게 실행될 수 있습니다. 프로파일 링은 문제가있는 위치를 식별하는 데 도움이됩니다.

당신은 이것을 확실히 상상하고 있습니다. :)

모든 소프트웨어에서 많은 요소가 작용합니다. 아키텍처, 코드 흐름의 중복성, 코드 품질 등. 목록을 시작하기에는 너무 많습니다.

ASP가 엔터프라이즈 수준의 사용에 적합하다는 증거를 원하십니까? 이 사이트 (및 모든 SE) 웹 사이트는 ASP.Net, 특히 MVC를 사용하여 만들어집니다.

이 사이트가 마지막으로 느린 시간은 언제입니까? 나는 1 년 넘게 이곳에와 왔고 방대한 사용자층에도 불구하고 한 번도 흥얼 거리는 것을 본 적이 없었습니다.

viewstate는 실제로 포스트 백을 느리게 할 수 있습니다. 페이지에 큰 드롭 다운 목록이있는 경우 해당보기 상태를 사용하지 않아야합니다.

viewstate를 사용하면 stateful winforms 앱에서 작업하는 것처럼 가장 할 수 있습니다. 때로는 문제가 생길 수 있습니다.

위의 모든 사항이 사실 일 수 있습니다. 내가 작업 한 ASP.NET 사이트의 성능에 영향을 미치는 가장 큰 단일 요인은 관련된 모든 것이 오래되었다는 것입니다. .NET 프레임 워크 버전, 서버, 데이터베이스 인프라 및 코드 자체는 모두 노화가 심했습니다.

많은 ASP.NET 사이트가 회사 사이트 인 경향이 있습니다. 그들은 일하는 경향이 있기 때문에 많은 사랑을 얻지 못합니다 . 사람들은 필요할 때까지 다시 쓰지 않습니다.

그 사용 ASP.NET은 엄청난 속도 향상을 가지고와 내가 일한 사이트 알고 단지 훨씬 더 효율적 JITing 및 제정신 캐싱 기본값을 가지고 프레임 워크의 최신 버전으로 이동합니다.

내가 본 또 다른 것은 많은 ASP.NET 사이트가 제대로 확장하는 방법을 모른다는 것입니다. 웹 가든에서 제대로 작동하도록 사이트를 디자인하는 것은 커뮤니티에서 일반적이거나 잘 문서화되어 있지 않기 때문에 적절한로드 밸런싱 설정이 없습니다. 처음부터 웹 가든을위한 사이트를 디자인하지 않으면 IIS에 기본 제공되는 확장 메커니즘을 사용할 수 없습니다. Windows NLB를 사용한 소프트웨어 부하 분산은 흔하지 않으며 관리하기가 복잡합니다. (이는 ASP.NET이 회사 소프트웨어 인 경향이 있으며이 구성 요소를 올바르게 구성하는 방법을 알고있는 IT 전문가가 아닌 사이트를 운영하는 회사가 관리하는 경향이 있습니다.)

F5를 사용한 하드웨어 부하 분산은 매우 비싸지 만 회사 네트워크 내에서 ASP.NET 사이트를 확장하는 가장 일반적이고 간단한 메커니즘 인 것 같습니다. 오픈 소스 사용자들 사이에서는 사용에 따라 자동으로 확장되는 무료로 제공되는 오픈 소스 도구를 사용하여 처음부터로드 밸런싱을 구축 할 것으로 기대합니다. 이것은 내가 본 것에서 ASP.NET 세계에서는 일반적이지 않습니다.