Я узнал, что MySQL может сжимать связь между серверами и клиентами.
Сжатие используется, если оба клиента и поддержка сервера zlib, и клиент запрашивает сжатие.
(из MySQL Forge Wiki)
Наиболее очевидные плюсы и минусы
Итак, это сжатый протокол, который я должен включить, когда я могу позволить себе серверы с адекватными характеристиками? Есть ли другие факторы, которые я должен рассмотреть?
Преимущества производительности будут в значительной степени зависеть от размера отправляемых вами результирующих наборов в дополнение к пропускной способности сети и задержке между сервером базы данных и его клиентами.
Чем больше наборов результатов, тем больше латентность или меньшая пропускная способность, тем более вероятно, что вы увидите преимущество сжатия.
Ваш максимальный уровень обслуживания ограничен наименьшим узким местом. Итак, вам нужно проанализировать, где вы сейчас находитесь в отношении ресурсов сети и ЦП.
Самый оптимизированный сервер базы данных использует 100% своего процессора в 100% случаев, иначе вы тратите впустую вычислительные ресурсы, имея процессор, который сидит там, ничего не делая. Конечно, вы не хотите, чтобы он составлял 101%, поэтому ваш целевой диапазон значительно ниже 100%. Тем не менее, я хочу сказать, что если у вас есть большой запас, прежде чем вы достигнете узкого места процессора, а результирующие наборы будут значительного размера, а сеть будет фактором, а затем включите сжатие. Циклы CPU дешевы, особенно неиспользованные (вы платите за электричество и охлаждение).
Если вы платите за пропускную способность, то использование торгового трафика для полосы пропускания легко оправдано, и даже если вы не приближаетесь к узким местам пропускной способности, тем быстрее скорость и более высокий уровень обслуживания стоит того.
Не забывайте, что клиент должен также расходовать процессорные циклы для распаковки данных. Не главная проблема, но все же фактор. В целом, сегодня процессоры работают быстрее, чем сегодня.
Я знаю это поздно, но я могу поделиться этим:
Оказывается, что 100-мегабитная связь (с временем разворота 1,4 мс) не является достаточно быстро... С сжатием общее время индексации сократилось до 87 с от 127 сек. Это почти 1,5-кратное улучшение общего времени работы. MySQL улучшение времени запроса еще больше. С другой стороны, 1 Gbit link был достаточно быстрым; и общее время работы было в 1,1 раза хуже с сжатия.
Если ваша база данных и клиент находятся на одном компьютере, на 100 Мбит сети и медленнее, включите сжатие!
Однако ваше окончательное решение может также зависеть от баланса между стоимостью циклов процессора (сжатие/распаковка) и использованием Bandwith (больше данных на проводе).
По моему опыту, большинство серверов mysql расположены на том же сервере, что и веб-сервер, поэтому пропускная способность сети не является проблемой.
Я бы сказал, что, если ваши db и приложения/веб-серверы не будут географически отделены друг от друга (то есть не на том же сервере или в сети), при включении сжатия будет очень мало пользы.
Из моего опыта это особенно полезно, если вы подключаетесь к внешнему серверу MySQL, который находится в совершенно другой сети (или даже стране). Преимущество, которое вы получаете от включения сжатия в таких случаях, зависит от размера передаваемых данных и расстояния между клиентом и сервером. Как всегда, вы должны протестировать свое приложение с сжатием и без него, а затем принять решение, наиболее выгодное для вашей ситуации. Нет абсолютного ответа на этот вопрос.
Я не вижу многого, что позволяет сжатие, если вы запрашиваете сервер MySQL на том же компьютере или даже в той же сети.