Наслышан о том что с помощью asio можно написать сервер, который при прочих равных условиях выдержит большее число подключений чем сервер работающий по модели ОДИН КЛИЕНТ-ОДИН ПОТОК.

Вопрос:
Есть машинка с одноядерным процессором, на сервере производится длительная операция обращения к БД. Как в asio сделать так чтобы пока идет
работа с БД - остальные клиенты не проставивали ?

P.S.
С многопоточным сервером все понятно, пока идет длительная операция - остальные потоки работают, разделяя общее процессорное время.

выносить операцию с бд в поток %)
я хз как связана ваша бд и asio

Artemon, asio - это аббревиатура от асинхронного ввода вывода.
Там смысл несколько отличный от стандартных представлений. Если тебе надо что-то сделать, то ты вызываешь соответствующий метод передавая ему функтор, который должен быть вызван по завершении операции. Когда операция завершается, этому функтору передается код завершения (ok или ошибка). И ты из этого функтора уже заказываешь выполнение следующего действия... Таким образом, ты никогда не сидишь и не ждешь, пока выполнится какое-либо действие - в это время может выполняться другое.

Например, у тебя есть твой вэб-сервер, работающий с БД. При запуске сервера ты ставишь задачу: установить TCP соединение с сервером БД

И запускаешь io_service.run()...
Как только у тебя происходит установка связи с БД вызывается соответствующий функтор, и если все в порядке, ты посылаешь команду авторизации... После ее отправки ты ставишь задачу ожидания результата авторизации. В случае успешного результата ты отправляешь команду на открытие БД... Короче, работа с БД установлена. Теперь можно открыть TCP порт 80 в режиме приема соединений, ставишь соответствующую задачу.

При подключении очередного клиента ты опять ставишь задачу приема соединений, а так же задачу получения от него данных. Когда ты их получишь, ты ставишь задачу оправки запроса к БД... В это же время может быть принят другой клиент... 

Я ищу вариант чтобы от этого УЙТИ.



Каким образом он будет принят если основной поток (и единственный) трудится над выборкой из БД ?

Допустим я получил соединение от клиента, клиент запросил какие-то данные, чтобы эти данные выбрать из БД нужен огромный и сложный запрос, выполняющийся продолжительное время. Заранее не известно что будет запрошено.
Собственно когда я начинаю выполнять такой запрос я НЕ могу больше приянть соединение от клиента т.к. основной поток выполнения занят задачей выборки из БД.

Сейчас все хорошо работает в многопоточном сервере, но я ищу пути оптимизации и решил приглядеться к asio, но наткнулся на такой затык.

Artemon, раз ты такие вопросы задаешь, значит ты не понимаешь, как работает asio.

постановка задачи занимает практически нулевое время. Другими словами, функция постановки возвращается тут же. Долгий запрос будет выполняться в "фоне". Т.е. ты не должен ждать, когда он завершится. Ты поставил задачу отправить запрос к БД и все. Когда задача будет выполнена будет вызвана твоя функция, в которой ты только поставишь задачу "принять данные от БД" и все. После успешного приема данных от БД, ты ставишь задачу "отправить данные клиенту"...

Посмотри внимательно примеры под asio.

насколько я понял у asio есть 2 основных метода sync_read и sync_write в которые мы передаем  методы, которые выполнятся по завершению чтения или записи.

Допусти я сделал что-то типа  этого:



Когда завершится чтение - начнет выполняться метод ReadHandler. Но с чего это он будет выполняться в Фоне ?

нет.
есть синхронные(блокирующие): read() и write(). и есть асинхронные(не блокирующие): async_read() и async_write().


по хорошему, должен быть пул потоков в котором выполняется asio::io_service::run.
в таком случае, если пул интеллектуальный, он сам, в зависимости от thread_sleep_time(не знаю как на русском сказать), производит регулирование числа потоков.
при этом, вы, свой долгий_запрос_к_БД, можете запостить как любую асинхронную задачу. смотрите: http://www.boost.org/doc/libs/1_46_0/doc/h...rvice/post.html
это позволит интеллектуальному пулу потоков, учитывать время затрачиваемое на этот запрос. и он(интеллектуальный пул потоков) примет этот факт во внимание, и в зависимости от политики пула, он, возможно, будет добавлять/убавлять кол-во потоков.


не понял вопроса..

Это сообщение отредактировал(а) boostcoder - 27.2.2011, 02:26

Artemon, ты все перепутал.

boostcoder, 



Подозреваю что эта асинхронная задача будет реализовываться с помощью потока. Если для каждого клиента создавть такие задачи, то какой выигрышь от ухода от модели один клиент-один поток?

На счет интеллектуальности - для начала хотелосьбы разобраться, удастся реализовать сервер используя лишь один основной поток + асинхронные вызовы asio.



Каким образом данная строка выполнится асинхонно ?
Как раз таки я и думаю что затык будет именно в этом месте (возможно ошибаюсь).

Это сообщение отредактировал(а) Artemon - 27.2.2011, 18:31

RTFM  

Artemon, основное время при работе по сети расходуется на ожидание ответа от удаленной машины. Это может делать как ядро системы, так и приложение. Отличия только в том, какой вызов используется. Есть синхронный, а есть асинхронный. Отличия в том, что если первый ждет завершения выполнения операции, то второй не ждет. При завершении операции приходит определенный сигнал. Вот asio с этим и работает.

asio не позволяет выполнять какую то работу параллельно с другой работой, она позволяет выполнять ввод/вывод параллельно с другой работой. Что бы обращение к BD было асинхронным, оно должно быть оформлено в виде отправки запроса через сеть (например запись текста SQL запроса в пайп), и дальнейшего чтения ответа опять же через сеть.

В таком случае asio позволит время от отправки запроса и до получения ответа использовать для обслуживания других клиентов

во первых - зачем?
во вторых - а если БД локальная, какой смысл в interprocess-comunication?

Это вопрос к ТС, а то он пытается от asio добиться каких то чудес   
Никакого. Смысл будет, если БД удаленная

Чудес я добиться не пытаюсь, а хочу лишь понять насколько реально сделать сервер на asio, под сервером я НЕ имею ввиду простейшие чаты, эхо серверы и прочее, а серьезный сервер, выполняющий сотни различных команд, делающий сложный выборки, реализующий часть логики клиентского приложения и т.д.

При модели один поток-один клиент (+ блокирующие сокеты), все это можно сделать без какого-либо шаманства.
Изучаю asio с его асинхронной моделью, пока собственно никаких плюсов кроме асинхронной модели не обнаружил, хотя это даже не плюс, а предпосылка к тому плюсу, что можно избавится от потоков.

Тему не закрываю, хочу еще поэксперементировать и сюда запостить появившиеся вопросы.