많은 양의 데이터 (예 : 큰 이미지)가있는이 새롭고 멋진 사이트가 있고 온라인으로 전환하려고한다고 가정하십시오. “너무 많은”홍보를하면 첫날에는 사이트에 요청이 압도 될 것입니다.
이 위험을 어떻게 완화 할 수 있습니까?
내가 생각한
- “개인”베타, 공개 베타, 공개
- X를 허용
사이세션을 동시에 수행하므로 연결된 사용자는 여전히 사이트에 대한 경험이 풍부하고 다른 사용자에게는 훌륭한 사과 메시지가 표시됩니다.
나는 할 수 없습니다 :
- 첫날 이후 더 많은 서버를 구입하면 사이트의 트래픽이 훨씬 적습니다. 🙂
답변
- 가능한 한 많이 캐시하십시오. 동적으로 작성된 모든 페이지는 사용자가 정적 버전을 얻을 수 있도록 캐시되어야합니다. db를 쿼리하는 페이지 구성 요소에서도 캐시되어야합니다.
- 이미지와 멀티미디어를 제공하기 위해 Amazon S3와 같은 외부 서비스를 사용해보십시오 (또는 사이트가 갑자기 많은 트래픽에 부딪히면 바로 사용할 수 있도록 준비하십시오).
Jeff와 Joel의 인기로 인해 SOF와 SF는 이미 광고와 수요가 이미 내장되어 있기 때문에 SOF와 SF에서 생방송을 진행할 수 있습니다. 거의 보장 된 사용자 기반이없는 것처럼 살면 점차 치명적일 수 있습니다.
비활성으로 인한 세션의 끝을 정의하기가 어렵 기 때문에 동시 세션에 의한 제한을 피할 수 있습니다. 사용자가 15 분 동안 떠나서 페이지를 다시로드하려고하면 오류 메시지 만 표시됩니다. 사용자를 잃어버린 것입니다.
답변
얼마나 많은 계획이 데이터 모델에 들어갔습니까? 값 비싼 정렬, 이진 열 또는 복잡한 조인없이 쿼리 볼륨을 증가시킬 수있는 스키마를 설계 했습니까? 데이터베이스 백엔드를 조정 했습니까 (있는 경우)?
‘큰 이미지’를 어떻게 제공하고 있습니까? 별도의 웹 서버 프로세스, 심지어 별도의 도메인으로 분리 할 수 있습니까?
시스템을로드 테스트 했습니까? ApacheBench 및 Siege와 같은 도구는 매우 유용합니다.
모든 구성이 svn입니까? 배포가 자동화 되었습니까? 우리의 응용 프로그램을 두 번째 서버로 롤아웃해야 할 때 기뻐할 것입니다.
답변
초대 시스템은 사이트의 사용자 유입을 제어하는 좋은 방법 일 수 있습니다. 사이트가 압도되지 않도록 처음에 특정 수의 초대를 전달하십시오. 그런 다음 각 사용자에게 다른 사용자에게 전달할 수있는 몇 가지 초대를 제공하여 사이트에 사용자 수를 천천히 쌓으십시오. 이렇게하면 처음에 사이트를 방문하는 사람이 너무 많아지지 않으며 트래픽이 많지 않습니다.
물론 단점은 처음에는 초대를받지 못한 사용자와 나중에 다시 돌아 오지 않을 수있는 많은 사용자를 거부 할 수 있다는 것입니다. 사람들이 사용하기에 매우 좋은 사이트가 아니라면 이것은 나쁜 행동 일 수 있습니다. 실제로 사이트에 따라 다릅니다. 또한 초대 시스템을 추가하려면 실제로 약간의 개발 시간이 필요합니다.
답변
시작하기 전에 강력한 모니터링 인프라가 있는지 확인하십시오. 결정을 내릴 수있는 데이터가 필요합니다. 즉, 서버 전체의 CPU로드를 측정하고로드가 박스 전체에 고르게 분산되어 있는지 확인하고 무언가가 녹 으면 어느 것이 어느 것인지 알 수 있습니다.
문제의 위치를 알면 응답 시간이 크게 줄어 듭니다. 화재가 발생한 후 나중에 설정 될 것이라는 의도로 어떤 종류의 모니터링 없이도 사이트가 너무 많이 시작되는 것을 보았습니다. 이것은 심각하게 잘못되었습니다.
답변
Amazon S3와 같은 정적 컨텐츠의 타사 호스팅을 살펴볼 수 있습니다. 애플리케이션에 따라 Amazon EC2를 사용하여 (버즈 워드를 싫어하는만큼) 클라우드하는 것도 가치가 있습니다.
답변
일부 호스팅 제공 업체를 사용하면 최대 용량의 개인 서버를 잠시 테스트 한 다음 평가판 기간 후에 합리적인 용량을 정할 수 있습니다.
DreamHost는 하나의 예입니다.
http://www.dreamhost.com/hosting-vps.html