Yvision.kzYvision.kz
kk
Разное
Разное
399 773 постов41 подписчиков
Всяко-разно
0
09:07, 16 августа 2010

mysql-proxy тестирование под мелкоскопом

mysql-proxy — практически идеальное решение для тех, кому нужен дешевый шардинг без переписывания приложений, а также хостинг провайдерам, которым сложно контролировать криворуких клиентов :) но хотелось бы вынести mysql или снизить нагрузку на СУБД без лишних контактов с клиентами.

Итак, есть задача, облегчить жизнь mysql серверу. Доступное решение — master-slave репликация. Всё замечательно, когда у нас есть программисты, которые могут переписать приложение на использование нескольких серверов СУБД, но как быть, если таковых нет? Тут на помощь нам приходит mysql-proxy. Работая прозрачно для клиента, mysql-proxy умеет проксировать запросы нескольких slave & master серверов.

далее будет описание тестов

Опущу в данном топике разворачивание master-slave репликации, документации море, рекомендую только пропускать ту, которая советует копировать файлы таблиц, опция --master-data в mysqldump давно уже присутствует.

Итак, была развернута master-slave репликация с одним мастером и тремя слейвами. Задача, проверить оверхед mysql-proxy и поддержку failover.

Для проверки, было использовано два скрипта, первый производил вставку 1000 строк в БД без использования индексов, второй производил чтение таблицы, кэш исключался, скрипт запускался несколько раз, брались средние значения.

Производилось несколько тестов.

Тест 1 — вставка в БД

а) напрямую в БД (результат берется за 100%) — 100%

б) через mysql-proxy (один мастер) — 69%

Тест 2 — выборка из БД

а) напрямую из БД (результат берется за 100%) — 100%

б) через mysql-proxy (только один слейв) — 75%

Тест 3 — выборка из БД

а) напрямую из БД (результат берется за 100%) — 100%

б) через mysql-proxy (три слейва) 70%

Тест 4 — выборка из БД

а) напрямую из БД (результат берется за 100%) — 100%

б) через mysql-proxy (два из трех слейвов были погашены для проверки failover) 8%

График:

Blog post image

Тестовые скрипты вызывались

ab -n 1000 -c 1 скрипт

и ab -n 1000 -c 10 скрипт

между вызовами была минутная пауза, отбрасывались крайние значения, среднее для коннекта без mysql-proxy бралось за 100%

Тест 1 проводился скриптом:

<?php

for ($i = 1; $i <= 1000; $i++) {

$link = new mysqli(«localhost», «login», «pass», «base»);

$link->query(«INSERT INTO test `SET`...»);

mysqli_close($link);

}

?>

перед его выполнением выполнялся truncate

Тесты 2 — 4

<?php

for ($i = 1; $i <= 1000; $i++) {

$link = new mysqli(«localhost», «login», «pass», «base»);

$q=$link->query(«SELECT * FROM `test`»);

while($r=$q->fetch_assoc()) {

print_r($r);

}

mysqli_close($link);

}

?>

Bыводы:

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

Конфиг mysql-proxy в тесте4

cat /etc/default/mysql-proxy

ENABLED=«true»

OPTIONS="

--proxy-address=localhost:3309

--proxy-read-only-backend-addresses=workserver1:3306

--proxy-read-only-backend-addresses=downserver1:3306

--proxy-read-only-backend-addresses=downserver2:3306

--proxy-backend-addresses=workserver1:3306

--proxy-skip-profiling

"

Ваши мысли?

0
246
1