데이터베이스 네트워크 대기 시간

Question

현재 N-Tier 시스템을 연구하고 일부 데이터베이스 성능 문제와 싸우고 있습니다. 우리가 조사한 영역 중 하나는 데이터베이스 서버와 응용 프로그램 서버 간의 대기 시간입니다. 우리의 테스트 환경에서 두 상자 사이의 평균 핑 시간은 0.2ms 영역에 있지만 클라이언트는 8.2ms 영역에서 더 많이 있습니다. 그게 우리가 걱정해야 할 일입니까?

평균 시스템에서는 공명 가능한 대기 시간을 어떻게 고려하고 대기 시간을 테스트/측정하는 방법은 무엇입니까?

칼

Answer 1

한마디로 : 아니요!

모니터링해야 할 것은 쿼리의 글로벌 성능입니다 (즉, DB + 실행 + 서버로 다시 전송하는 전송)

당신이 할 수있는 일은 성능 카운터를 사용하여 쿼리가 일반적으로 실행하는 데 걸리는 시간을 모니터링하는 것입니다. 당신은 아마도 당신의 결과가 밀리 초 영역에 있음을 알 수 있습니다.

"합리적인 대기 시간"과 같은 것은 없습니다. 오히려 "프로젝트의 합리적인 대기 시간"을 고려해야합니다. 이는 작업중 인 작업에 따라 다릅니다. 사람들은 실시간 거래 플랫폼과 읽기 전용 아마추어 웹 사이트에 대한 기대치가 동일하지 않습니다.

Answer 2

매우시기 적절한 응답에 대해 죄송하지만 다른 네트워크 대기 시간이 앱 서버와 DB 서버간에 어떤 네트워크 대기 시간을 달성했는지에 대한 메트릭을 찾을 때이 질문을 우연히 발견했습니다. 어쨌든, 나는 다른 대답을 알았습니다

어쨌든, 요약하면 : 네, 네트워크 대기 시간 (Ping으로 측정)은 큰 차이를 만들 수 있습니다.

데이터베이스 응답이 .001ms 인 경우 0.2ms에서 8ms 핑으로 이동하는 데 큰 영향을 미칩니다. 데이터베이스 프로토콜이 수다 스럽다고 들었습니다. 사실이라면 느린 네트워크 대기 시간 대 HTTP에 의해 더 많은 영향을 받는다는 것을 의미합니다.

그리고 아마도 1 쿼리를 실행하는 경우 8ms를 추가하여 DB에서 답장을받는 것은 중요하지 않습니다. 그러나 일반적으로 잘못된 코드 또는 최적화되지 않은 ORM 사용으로 발생하는 10,000 쿼리를 수행하는 경우 8ms 핑에 대해 80 초를 기다릴 수 있습니다.

나 자신에 대한 정책의 문제로, 나는 클라이언트 애플리케이션이 데이터베이스에 직접 연락하지 않도록합니다. 클라이언트 애플리케이션은 항상 응용 프로그램 서버 (예 : REST 웹 서비스)를 통과해야합니다. 그렇게하면 실수로 "1+n"ORM 문제가 있다면 거의 영향력이 없습니다. 나는 여전히 근본적인 문제를 해결하려고 노력할 것입니다 ...

Answer 3

Linux 기반 서버에서는 TC 명령을 사용하여 대기 시간의 효과를 직접 테스트 할 수 있습니다.

예를 들어이 명령은 ETH0을 통해 진행되는 모든 패킷에 10ms 지연을 추가합니다.

tc qdisc add dev eth0 root netem delay 10ms

이 명령을 사용하여 지연을 제거하십시오

tc qdisc del dev eth0 root

자세한 내용은 여기에서 제공됩니다.http://devresources.linux-foundation.org/shemminger/netem/example.html

모든 응용 프로그램은 다르지만 10ms 대기 시간이 시스템 성능에 큰 영향을 미치는 상황을 확실히 보았습니다.

Answer 4

Answers.com의 Head Honchos 중 하나는 연구에 따르면 웹 페이지로드에 대한 400ms 대기 시간은 사람들이 처음 페이지로드를 취소하고 다른 곳으로 가기 시작하는 시간입니다. 저의 조언은 원래 클라이언트 요청에서 이행에 이르기까지 전체 프로세스를 살펴 보는 것입니다. 더 잘하고 있다면 더 이상 최적화 할 필요가 없습니다. 8.2ms 대 0.2ms는 수학적 의미에서 기하 급수적으로 더 크지 만 인간의 의미에서 아무도 8.0ms 차이를 인식 할 수 없습니다. 그들이 경주에서 사진을 마무리하는 이유입니다.)