나는 이것에 대한 진정한 대답이 없다는 것을 알고 있기 때문에 사양에 구체적으로 들어 가지 않습니다. 그러나 나는 오늘 ab아파치 명령으로 부하 테스트를 해왔다 .
또한 4 개의 서로 다른 DB 테이블에서로드되고 데이터를 조작하는 페이지에서 초당 70 건의 요청 (100 명의 동시 사용자가있는 1000 건의 요청)이 발생했습니다. 따라서 상당히 무거운 페이지입니다.
서버는 현재 다른 용도로는 사용되지 않으며 개발 중이므로 서버에 대한 부담은 저에게 있습니다. 그러나 응용 프로그램은 많은 사용자가 매일 사용합니다.
그러나 이것으로 충분합니까? 또는 걱정해야합니까 (X 요청이 1 초 이상 지속되는 한)
걱정할 필요는 없지만 이것에 대한 몇 가지 팁을 원합니다.
답변:
초당 70 개의 요청이 시간당 252,000 페이지 렌더링의 시간당 비율로 작동합니다.
사이트의 평균 탐색 세션이 10 페이지라고 가정하면 시간당 25,000 개의 고유 항목을 지원할 수 있습니다.
이 수치는 예상 방문자 수와 비교하여 확인해야하며, 이는 비즈니스 측 직원에게 제공되어야합니다.
내가 작업하는 많은 사이트는 매일 대략 3 시간 정점에 일일 트래픽의 약 50 %를 확인합니다. 사이트의 경우 (제공하는 콘텐츠의 종류 및 대상에 따라 다름) 일일 약 150,000 회의 방문수를 지원할 수 있어야합니다.
이들은 꽤 좋은 숫자입니다. 난 당신이 괜찮을 것 같아요. 지금 opcode 캐싱 및 데이터베이스 튜닝을 검토하는 것이 현명하지만, 조기 최적화는 모든 악의 근원입니다. 사이트를 모니터링하고 핫스팟을 찾은 다음 트래픽이 커질 때까지 기다렸다가 고가의 문제에 대해 고가의 최적화 노력을 수행하십시오.
나는 과거에 아파치 서버 의 성능 을 관찰 하기 위해 2 가지 도구를 사용했습니다 .
하나는 munin으로 , 아파치 인스턴스 수, 연결 수, 사용 가능한 메모리, 프로세서 사용량 등을 포함하여 모든 종류의 것을 그래프로 표시하며, 위험 구역에 접근하는시기 와 이유를 결정하는 데 도움이됩니다 .
두 번째는 단순히 아파치 서버 상태 페이지 ( http : // your_server / server-status? refresh = 10 )로 각 연결의 상태와 주어진 시점에 사용 가능한 무료 연결 수를 볼 수 있습니다.
앱이 처음 출시 될 때 매우 바쁠 것이라고 생각하는 경우에만 걱정하는 것이 좋습니다. 문제의 페이지가 그렇게 세게 노출 될 가능성이 있습니까? 더 어려워? 적게? 당신이 모른다면, 나는 그것이 이전에 문제가되지 않았을 것이라고 생각합니다. 가장 느린 페이지 인 경우 나중에 시스템을 최적화해야하는지 한 곳을 알게됩니다.
또한 더 많은 성능을 발휘하기 위해 대부분의 웹 서버 및 데이터베이스 엔진을 조정하기 위해 수행 할 수있는 많은 작업이 있습니다.
귀하는 귀하의 서버가 빈 페이지에서 초당 2,900 건의 요청을 처리 할 수 있다고 설명합니다. 이는 웹 서버 자체가 아니라 처리 중이라는 것을 강력하게 나타냅니다.
PHP를 사용하는 경우 APC 와 같은 opcode 캐시 프로그램을 고려하십시오 . DB에 병목 현상이 발생하면 memcached 가 도움이 될 것입니다.
사이트를 게시 한 후에는 mod_top 1 을보고 Apache의 현재로드를 실시간으로 볼 수 있습니다. 나는 그것을 직접 설치하지는 않았지만 표준 Apache 서버 상태보다 더 많은 정보와 더 나은로드 분류가있는 것 같습니다.