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

Question

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

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

(от MySQL Forge Wiki)

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

• Large result sets vs compression

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

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

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