olemskoi Jan 31 2013 at 19:32

Отдельный сервер для БД MySQL — как сэкономить трафик и ускорить приложение

1 min

17K

Слёрм corporate blogMySQL*

Comments 27

codrem Jan 31 2013 at 19:34

а где график загрузки CPU на этом же сервере после включения сжатия?

olemskoi Jan 31 2013 at 19:35

gyazo.southbridge.ru/i/7d21cc6816e487b449e7c2544591.png

adeep Jan 31 2013 at 20:37

Дальше бы посмотреть. У вас слева на графике видна высокая загрузка, включение сжатия ощутимо повысило нагрузку на процессор. Интересно посмотреть на результат сложения первого и второго.

olemskoi Jan 31 2013 at 21:08

Завтра скину графики, можно будет сравнить за сутки.

wisd Feb 1 2013 at 07:27

Вы хотите сложить огурцы с помидорами?
Для такой оценки нужно придумать веса параметрам, например 2*огурцы+3*помидоры.
Веса исходят из текущей ситуации…

adeep Feb 1 2013 at 12:45

Поясняю: на графиках нагрузки процессора есть большой всплеск слева. При этом он коррелирует с нагрузкой на сетевой интерфейс, но отличается по нагрузке от дневной части графика.
Сжатие сетевого обмена увеличило нагрузку на процессор, в дневной части графика все хорошо. Но был ли смысл увеличивать нагрузку на процессор для варианта нагрузки аналогичного времени слева по графику?

olemskoi Feb 1 2013 at 12:55

Слева по графику была несколько иная нагрузка — в тот момент на этом же сервере работало приложение.

А сжатие применили, когда поняли, в кратковременные пики не хватает канала.

olemskoi Feb 1 2013 at 18:27

Как и обещал, даю ссылки на свежие графики:
gyazo.southbridge.ru/i/b3b019f3ee6187eeff0d597c6707.png
gyazo.southbridge.ru/i/9fb3a74d11a2e85ae8bd1f7e93c7.png

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

Sicness Jan 31 2013 at 20:49

Включили бы в топик этот график.

olemskoi Jan 31 2013 at 22:34

Спасибо, включил.

olemskoi Jan 31 2013 at 19:35

Нагрузка вполне терпимая — стоит того.

lair Jan 31 2013 at 22:01

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

Вы статью, на которую ссылку даете, читали?

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

olemskoi Jan 31 2013 at 22:06

Тонкий линк — понятие весьма относительное. В моем случае «тонкий линк» — это 100 Mbit/s, из-за которых в течение дня несколько раз возникала кратковременная недоступность приложения.

Стоит так же взять во внимание тарифы хостеров. К примеру, в Hetnzer не всегда удобно покупать локальную сеть между серверами, а если гнать много трафика по гигабитному каналу, получаются большие счета.

lair Jan 31 2013 at 22:07

В моем случае «тонкий линк» — это 100 Mbit/s, из-за которых в течение дня несколько раз возникала кратковременная недоступность приложения.

Какие объемы вы передаете, и зачем?

Стоит так же взять во внимание тарифы хостеров. К примеру, в Hetnzer не всегда удобно покупать локальную сеть между серверами, а если гнать много трафика по гигабитному каналу, получаются большие счета.

Вот и выясняется, что дело не в производительности, а в деньгах. Что совсем другое.

-2

olemskoi Jan 31 2013 at 22:18

Вот и выясняется, что дело не в производительности, а в деньгах. Что совсем другое.

Вы считаете, что нужно увеличивать пропускную способность и это будет способствовать лучшей производительности? А когда канала станет мало, выстраивать серверы рядом друг с другом, обматывать локалкой, делать bonding?

Какие объемы вы передаете, и зачем?

Сайт на Wordpress (достаточно большая посещаемость), включено всевозможное кэширование. В код не лезем, это нам неподвластно.

lair Jan 31 2013 at 22:20

Вы считаете, что нужно увеличивать пропускную способность и это будет способствовать лучшей производительности?

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

В код не лезем, это нам неподвластно.

Эгм, а как же тогда планируете компрессию включить?

olemskoi Jan 31 2013 at 22:34

Согласитесь, повлиять на включение одного флага в функции mysql_connect (если говорить о php) значительно проще, чем провести аудит кода и выполнить доработки (порой значительные).

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

lair Jan 31 2013 at 22:36

Нет, не соглашусь. Либо вы вмешиваетесь в код, либо нет. А простое включение флага в mysql_connect (а я еще и не удивлюсь, если это происходит в одном месте на весь код, из соображений какого-нибудь DRY) может привести к произвольным последствиям.

Ну нельзя, нельзя такие вещи делать без подробного бенчмаркинга.

-1

olemskoi Feb 1 2013 at 18:24

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