프로덕션 웹 애플리케이션의 초당 "평균"요청은 얼마입니까?


120

나는 "빠른"것으로 간주되는 것에 대한 기준이 없습니다. 나는 항상 이것을 궁금해했지만 정답을 찾지 못했습니다 ...


9
정답은 없습니다. 빠름은 상대적인 용어이며 대답은 상황과 응용 프로그램에 따라 크게 달라집니다.
Dave L.

답변:


105

OpenStreetMap은 초당 10-20 인 것 같습니다

Wikipedia는 300 개의 서버에 분산 된 초당 30000에서 70000으로 보입니다 (시스템 당 초당 100에서 200 개의 요청, 대부분 캐시 임).

Geograph는 주당 7000 개의 이미지를 받고 있습니다 (95 초당 1 회 업로드).


6
와우,
Joseph Persie

8
@JosephPersie 게시 날짜를 보는 것을 잊지 마세요, hehe.
Spectral

여전히 200,000 / sec 미만으로 표시됩니다. 새 모니터링 페이지는 grafana.wikimedia.org입니다
OJW

흥미롭게도, 저는 초당 레코드와 초당 요청에 대한 웹 피스 스트리밍을로드 테스트했습니다. 초당 요청이 동일한 야구장 (100 ~ 200)에 있다고 생각하지만 스트리밍을 사용하면 초당 최대 1140 레코드를 촬영합니다 (ndjson 수행). 어쨌든 더 많은 숫자를 공유 할 것이라고 생각했습니다. (2 개의 마이크로 서비스를 통해 인 메모리 데이터베이스로 스트리밍 된 테스트에서 이것이 변경되는지 확실하지 않습니다 ... 여전히 라이브 DB로 테스트해야합니다. DB는 병목 현상이 될 수 있으며 nosql로 전환하지 않는 한 다시 다운 될 수 있습니다).
Dean Hiller

50

확실하지 사람이 여전히 관심이 있지만,이 정보는 트위터에 대해 게시했습니다 (그리고 너무 여기 )

통계

  • 350,000 명 이상의 사용자. 실제 숫자는 항상 그렇듯이 매우 슈퍼 극비입니다.
  • 초당 600 개의 요청.
  • 초당 평균 200-300 개의 연결. 초당 800 개의 연결로 급증합니다.
  • MySQL은 초당 2,400 개의 요청을 처리했습니다.
  • 180 Rails 인스턴스. Mongrel을 "웹"서버로 사용합니다.
  • MySQL 서버 1 개 (빅 8 코어 박스 1 개) 및 슬레이브 1 개. 슬레이브는 통계 및보고 용으로 읽기 전용입니다.
  • 이상한 작업을 처리하기위한 30 개 이상의 프로세스.
  • 8 Sun X4100s.
  • Rails에서 요청을 200 밀리 초 안에 처리합니다.
  • 데이터베이스에서 소요되는 평균 시간은 50-100 밀리 초입니다.
  • 16GB 이상의 memcached.

2
블로그 게시물이 다운되는 경우 소스에 한 걸음 더 가까워짐 : highscalability.com/blog/2009/6/27/…
Chinoto Vokro

@ChinotoVokro 답변에 대한 링크도 추가했습니다. 감사!
Peter K.

1
@user :-D 예, 지금은 꽤 역사적입니다. 하지만 당시 나에게는 유용한 답변이었습니다! :-)
Peter K.

13

웹 호스트의 제어판으로 이동하여 phpMyAdmin을 열고 "MySQL 런타임 정보 표시"를 클릭하면 다음과 같은 결과가 나타납니다.

이 MySQL 서버는 53 일, 15 시간, 28 분 53 초 동안 실행되었습니다. 2008 년 10 월 24 일 오전 4시 3 분에 시작되었습니다.

쿼리 통계 : 시작 이후 3,444,378,344 개의 쿼리가 서버로 전송되었습니다.


시간당
3,444M 분당 2.68M
초당 44.59k 743.13

이는 지난 53 일 동안 1 초마다 평균 743 개의 mySQL 쿼리입니다!

나는 당신에 대해 모르지만 나에게 그것은 빠르다! 아주 빨리 !!


확실하지 않다. 그 당시 나는 IXWebhosting에 있었고 그들은 공유 서버에 Windows 32 비트 운영 체제를 사용하고있었습니다. 나는 그들의 mySQL 데이터베이스 서버가 별도의 전용 머신이라고 생각하지만 확실하지 않습니다.
lkessler

3
내가 잘못 될 수도 있지만 - 나는 그 숫자는 단지 인스턴스 특정 MySQL 서버에 대한 모든 안타의 집합체이며, 아니 셨을 텐데요
워렌

@Warren : 예, 전체 서버라고 가정했습니다. 그러나 처리 측면에서 하나의 SQL 쿼리에 무엇이 포함되는지 아는 것은 매초마다 처리하는 것이 매우 인상적이며 이는 최대 부하가 아니라 평균 일뿐입니다.
lkessler

11

개인적으로 저는 매번 수행되는 분석을 모두 좋아합니다 .... 요청 / 초 및 평균 시간 / 요청과 최대 요청 시간을 보는 것을 좋아합니다. 초당 61 개의 요청이 있으면 쉽게 뒤집을 수 있으며 1000ms / 61 개의 요청으로 뒤집을 수 있습니다.

귀하의 질문에 답하기 위해 우리는 대규모 부하 테스트를 수행했으며 우리가 사용하는 다양한 아마존 하드웨어 ($$ / 이벤트 / 초로 떨어졌을 때 32 비트 중간 CPU)와 요청 / 초 범위에서 범위를 찾았습니다. 29 개 요청 / 초 / 노드에서 최대 150 개 요청 / 초 / 노드 범위입니다.

물론 더 나은 하드웨어를 제공하면 더 나은 결과를 얻을 수 있지만 최상의 ROI는 아닙니다. 어쨌든,이 게시물은 내가 야구장에서 내 번호가 어디에 있는지 확인하고 다른 사람이 찾고있는 경우 내 번호를 공유했는지 확인하기 위해 몇 가지 유사점을 찾고 있었기 때문에 훌륭했습니다. 내 것은 순전히 내가 갈 수있는만큼 높은 곳입니다.

참고 : 요청 / 초 분석 (ms / request가 아님) 덕분에 Linux (우리는 C 및 Java에서 서버를 테스트 함)가 너무 많은 부하를받을 때 소켓 라이브러리에 대한 모든 호출을 동결하는 문제를 해결하려는 주요 Linux 문제를 발견했습니다. 매우 이상해 보입니다. 전체 게시물은 실제로 여기에서 찾을 수 있습니다 .... http://ubuntuforums.org/showthread.php?p=11202389

이 문제가 해결되면 테스트가 2 분 42 초에서 1 분 35 초로 진행되어 33 %의 성능 향상을 볼 수 있다는 점에서 엄청난 성능 향상을 제공하므로이를 해결하기 위해 노력하고 있습니다 .... DoS 공격이 더 나쁠수록 이러한 일시 중지 시간이 길어 모든 CPU가 0으로 떨어지고 처리가 중지됩니다. 내 생각에 서버 처리는 DoS에 직면하여 계속되어야하지만 어떤 이유로 든 때때로 중단됩니다. Dos 동안 때때로 최대 30 초 !!!

추가 : 실제로 jdk 경합 상태 버그라는 것을 알았습니다 .... 큰 클러스터에서 분리하기가 어려웠지만 1 개의 서버 1 데이터 노드를 실행했지만 그중 10 개를 실행했을 때 매번 재현 할 수 있었고 서버 만 살펴 보았습니다. / datanode에서 발생했습니다. jdk를 이전 릴리스로 전환하면 문제가 해결되었습니다. 우리는 jdk1.6.0_26에있었습니다.


4

그것은 매우 열린 사과 대 오렌지 유형의 질문입니다.

1. 프로덕션 애플리케이션의 평균 요청로드 2. 빠른 것으로 간주되는 것

이것들은 반드시 관련이 없습니다.

초당 평균 요청 수는 다음에 의해 결정됩니다.

ㅏ. 동시 사용자 수

비. 초당 평균 페이지 요청 수

씨. 추가 요청 수 (예 : ajax 호출 등)

빠르다고 생각되는 것이 무엇인지에 관해서는 .. 사이트가 취할 수있는 요청이 얼마나 적다는 의미입니까? 아니면 하드웨어가 xyz 초당 요청 수를 처리 할 수 ​​있다면 빠른 것으로 간주된다면?


1

적중률 그래프는 '피크 시간'이 사용자가 잠자는 동안 얻는 속도의 2 배 또는 3 배인 정현파 패턴입니다. (일일 일괄 처리 작업이 서버에서 발생하도록 예약 할 때 유용 할 수 있습니다.)

위키 백과와 같은 '국제'(다국어, 현지화 된) 사이트에서도 효과를 볼 수 있습니다.


1

일반적으로 사용자 당 2 초 미만-즉 시스템이 느리다고 생각하는 것보다 느린 응답을 보는 사용자.

이제 연결 한 사용자 수를 알려줍니다.


1

당신의 그래프의 "Slashdot의 효과 분석"를 검색 할 수 있습니다 당신이 보는 것이 무엇 예를 들어 사이트의 일부 측면이 갑자기 뉴스에 인기가있는 경우, 위키에이 그래프를 .

살아남는 웹 애플리케이션은 처리 언어를 통해 모든 요청을 보내는 대신 정적 페이지를 생성 할 수있는 경향이 있습니다.

단일 서버 이상으로 웹 사이트를 확장하는 방법에 대한 아이디어가 포함 된 훌륭한 비디오 (ted.com에 올 것 같은데요? 플리커 웹 팀이 만든 것 같아요? 링크를 아십니까?) 다양한 유형의 사용자에게 최상의 효과를 얻기 위해 읽기 전용 및 읽기-쓰기 서버의 혼합 사이에 연결을 할당합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.