Причины задержки Redis в облаке (по сравнению с локальным redis на MacBook Pro) - PullRequest
Новая
       70

Причины задержки Redis в облаке (по сравнению с локальным redis на MacBook Pro)

0 голосов
/ 31 декабря 2018

Redis может дать время отклика менее миллисекунды.Это большое обещание.Я тестирую heroku redis и получаю 1ms примерно до 8ms, за zincrby.Я использую microtime() в php, чтобы обернуть вызов.Это повторение heroku (я использую бесплатный план) является общим экземпляром, и существует конфликт ресурсов, поэтому я ожидаю, что время отклика для идентичных запросов будет разным, и они, безусловно, меняются.

Мне любопытно, что касаетсяпричина различий в производительности по сравнению с Redis, установленным на моем MacBook Pro с помощью homebrew.Там явно нет задержки в сети.Что меня интересует, так это то, означает ли это, что любое повторное облачное хранилище (т. Е. Подключение по сети, скажем, в пределах aws) всегда будет работать немного медленнее, чем если бы я имел один облачный сервер и запускал бы redis внутрина том же физическом компьютере, таким образом устраняя задержку в сети?

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

Некоторые цифры: мой местный MacBook Pro постоянно выдает 0.2ms для идентичного zincrby, который занимает от 1ms & 8ms для redis heroku.

Является ли задержка в сети причинойэтого?

1 Ответ

0 голосов
/ 31 декабря 2018

Нет, возможно, нет.

Типичная задержка в сети 1 Гбит / с составляет около 200us.Это 0.2ms.

Более того, в aws вы, вероятно, на скорости не менее 10 Гбит / с.

Как и на этой странице в руководстве по redis, объясняется основная причинаизменение задержки между этими двумя средами почти наверняка будет результатом более высокого intrinsic latency (есть команда redis для проверки этого на любой конкретной системе: redis-cli --intrinsic-latency 100, см. страницу руководства выше) , возникающая из-за запуска вконтейнер linux .

т. Е. Задержка в сети не является основной причиной изменений, наблюдаемых здесь.

Вот контрольный список (со страницы руководства redis, связанной выше).

  • Если вы можете себе это позволить, предпочитайте физический компьютер виртуальной машине для размещения сервера.
  • Не подключайтесь к серверу систематически (особенно для веб-приложений).Сохраняйте ваши подключения как можно дольше.
  • Если ваш клиент находится на том же хосте, что и сервер, используйте доменные сокеты Unix.
  • Предпочитаете использовать агрегированные команды (MSET / MGET) иликоманды с переменными параметрами (если возможно) для конвейерной обработки.
  • Предпочитают использовать конвейеризацию (если возможно) для последовательности циклических переходов.
  • Redis поддерживает сценарии на стороне сервера Lua для покрытия случаев, которые не подходятдля необработанной конвейеризации (например, когда результат команды является входом для следующих команд).
...