| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > запросы в MySQL в многопоточном приложение |
| Автор: boost0klr 3.2.2012, 00:25 |
| Добрый день. Есть необходимость использовать мускул в многопоточном приложение. разобравшись в С++ АПИ для мускула, завернув его в свои классы обертки, и локализовав это в отдельном потоке, который ждет запрос и отдает ответ всем остальным потокам, скорость приложения уперлась в производительность БД, т.е. в скорость потока работающего с БД. мне кажется я как-то криво пишу на плюсах что ли.. но с другой стороны.. не размазывать же запросы по всему проекту, кроме того мне кажется там что-то лимитируются сессии.. или что то ещё.. т.к. я экспериментально создал 1000 потоков с запросами в БД, и как то оно не празднично работает. кароче говоря, кто как интегрирует БД в проекты. и не могли бы вы наспамить ссылок на листинги, и т.п. материалы. з.ы. прошу простить за оффтоп, но пост ближе к плюсам и архитектуре чем к БД. Добавлено @ 00:28 у меня кроме как создать пул потоков работающих с БД умнее не получается придумать ничего, но там какие-то грабли.. и лениво их выкупать. помогите плиз. сроки((( |
| Автор: boostcoder 3.2.2012, 00:34 |
да ты че?! жесть т.е. все потоки лочатся на одном мьютексе? Добавлено через 1 минуту и 12 секунд и объясни задачу. откуда необходимость в более чем одном потоке? чем обусловлено? |
| Автор: boost0klr 3.2.2012, 08:27 |
| ну например, есть 20-30 потоков, у них там переменные всяке, и т.п. эту всю ерунду проще держать в базе, чем за хардкодить. ну вот.. все эти переменные необходимые им для работы, они получают из БД, через поток работающий с БД. и вот это мне не нра совсем. они встают в очередь ожидая пока поток работающий с БД раздаст всем результаты запросов. ну и конечно 1000 потоков не будет уменя, но будет много потоков, и хотелось бы максимально производительность приложения с БД ..приблизить к как будто бы она без БД)) ладно ..есть другой вариант. например при загрузке подгружаем из БД всё переменные в кучу, и потом работаем сней, по сигналу заново перечитываем настройки. При таком раскладе плевать на эти тормоза, и оставляем пул потоков для записи данных в базу. Мне так даже нравится. Доброе утро |
| Автор: boost0klr 3.2.2012, 11:15 |
| ну наконецто. т.е. самое главное.. что? запросы к БД не распаралелить? |
| Автор: boostcoder 3.2.2012, 11:48 |
распаралелить можно. но какого-либо повышения производительности это не даст. а даже наоборот. еще, распаралеливание запросов можно использовать чтоб эмитировать асинхронность. но опять же, никакого повышения скорости выборки это не даст. |
| Автор: boost0klr 3.2.2012, 11:57 | ||
если я правильно Вас понимаю, один поток, пул потоков, ..запросы БД выстраивает в очередь внутри себя???? и тут уже без вариантов.да? |
| Автор: boostcoder 3.2.2012, 12:03 |
да. мне не известны многопоточные БД... может кто-то подскажет. |
| Автор: azesmcar 3.2.2012, 12:56 |
| boost0klr Создавай по одному MySQL соединению на каждый поток, синхронизацию СУБД сама обеспечит. |
| Автор: boost0klr 3.2.2012, 13:31 |
| мне кажется при таких раскладах, когда из под одного процесса много запросов к базе.. через одно АПИ С++Мускл ..как то тупит оно.. не, не может такого быть? |
| Автор: azesmcar 3.2.2012, 13:34 | ||
Я честно говоря ничего не понял из вопроса, это кому предназначалось? |
| Автор: boostcoder 3.2.2012, 14:18 | ||
тут два тупика: 1. тупик производительности ФС. как правило, производительность БД ограничивается в первую очередь этим. 2. при работе с одной_БД/одним_сервером_БД - это не имеет смысла. Добавлено через 10 минут и 20 секунд
тут есть надежда на то, что сервер БД настроен на максимум кеширования в RAM. но опять же, про работе с одной БД, я почти полностью уверен в том, что запросы из нескольких потоков встанут в очередь. Добавлено через 11 минут и 11 секунд и не плохо бы узнать, какая именно БД используется. |
| Автор: azesmcar 3.2.2012, 18:09 | ||||
Во первых не все и всегда читается с диска, а во вторых выполнения запроса это далеко не только чтение самих данных, есть и много чего другого, что вполне можно выполнить параллельно. Если интересно, можешь посмотреть в профайлере на что было потрачено время при выполнении запроса, и далеко не всегда основное время тратится на чтение данных с диска. К тому же в базе может быть бизнес логика описанная в процедурах, чтения и запись данных вполне можно распаралеллить на нулевом рейде, я уже не говорю про кэширование. Другое дело, что оптимальное количество потоков для приложения не обязательно равно оптимальному количеству потоков в СУБД, но хуже от этого не будет, все равно где-то надо синхронизировать, пусть этим займется СУБД.
|
| Автор: boost0klr 5.2.2012, 14:27 |
| Парни, это всё понятно, вопрос в том ..имеет и смысл делать несколько потоков работающих с БД.. или один? вот смотрите, есть десять потоков, всем им нужно потреблять/производить данные для/в БД.. можно к ним добавить 11й поток.. в который первые десять отправляют запросы и ждут, либо 11й, 12й, 13й, 14й, 15й поток.. для обработки данных в/для БД т.е. пул из (например) 5ти потоков... пул работает на C++ MySQL API.. возникают сомнения что из под одного процесса и одного АПИ, весь пул будет работать корректно, и так же сомнения по поводу производительности пула, т.к. если всё встают в очередь, какая разница.. мне интересно кто как пишет.. кто как интегрирует БД в приложение. к примеру.. вам надо раздать 200 клиентам инфу с вашего сервера_приложения, которое берет инфу из базы, вы напишите пул? или один главный поток, который будет работать с очередями от клиентов? кэширование понятно, файловая система тоже понятно.. вопрос исключительно по архитектуре ПО. спасибо. |
| Автор: boostcoder 5.2.2012, 14:49 |
| я никогда не использовал несколько потоков для работы с БД. при том, с БД работаю. в одном из проектов, БД используют ~4000 юзеров. архитектура такая: сервер. юзеры коннектятся к серверу. сервер работает с БД в одной сессии. запросы в БД выполняются асинхронно по отношению к запросам со стороны юзеров, при помощи одного потока и http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio/reference/io_service/post.html. Добавлено через 1 минуту и 55 секунд я не проверял БД на предмет выполнения запросов из нескольких потоков. напиши микротест (код выложи), любопытно. |