Задержка в сети базы данных

Question

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

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

Карл

Answer 1

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

Что вы должны отслеживать, так это глобальную производительность ваших запросов (т. е. транспортировку в базу данных + выполнение + транспортировку обратно на ваш сервер).

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

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

Answer 2

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

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

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

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

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

Answer 3

На сервере под управлением 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 мс оказывала значительное влияние на производительность системы.

Answer 4

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