Задержка сети базы данных - PullRequest
3 голосов
/ 03 марта 2009

В настоящее время я работаю над n-уровневой системой и борюсь с некоторыми проблемами с производительностью базы данных. Одна область, которую мы исследовали, - это задержка между сервером базы данных и сервером приложений. В нашей тестовой среде среднее время пинга между двумя полями составляет около 0,2 мс, однако на клиентском сайте оно больше в районе 8,2 мс. В том, что Что-то, о чем мы должны беспокоиться?

Для вашей средней системы, что вы, ребята, считаете приемлемой задержкой и как бы вы провели тестирование / измерение задержки?

Karl

Ответы [ 4 ]

5 голосов
/ 03 марта 2009

Короче говоря: нет!

То, что вы должны отслеживать, - это глобальная производительность ваших запросов (т.е. передача в БД + выполнение + транспортировка обратно на ваш сервер)

Что вы можете сделать, это использовать счетчик производительности, чтобы отслеживать время, которое ваши запросы обычно занимают. Вы, вероятно, увидите, что ваши результаты превышают миллисекунду.

Нет такой вещи, как "Разумная задержка". Вы должны рассмотреть «разумную задержку для вашего проекта», которая сильно варьируется в зависимости от того, над чем вы работаете. Люди не имеют одинаковых ожиданий для торговой платформы в реальном времени и для любительского веб-сайта только для чтения.

4 голосов
/ 02 апреля 2013

Извините за очень несвоевременный ответ, но я наткнулся на этот вопрос, когда искал метрики того, какие задержки в сети достигают другие между своим сервером приложений и сервером БД. Во всяком случае, я заметил, что другие ответы

В любом случае, короче говоря: да, задержка сети (измеряемая ping) может иметь огромное значение.

Если ваш отклик базы данных равен 0,011 мс, вы увидите огромное влияние перехода от пинга 0,2 мс до 8 мс. Я слышал, что протоколы баз данных являются болтливыми, что, если истинно, означает, что они будут затронуты медленной задержкой сети по сравнению с http.

И более чем вероятно, если вы выполняете 1 запрос, то добавление 8 мс для получения ответа от базы данных не имеет значения. Но если вы делаете 10 000 запросов, что обычно происходит с плохим кодом или неоптимизированным использованием ORM, то вам придется ждать дополнительные 80 секунд для пинга 8 мс, тогда как для пинга 0,2 мс вы будете ждать только 4 секунды.

Для себя я никогда не позволяю клиентским приложениям напрямую связываться с базой данных. Я требую, чтобы клиентские приложения всегда проходили через сервер приложений (например, веб-сервис REST). Таким образом, если у меня случайно возникла проблема ORM "1 + N", то это не так эффективно. Я бы все равно попытался исправить основную проблему ...

3 голосов
/ 10 июня 2010

На сервере под управлением Linux вы можете самостоятельно проверить влияние задержки с помощью команды tc.

Например, эта команда добавит задержку 10 мс ко всем пакетам, проходящим через eth0

tc qdisc add dev eth0 root netem delay 10ms

используйте эту команду для удаления задержки

tc qdisc del dev eth0 root

Более подробная информация доступна здесь: http://devresources.linux -foundation.org / shemminger / netem / example.html

Все приложения будут отличаться, но я определенно видел ситуации, когда задержка в 10 мс оказала значительное влияние на производительность системы.

1 голос
/ 18 октября 2012

Один из руководителей Honchos на answers.com сказал, что согласно их исследованиям, 400 мс времени ожидания загрузки веб-страницы - это примерно то время, когда они впервые начинают заставлять людей отменять загрузку страницы и уходить куда-то еще. Мой совет - взглянуть на весь процесс, от первоначального запроса клиента до его выполнения, и если у вас все хорошо, нет необходимости в дальнейшей оптимизации. 8,2 мс против 0,2 мс экспоненциально больше в математическом смысле, но с человеческой точки зрения никто не может реально почувствовать разницу в 8,0 мс. Вот почему у них есть фото финиширует в гонках;)

...