Web server (boost.asio), Архитектура Опции

[crashsp]

Доброго времени суток, сейчас есть написанный winsock сервер , но изначально не был продуман вопрос нагрузки , ну вот в сети у нас появилось более 2000 устройств которые ломятся на него с периодичностью 15 сек , как следствие возникли проблемы , в принципе увеличили таймером на 1 минуту стало полегче , но в любом случая рано или поздно и этого станет мало...А мне надо как минимум 5000 соединений обрабатывать с адекватными задержками, дальше уже думаю делать распределение по другим серверам.

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

PS: Web Server потому что хочется за одно облегчить логику на стороне клиента.

Благодарю.

Сообщение отредактировал crashsp - 25.4.2012, 4:44

[Алексей1153]

crashsp, а в чём проблема то ? MFC прекрасно справляется с таким количеством соединений.
Протокол TCP/IP или UDP?
Железо у сервера какое ?

Как вариант - переписать на чистом SOCKET (вот совсем недавно реализовывал этот вариант):

1)поток с сервером
2)поток вычитки клиентов и отправки подтверждений протокола
3)поток отправки клиентам
4)поток обработки прочитанного

Сообщение отредактировал Алексей1153 - 25.4.2012, 6:12

[crashsp]

Протокол TCP/IP или UDP?

TCP/IP

Железо у сервера какое ?

4 cpu intel xeon , 2 GB RAM

а в чём проблема то ?

Вот текущая архитекрута :
Создается 50 потоков , все запускаются и ждут события для чтения и записи
CAsyncSocket принимает асинхронно соединения и складывает связанные с ними сокеты в std::queue<SOCKET*> , при определенном количестве сокетов в очереди ну скажем 3ех, помещаем их в свободные потоки и испускаем события по которому поток начнет читать данные, считал-> запись в лог -> работа с БД -> отправка результата обратно , как поток завершает операции с сокетом и обработкой пришедшей инфы он смотрит сразу в очередь что б взять следующий сокет и так далее . Этот вариант в принципе работает и сейчас нормально (1 минутный интервал еще не на всех устройствах) , не уверен что этот подход правилен и хочется пересмотреть архитектуру , вот и возникла идея сразу это еще и кросплатформенно решить.
Как по вашему такая архитектура себя поведет при нагрузки в 5000 соединений ? может и этот вариант стоит модернизировать и успокоится ? пакеты в принципе маленькие , БД Oracle, так что в принципе задержек в этом месте нет .