ScaleArc недавно наняла Percona для проведения различных тестов своего продукта для управления трафиком баз данных. Этот пост является результатом тестов, проведенных Uday Sawant (ScaleArc) и мной. Вы также можете скачать отчет непосредственно в формате PDF здесь .
Цель этих тестов — определить потенциальные издержки самого программного обеспечения ScaleArc и потенциальные преимущества кэширования. Тесты проводились с использованием транковой версии sysbench. По этой причине мы использовали очень маленький набор данных, поэтому измерения будут быстрыми, и известно, что кэширование имеет огромные преимущества, когда сами запросы довольно дороги. Мы решили, что лучше показать это преимущество с помощью реального приложения, которое появится позже в этой серии. И если вы находитесь в районе Силиконовой долины, не забудьте присоединиться к нам сегодня вечером в первый в истории День признания с открытым исходным кодом — я был бы рад обсудить выводы, представленные здесь, в этом посте. Вход свободный, но из-за ограниченного пространства вы должны зарегистрироваться сейчас, Я также буду доступен на конференции и выставке Percona Live MySQL всю эту неделю.
На этом итоговом графике видно, что с точки зрения пропускной способности (эталон только для чтения, который важен для приложений, предназначенных для чтения), ScaleArc не имеет значительных накладных расходов, в то время как кэширование может иметь потенциально огромные преимущества.
Ситуация очень похожа со временем отклика. ScaleArc не добавляет значительных накладных расходов, а кэширование также может принести огромную пользу с точки зрения времени отклика.
В случае этой конкретной рабочей нагрузки (которая предназначена только для чтения sysbench), использование кэширования означает увеличение производительности примерно в 3 раза и сокращение времени отклика примерно на 80%.
В целом, ScaleArc — хороший продукт с точки зрения производительности и функциональности. Я определенно рекомендовал бы это.
О ScaleArc для MySQL
ScaleArc для MySQL — это программный продукт, который прозрачно подключается между приложениями и базами данных для повышения доступности и производительности приложений. Он не требует никаких изменений в приложениях или базах данных и обеспечивает:
- Мгновенное масштабирование — прозрачный пул и мультиплексирование соединений, прозрачное кэширование на основе TTL, защита от перенапряжения
- Прозрачное масштабирование — разделение на чтение / запись, распределение нагрузки, маршрутизация запросов, сегментирование
- Автоматическая высокая доступность — автоматическое аварийное переключение
- Аналитика в реальном времени
Настройка бенчмаркинга
На клиентских машинах запущено программное обеспечение для сравнения, такое как sysbench, в случае этих тестов.
Процессор: 2 x Intel (R) Xeon (R) CPU E5-2620 v2 @ 2,10 ГГц (6 ядер, многопоточность чипа выключена)
Память: 64G
Мы использовали 2 клиентов. Результаты двух клиентов представлены отдельно, поэтому видно, что они прикладывают одинаковый объем нагрузки к базе данных или программному обеспечению ScaleArc.
База данных машин
Процессор: 2 x Intel (R) Xeon (R) CPU E5-2620 v2 @ 2,10 ГГц (6 ядер, многопоточность чипа выключена)
Память: 64G
Запуск MySQL Community Edition 5.6.15
Конфигурация MySQL
[mysqld] max_allowed_packet = 64M thread_cache = 256 query_cache_size = 0 query_cache_type = 0 max_connections = 20020 max_user_connections = 20000 max_connect_errors = 99999999 wait_timeout = 28800 interactive_timeout = 28800 log-error=/var/lib/mysql/mysql.err back_log=60000 innodb_buffer_pool_size = 3G innodb_additional_mem_pool_size = 16M innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 0 innodb_flush_method = O_DIRECT innodb_open_files = 2000 innodb_file_per_table innodb_log_file_size=2G innodb_log_files_in_group=2 innodb_purge_threads=1 innodb_max_purge_lag=0 innodb_support_xa=0 innodb_locks_unsafe_for_binlog = 1 innodb_buffer_pool_instances=8 sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
Буферный пул базы данных преднамеренно мал, поэтому легко создать связанную с диском рабочую нагрузку.
Обратите внимание, что следующие настройки не рекомендуются в производстве.
innodb_support_xa=0 innodb_locks_unsafe_for_binlog = 1
Мы использовали эти параметры для обеспечения максимальной производительности узла, избегая любых возможных накладных расходов, которые могут потребоваться в производственной системе. В типичных производственных настройках они не установлены, и двоичное ведение журнала включено, что потенциально снижает дополнительные издержки ScaleArc.
ScaleArc программного обеспечения прибора с
Процессор: 1 процессор Intel (R) Xeon (R) E5-2620 v2 @ 2,10 ГГц (6 ядер, многопоточность чипа отключена)
Память: 64G
Машины работали под ScaleArc для MySQL 3.0.
сеть
Машины были подключены с использованием 10G соединений.
измерения
Все измерения были сделаны с очень маленькой базой данных, которая полностью помещается в памяти.
--oltp-table-size=10000 --oltp-tables-count=64
В этих тестах мы ожидали, что и база данных, и ScaleArc будут привязаны к процессору. В случае связанной с диском рабочей нагрузки ScaleArc будет работать лучше, чем в этом тесте. Если запросы стоят дороже (они должны попадать в хранилище), издержки в% меньше, а в случае кэширования преимущество запроса по запросу больше.
Мы измерили 3 различные установки, как для случаев только для чтения, так и для чтения и записи. Это следующие.
- Прямое подключение к базе данных.
- Соединение с базой данных через ScaleArc, где ScaleArc действует только как сквозной фильтр (так как это балансировщик нагрузки, который говорит по протоколу проводных соединений MySQL, все механизмы для этого все еще действуют). Обратите внимание, что эта настройка не имеет смысла в реальной жизни. Цель этой настройки — показать потенциальные издержки использования ScaleArc и выявить потенциальные ограничения самого программного обеспечения ScaleArc.
- Подключение к базе данных через ScaleArc, где ScaleArc разрешено кэшировать. Кэширование в ScaleArc — это кэширование на основе TTL (Time To Live), что означает, что результаты запроса чтения кэшируются в ScaleArc. Если этот запрос на чтение снова виден до истечения срока его действия, он больше не запускается на сервере базы данных, а подается из кеша. По истечении времени таймера для кэшированного запроса запрос снова будет отправлен в базу данных. Кэширование, конечно, работает только для операций чтения, которые не входят в явную транзакцию (автокоммит включен и START TRANSACTION не выдается). По этой причине мы использовали –oltp-skip-trx во время кэшированных тестов (случай только для чтения). В случае этих тестов TTL составлял 1 час, потому что мы хотели насыщать программное обеспечение ScaleArc при обслуживании кэшированных запросов. 1 час TTL может быть нереальным для некоторых приложений,в то время как для других приложений даже 1-дневный TTL — это то, с чем они могут жить для некоторых запросов. В этом случае мы хотели измерить производительность кэша, поэтому мы хотели, чтобы запросы кэшировались в течение всего прогона теста производительности, чтобы показать потенциальный выигрыш даже в случае очень маленьких запросов.
TTL-кэширование
Важно отметить, что срок действия кэша контролируется значением TTL — других аннулирований нет, поэтому возможно чтение устаревших данных при изменении результатов запроса, но срок действия кэша не истек. Чтение устаревших данных само по себе нормально для большинства приложений, это может происходить с обычным асинхронным ведомым устройством, если оно отстает от ведущего (и всегда отстает). В противном случае кэш очень похож на кеш запросов MySQL, который не страдает от проблемы устаревшего чтения, но имеет грубую аннулирование (если таблица записывается, записи в кэше, принадлежащие данной таблице, сбрасываются). Пока кеш очищается, мьютекс кеша запросов удерживается, что блокирует четное чтение. Из-за мьютекса встроенный кэш запросов является очень обычным узким местом производительности. Кеш ScaleArc от этого не страдает.
Важно отметить, что ScaleArc по умолчанию ничего не кэширует. Кроме того, есть и другие способы активировать записи в кэше, кроме ожидания истечения срока действия TTL.
- Аннулирование на основе вызова API (вы можете очистить кэш для всего правила шаблона запросов одним вызовом API)
- Аннулирование запроса на основе комментариев (вы можете поместить комментарий / * wipe * / перед запросом и стереть и обновить кэш)
- Обход кеша (вы можете отправить комментарий / * nocache * / и обойти кеш для этого конкретного запроса)
Пропускная способность Sysbench только для
чтения
В нижней области потоков (до 32) мы видим, что значение TPS значительно падает в случае прохождения ScaleArc. В этом нет ничего удивительного, причина этого — сетевые обходы. Поскольку ScaleArc является программным устройством, он добавляет переход между базой данных и приложением, что вносит задержку. Если количество потоков больше (32 и выше), это начинает иметь значение все меньше и меньше, а производительность практически идентична, что очень впечатляет. Это означает, что при оптимальной степени параллелизма для этих машин ScaleArc вводит очень мало (едва поддающихся измерению) издержек.
Время отклика Sysbench
Этот график содержит время отклика, относящееся к предыдущим тестам. Это действительно трудно прочитать, потому что при 4096 потоках система перегружена, а время отклика намного больше, чем в области максимальной пропускной способности. Поскольку это на несколько порядков выше, интересное время отклика не читается из этого графика.
Следующий график такой же, как и выше, за исключением того, что ось y ограничена 250 мс, поэтому здесь видна область, которая не видна на графике выше. То, что мы видим там относительно накладных расходов, в значительной степени совпадает с тем, что мы видели в случае графика пропускной способности, что означает, что ScaleArc сам по себе вводит неизмеримо низкую задержку (что объясняет разницу в случаях, когда параллелизм низок). Обычно приложения, использующие сервер базы данных, используют значительно больше одного потока (в MySQL один запрос всегда использует один поток, другими словами, нет параллелизма внутри запроса). Задержка из 32 потоков выше на самом деле несколько ниже при прохождении через ScaleArc (точный переломный момент здесь может отличаться в зависимости от количества процессоров).Причиной этого является то, что сам ScaleArc использует цикл событий для подключения к MySQL, поэтому при высоком параллелизме может планировать отправку трафика в MySQL по-другому. Это имеет значение только тогда, когда в противном случае сервер MySQL насыщен процессором.
Загрузка процессора
Наконец, что не менее важно, этот график содержит загрузку ЦП различных настроек. С левой стороны показано использование процессора при подключении напрямую к базе данных, а с правой стороны показано подключение через ScaleArc. В обоих случаях узким местом является центральный процессор сервера базы данных. Видно, что ЦП клиентского узла простаивает более чем на 75% (для улучшения читаемости используется только client1, а client2 практически такой же). От 32 потоков и выше синяя полоса (CPU user%) относительно высока на серверах баз данных, как и зеленая (CPU sys%). Из 64 потоков время простоя практически равно 0, пока системы не будут перегружены. Справа мы видим, что ScaleArc при этой нагрузке все еще имел 50% простоя ЦП, что означает, что мы могли бы практически выполнить тот же тест на другом наборе блоков через тот же ScaleArc,и только тогда он будет полностью использован. Здесь мы говорим о 3000 системных сборных. Еще одна интересная вещь, которую стоит отметить — это относительно высокое системное время ibd. Это также связано с тем, как ScaleArc подключается к базе данных (см. Предыдущий абзац).
[ 17s] threads: 64, tps: 3001.98, reads/s: 41962.70, writes/s: 0.00, response time: 35.22ms (95%)
Эти потоки принадлежат одному клиенту, а это означает, что ScaleArc может справиться с разбором примерно 84000 операторов в секунду с использованием половины своего ЦП, что впечатляет. Обратите внимание, что программное обеспечение ScaleArc в этом случае было настроено на этот тип рабочей нагрузки, что означает, что у нас было больше потоков обработки запросов. В случае кеширования у нас будет больше потоков обработчика кеша.
Влияние кэширования на нагрузку только для чтения
Пропускная способность Sysbench
Следующий набор графиков будет сравнивать случаи, когда кэш используется и не используется.
Предыдущий график TPS содержит число операций чтения в секунду (поскольку мы измеряли с помощью –oltp-skip-trx), поэтому примерно 42000 операций чтения соответствуют примерно 3000 транзакциям в более ранней установке (14 операций чтения в транзакции). В левой части графика кешированная пропускная способность видна зеленым цветом — с правой стороны не кешированная пропускная способность видна с красным (прямой доступ) и синим (доступ через ScaleArc как сквозной фильтр). ). Видно, что кеширование резко повышает скорость, но когда ScaleArc становится перегруженным (8192 клиентских потока, 4096 от каждого клиента), производительность становится несколько непоследовательной, что понятно, учитывая, как мало ядер было запущено ScaleArc. На графике точки являются полупрозрачными, что означает, что цвета в областях, где больше образцов, более яркие. Даже в перегруженном случае,большинство образцов находятся в диапазоне 100k + операций чтения / сек на двух клиентах, что означает, что производительность очень изящно снижается даже при большой нагрузке.
Время отклика Sysbench
Как и в случае не кэшированной рабочей нагрузки, время отклика не слишком читаемо из-за очень высокого времени отклика, когда системы перегружены. Но из-за видимого перегруженного времени отклика кажется, что использование кэширования не ухудшает время отклика.
Как и в случае некэшированной рабочей нагрузки, этот график является увеличенной версией предыдущей. Здесь максимум оси Y равен 100 мс. Из этого графика видно, что при меньшем параллелизме и оптимальной пропускной способности кэширование фактически помогает сократить время отклика. Это понятно, так как в случае попадания в кэш ScaleArc может обслуживать результаты, и клиенту (в нашем случае здесь sysbench) не нужно переходить в базу данных, поэтому время обхода и обработки базы данных сокращается. Стоит также упомянуть, что данные «поступают из памяти», не имеет значения, попадем ли мы в кеш ScaleArc базы данных. Когда используется кэш ScaleArc, время отклика ниже, поскольку исключается дополнительная обратная передача в базу данных и потенциальная работа базы данных (например, анализ SQL).Это означает, что кэширование может иметь преимущества, даже если база данных помещается в буферный пул. Улучшение всегда зависит от рабочей нагрузки — кэширование помогает больше всего, когда оно может кэшировать относительно дорогие запросы, такие как агрегаты и запросы, попадающие в хранилище.
Загрузка процессора
Как и в предыдущем случае, предыдущий график показывает загрузку ЦП различных компонентов. В случае кэшированной рабочей нагрузки сам клиент гораздо более загружен (так как он быстрее получает ответы, он должен генерировать трафик быстрее). При такой рабочей нагрузке при использовании только одного клиента мы бы столкнулись с ЦП клиента как узким местом в производительности. База данных тоже интересна. При кэшировании его процессор практически не используется. Это связано с тем, что если запрос подается из кэша, он никогда не попадает в базу данных, поэтому загрузка ЦП базы данных будет ниже. Другими словами, использование кеша помогает разгрузить базу данных. Если на графиках ScaleArc видна разгрузка, то при использовании кэширования ЦП на сервере, на котором размещается ScaleArc, используется гораздо больше. Для этого теста программное обеспечение ScaleArc было настроено для обработки кэшированной рабочей нагрузки.что означает больше потоков обработчика кэша.
Читай пиши
Для тестов чтения-записи нам нужно было создать oltp_nontran.lua, который является тем же тестом sysbench, что и oltp.lua, за исключением того, что он выполняет чтение вне транзакции и выполняет только запись в транзакции, поэтому кэширование может оказать влияние на читать. Остальная часть настройки бенчмаркинга такая же, как и в случае только для чтения.
Пропускная способность Sysbench
Подобно случаю только для чтения, при низком параллелизме накладные расходы ScaleArc поступают от дополнительного сетевого обхода. При оптимальном параллелизме накладные расходы едва поддаются измерению (точки нанесены практически друг на друга).
Время отклика Sysbench
Случай очень похож на время ответа, как в случае только для чтения. Точно так же второй график является увеличенной версией первого, который максимум 250 мс.
Загрузка процессора
График загрузки ЦП показывает, что в этом случае узким местом является ЦП сервера базы данных. Что интересно, ScaleArc использует меньше ресурсов процессора, чем в случае только для чтения. Это понятно, поскольку транзакция теперь также содержит записи, которые являются дорогостоящими на стороне базы данных, но они по-прежнему являются просто операторами для маршрутизации на стороне ScaleArc.
Влияние кэширования на рабочую нагрузку чтения-записи.
Измерение кэширования здесь интересно, поскольку рабочая нагрузка больше не предназначена только для чтения и предназначена для чтения. У нас очень значительное количество записей.
За 30 000 операций чтения мы получаем 8,5 000 операций записи. Ожидается, что кэширование не поможет так же, как в предыдущем случае, потому что записи не могут быть кэшированы, и пока они находятся в процессе, потоки тестирования не могут продолжить чтение. Обратите внимание, что это означает, что примерно 25% трафика приходится на запись, типичное приложение, масштабируемое с дополнительными ведомыми устройствами для чтения, не имеет такого отношения чтения-записи.
Пропускная способность Sysbench
Первый график показывает, что с точки зрения общей пропускной способности кэширование по-прежнему помогает.
Как и в случае только для чтения, кэширование также помогает сократить время отклика, поскольку сокращает время, необходимое для чтения части рабочей нагрузки.
Загрузка процессора
Этот тест действительно нагружает процессор сервера базы данных, когда он не кэшируется. При включенном кэшировании, как и в случае только для чтения, рабочая нагрузка клиента несколько увеличивается (но не так сильно), а загрузка ЦП сервера базы данных значительно снижается. В последнем ряду загрузка ЦП ScaleArc показывает, что, хотя с кэшированием она несколько выше, она все же не намного выше.
Из этих тестов видно, что кэширование может быть полезным, даже если коэффициент записи такой же высокий, как в этом тесте.
Вывод
Инжиниринг — это всегда правильные компромиссы. Если кому-то нужны функции, которым нужен балансировщик нагрузки на уровне протокола, такой как ScaleArc, цена должна быть оплачена за счет разбора уровня 7 и принятия решений. Инженерная команда ScaleArc проделала большую работу, чтобы минимизировать эти накладные расходы. Сам ScaleArc очень хорошо настраивается для различных типов рабочих нагрузок (если важно кэширование, ScaleArc можно настроить для кэширования — если переписать запрос, ScaleArc можно настроить для этого).