---
title: "mysql-proxy тестирование под мелкоскопом"
description: "mysql-proxy — практически идеальное решение для тех, кому нужен дешевый шардинг без переписывания пр..."
author: "Obolganliquida"
published: "2010-08-16T09:07:25+00:00"
modified: "2010-08-16T09:07:25+00:00"
locale: "ru"
canonical_url: "https://yvision.kz/post/mysql-proxy-testirovanie-pod-melkoskopom-65764"
markdown_url: "https://yvision.kz/post/mysql-proxy-testirovanie-pod-melkoskopom-65764/markdown"
site_name: "Yvision.kz"
---

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

> 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%

График:

![mysql-proxy тестирование под мелкоскопом](http://a0.1nsk.ru/3/0e2ab99bf7.png)

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

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

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

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

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

> query(«INSERT INTO test `SET`...»); mysqli_close($link); } ?>

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

Тесты 2 — 4

> 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

"

Ваши мысли?

---

Source: [https://yvision.kz/post/mysql-proxy-testirovanie-pod-melkoskopom-65764](https://yvision.kz/post/mysql-proxy-testirovanie-pod-melkoskopom-65764)