Comments 9
Замечания:
1) коннект к мусклу вызывался каждый раз специально чтобы посмотреть на этот параметр;
2) если коннект вынести за предел цикла, то ситуация не сильно меняется;
3) в тесте 3 ситуация будет совершенно иная в рабочей ситуации, так как оверхед mysql-proxy будет перекрываться за счет шардинга
1) коннект к мусклу вызывался каждый раз специально чтобы посмотреть на этот параметр;
2) если коннект вынести за предел цикла, то ситуация не сильно меняется;
3) в тесте 3 ситуация будет совершенно иная в рабочей ситуации, так как оверхед mysql-proxy будет перекрываться за счет шардинга
Хотелось-бы понять причины таких значений в четвертом тесте, еще один линк на тестирование оверхеда mysql-proxyhttp://pero.blogs.aprilmayjune.org/2008/05/05/update-benchmark-hscale-with-mysql-proxy-070-svn-against-061/
какая версия mysql-proxy? где комплексные замеры остальных параметров? munin хотя бы влепили бы.
есть мнение, что все дело в однопоточной модели mysql-proxy версий ниже 0.8.
есть мнение, что все дело в однопоточной модели mysql-proxy версий ниже 0.8.
«mysql-proxy — практически идеальное решение для тех, кому нужен дешевый шардинг без переписывания приложений, а также хостинг провайдерам, которым сложно контролировать криворуких клиентов»
неправда. это практически идеальное решение для тех, кто хочет при наличии одних проблем (нагрузка) нажить ещё и других (прокси без переписывания кода)
навскидку я приведу вам парочку примеров «из жизни», от которых ваши администраторы станут спать ещё меньше, а пользователи начнут писать ещё чаще
1. лаг репликации
2. SELECT LAST_INSERT_ID()/mysql_insert_id()
это только вершина айсберга, но уже эти проблемы вы не сможете решить без переписывания кода.
неправда. это практически идеальное решение для тех, кто хочет при наличии одних проблем (нагрузка) нажить ещё и других (прокси без переписывания кода)
навскидку я приведу вам парочку примеров «из жизни», от которых ваши администраторы станут спать ещё меньше, а пользователи начнут писать ещё чаще
1. лаг репликации
2. SELECT LAST_INSERT_ID()/mysql_insert_id()
это только вершина айсберга, но уже эти проблемы вы не сможете решить без переписывания кода.
Скрипт из поставки rw-splitting.lua вроде бы специальным образом обрабатывает эти штуки. Но автор пишет, что со скриптами еще хуже масштабирование. в 0.9 обещает улучшить.
С репликацией, конечно, возможен облом, но думаете ушлых хостеров это остановит? Во многих случаях может нормально работать.
С репликацией, конечно, возможен облом, но думаете ушлых хостеров это остановит? Во многих случаях может нормально работать.
угу, я тоже читал (правда давно), что проблемы типа получения last_insert_id() скриптом решаются, но я верю, что всё равно остаётся ряд аналогичных проблем, когда даже в той же сессии читать нужно из мастера, а скрипт об этом не знает.
Еще есть синхронная репликация dev.mysql.com/doc/refman/5.5/en/replication-semisync.html
Правда, в mysql она синхронная только с двумя серверами. Непонятно почему не стали делать полностью синхронную.
Правда, в mysql она синхронная только с двумя серверами. Непонятно почему не стали делать полностью синхронную.
Объясните пожалуйста в чем великая плюшка разделения запросов на запись и на чтение по разным серверам? Проблемы такого подхода очевидны, а в чем преимущества?
По моему master-master репликация плюс балансировка на уровне соединений а не запросов гораздо более жизнеспособная схема.
Правда более чем на 2-х машинках я ее не разворачивал, но в теории должно работать. Вот только каждый новый мускуль добавленый в такое колечко репликации создает точку отказа.
По моему master-master репликация плюс балансировка на уровне соединений а не запросов гораздо более жизнеспособная схема.
Правда более чем на 2-х машинках я ее не разворачивал, но в теории должно работать. Вот только каждый новый мускуль добавленый в такое колечко репликации создает точку отказа.
4 тест. 1000 записей — это очень маленький объем данных для состоятельной оценки. Думаю mysql на слейве просто закешировал данные после третьего теста и в 4 отдал его вам быстрее.
Sign up to leave a comment.
mysql-proxy тестирование под мелкоскопом