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