램 블러와 같은 사이트는 어떻게 동적 콘텐츠를 그렇게 빨리 제공합니까? Yahoo보다 더 빠릅니다 (내 국가 SE 아시아에 서버가 있지만 램 블러는 그렇지 않습니다).
이것이 순전히 Nginx의 기능입니까? 그러한 기능에 대해 어디에서 살펴보아야합니까?
Nginx에서 제공되는 serverfault.com이 IIS 7보다 훨씬 빠를 것이라고 믿습니다 (두 경우 모두 db 액세스 시간이 동일하다고 가정). 이것이 공정한 가정입니까?
편집하다:
IIS7 앞에서 Nginx를 사용하여 Karl에서 게시
답변:
nginx 내부에 대한 개요를 보려면 이 프레젠테이션을 볼 수 있습니다 . 주요 차이점은 Apache와 마찬가지로 스레드를 사용하는 대신 요청을 비동기 적으로 처리하는 것입니다. 이 문서 를 볼 수도 있습니다 .
램 블러와 같은 사이트는 어떻게 동적 콘텐츠를 그렇게 빨리 제공합니까? ... 이것은 순전히 Nginx의 기능입니까? 그러한 기능에 대해 어디에서 살펴보아야합니까?
이것은 nginx, IIS 및 Apache가 일반적으로 밀리 초 이내에 그들의 작업을 '충분히'빠릅니다. nginx는 Apache보다 훨씬 빠르지 만, 이는 단지 사이트 소유자가 웹 서비스 부분에 더 적은 수의 서버를 필요로한다는 것을 의미합니다. nginx는 데이터를 더 빨리 전송하지 않습니다.
덜 중요한 부분은 서버 측 속도 , 즉 HTML을 만드는 데 걸리는 시간입니다. 더 중요한 부분은 '프론트 엔드'성능 인데, 이는 HTML, CSS, 자바 스크립트 및 이미지, 개수, 크기 및 적절한 전달 (HTTP 압축, 캐싱)을 의미합니다.
물론 서버 쪽 속도는 여전히 중요합니다. 무시하거나 중요하지 않다는 말은 아닙니다. 그러나 일반적으로 최종 사용자 속도로 인식되는 가장 작은 부분입니다. 서버 측 작업은 종종 500 밀리 초 이내에 완료되지만 3,000 ~ 5,000 밀리 초가 지나기 전에는 페이지가 준비되지 않습니다. 이 시간의 대부분은 프론트 엔드 리소스 (CSS, Javascript, Images)를 다운로드하는 것입니다.
Steve Souders 는 Yahoo에서 원래 작업을 수행했으며 현재 Google에서 작업하고 있습니다. 그의 첫 번째 책인 "고성능 웹 사이트" 는 빠른 웹 사이트 제작에 대해 더 배우기위한 최고의 출발점입니다. 그의 비디오에 나오는 그의 책과 같은 자료 와 이러한 디자인 규칙을 찾을 수 있습니다 . 그러나 나는 그 책이 빨리 읽고 이해하기 쉽다는 것을 알게되었다.
WebPageTest.org의 테스터를 통해 사이트를 운영 할 수 있습니다. 웹 사이트 의 프론트 엔드 부분에 대해 좋은 느낌을주고 왜 더 빠르거나 느린 지 알 수 있습니다.
Nginx에서 제공되는 serverfault.com이 IIS 7보다 훨씬 빠를 것이라고 믿습니다 (두 경우 모두 db 액세스 시간이 동일하다고 가정). 이것이 공정한 가정입니까?
아니, 그건 오해입니다. :-)
Nginx는 다른 응용 프로그램 / 서버를로드 밸런싱하고 정적 서버를 전체 서버로 사용하는 것보다 더 자주 사용합니다.
예를 들어 많은 파이썬 프레임 워크 중 하나를 사용하여 앱을 작성하고 nginx를 여러 인스턴스에 대한 프론트 엔드로 사용할 수 있습니다 (아마도 여러 머신에 퍼져 있음). 이 경우 nginx 서버는 두 가지 목적으로 이미지 및 스타일 시트와 같은 정적 컨텐츠에 대한 요청을 직접 처리하며 (디자인으로 인해 매우 빠르게 수행됨) 알고있는 모든 인스턴스간에로드를 분산시키는 동적 요청을 애플리케이션에 전달합니다. . 이것은 Ruby on Rails 커뮤니티에서도 매우 인기있는 구성입니다.
Rambler가 로컬 Yahoo 서비스보다 더 빨리 나타날 수있는 다른 두 가지 이유가 있습니다. 첫째, 로컬 Yahoo PoP에는 더 많은 요청을 처리 할 수있는 충분한 리소스가 없을 수 있으므로 더 많은 하드웨어를 추가하면 (소프트웨어가 이런 식으로 잘 조정된다고 가정) 속도가 빨라질 것입니다. 추가 키트를 유지 관리하는 데 드는 비용이 들거나 Yahoo가이를 수행했을 것입니다. 다른 큰 차이점은 웹 서버가 아닌 백엔드에있을 수 있습니다. 두 서비스는 데이터베이스 구성이 매우 다르며, 그렇지 않은 경우에도 정확히 동일한 다양한 쿼리 (및 데이터베이스 아키텍처 전용 하드웨어도 중요한 영향을 미칩니다).
하나의 서비스가 다른 서비스보다 빠른 이유 (일반적으로 또는 특정 상황에서)를 분석하는 것은 일반적으로 하나의 간단한 답변을 얻지 못할 것입니다. 자체적 인 이점, 문제 및 타협점을 고려하더라도 각 사이트마다 이러한 차이를 모두 고려하더라도 사용자 기반의 역 동성이 다르고 설계자가 제어 할 수없는 네트워크 문제도 있습니다.
다음은 좋은 설명입니다. http://www.aosabook.org/en/nginx.html
내 경로를 통해 EU에서 이미 인스턴트 페이지로드이므로 serverfault를 훨씬 더 빨리 보는 데 어려움을 겪고 있습니다 (SO는 아마도 트래픽으로 인해로드 문제가 있습니까?). 대부분의 지역 뉴스 사이트보다 더 빠르고 반응이 빠릅니다.
로드 시간 및 대기 시간과 관련된 명백한 문제의 대부분은 실제 서버 성능이 아닌 서버와 최종 사용자 imo 사이에서 발생합니다 (다른 사람이 크기를 정하거나 무언가를 잘못 설계하지 않은 한). 다른 사이트는 다른 방법으로 라우팅 될 수 있으며, 나를위한 국가-로컬 사이트는 지구상의 어떤 것보다 대기 시간이 더 클 가능성이 큽니다. 모두 변수로 인해 서비스로 해결할 수 있다고 말할 수는 없습니다. 특정 용도 (r)에 대한 문제가 어디에 있는지 알지 않는 한 업그레이드 / 스위치
분명히 서버에서 다양한 종류의 캐싱은 큰 차이를 만들지 만 이러한 모든 사이트는 이미 알고있는 한 그렇게합니다.