Когда я должен использовать сжатый протокол MySQL?

Question

Я узнал, что MySQL может сжимать связь между серверами и клиентами.

Сжатие используется, если и клиент, и сервер поддерживает сжатие zlib, и клиент запрашивает сжатие.

(из MySQL Forge Wiki )

Наиболее очевидные плюсы и минусы

• плюсы: уменьшенный размер полезной нагрузки
• минусы: увеличено время вычислений

Итак, является ли сжатый протокол чем-то, что я должен включить, когда могу позволить себе серверы с адекватными характеристиками? Есть ли другие факторы, которые я должен учитывать?

Answer 1

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

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

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

Самый оптимизированный сервер баз данных использует 100% своего ЦП в 100% случаев, в противном случае вы тратите впустую вычислительные ресурсы из-за того, что находящийся там процессор ничего не делает. Конечно, вы не хотите, чтобы это было на уровне 101%, поэтому ваш целевой диапазон намного ниже 100%. Тем не менее, я хочу сказать, что если у вас есть большой запас мощности до того, как вы достигнете узкого места в ЦП, и результирующие наборы имеют значительный размер, а сеть является фактором, тогда включите сжатие. Циклы процессора дешевые, особенно неиспользуемые (вы платите за электричество и охлаждение).

Если вы платите за пропускную способность, использование ЦП для пропускной способности легко оправдывается, и даже если вы не приблизились к узкому месту в пропускной способности, эта более высокая скорость и более высокий уровень обслуживания чего-то стоят.

Не забывайте, что клиент также должен тратить циклы ЦП для распаковки данных. Не главная проблема, но все же фактор. В целом, современные процессоры работают быстрее, чем современные сети.

Answer 2

Я знаю, что уже поздно, но я могу поделиться этим:

• Большие наборы результатов против сжатия

Оказывается, что 100-мегабитный канал (с временем прохождения сигнала в 1,4 мс) равен , а не достаточно быстро ... При сжатии общее время индексации сокращено до 87 сек. от 127 сек Это почти в 1,5 раза больше общего времени выполнения. MySQL улучшение времени запроса еще больше. С другой стороны, 1-гигабитная ссылка был достаточно быстр; и общее время выполнения было в 1,2 раза хуже с сжатие.

Если ваша база данных и клиент не находятся на одном компьютере, в сети 100 Мбит и более, включите сжатие!

Однако ваше окончательное решение может также зависеть от баланса между стоимостью циклов ЦП (сжатие / распаковка) и использованием полосы пропускания (больше данных на проводе).

Answer 3

По моему опыту, большинство серверов mysql расположены на том же сервере, что и веб-сервер, поэтому пропускная способность сети не является проблемой.

Я бы сказал, что если ваши БД и серверы приложений / веб-сервера географически не разделены (т.е. не находятся на одном сервере или в сети), то включение сжатия будет очень незначительным.

Answer 4

По моему опыту, это особенно полезно, если вы подключаетесь к внешнему серверу MySQL, который находится в другой сети (или даже стране). Преимущество, которое вы получаете от включения сжатия в таких случаях, зависит от размера передаваемых данных и расстояния между клиентом и сервером. Как всегда, вы должны протестировать свое приложение со сжатием и без него, а затем принять решение, которое наиболее выгодно для вашей ситуации. На этот вопрос нет абсолютного ответа.

Я не вижу особого смысла включать сжатие, если вы запрашиваете сервер MySQL на той же машине или даже в той же сети.