| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Высоконагруженный TCP сервер
Eraser © (2010-06-03 16:13:00)Интересует любая правильная информация по созданию высоконагруженных (в плане количества установленных одновременно соединений от 1000 до сотен тысяч в перспективе) TCP серверов, скорее всего с уклоном на I/O Completion Ports.
Понимаю, что есть гугл, но хотелось бы получить правильнуюинформацию о том, куда копать и что читать от людей, которые сталкивались с этой темой. Примеры, даже простенькие, тоже не будут лишними ;-)
Спасибо.
DVM (2010-06-16 20:26:00) [1]
> Eraser © (16.06.10 18:34) [24]
> пока беглым взглядом глянул. На вид написано прилично.
Бывшим завсегдатаем этого форума написано вроде.
Eraser (2010-06-16 18:34:00) [2]> [23] Hello, Word (16.06.10 18:02)
пока беглым взглядом глянул. На вид написано прилично. Буду тестировать. Если подойдет, то сослужит хорошую службу, избавит от рутины.
PS
Инди даже не рассматривался как вариант, это отличные компоненты, которые давно служат верой и правдой, но совершенно для другого сегмента ПО.
Hello, Word (2010-06-16 18:02:00) [3]На Торри есть компонент HPScktSrvr, юзает Completion port. Быстрей ево не встречал. На Indy сервак при 300 клинтах за 50% проц грузит, тож самое на етом компоненте дает 1-2 %
http://www.torry.net/pages.php?id=220
Polevi (2010-06-15 12:03:00) [4]Транспортный поток акцептует клиентов, получает запрос, кладет в очередь запросов, следит за очередью ответов, отсылает.
Рабочий поток (пул) следит за очередью запросов, обрабатывает, кладет ответ в очередь ответов.
Обмен c сокетами через WSA ф-ии с CompleationRoutine, с рабочими потоками с использрованием GetQueuedCompletionStatus, PostQueuedCompletionStatus
Примерно так
Eraser (2010-06-06 19:36:00) [5]> [20] CrytoGen (06.06.10 19:30)
Речь не про прикладной протокол. В моем случае http хоть и возможен, но ни к чему. Повторюсь - см. сабж.
Я не спрашиваю про архитектуру, т.к. она давно известна и широко используется, интересуеют именно тонкости и нюансы реализации.
CrytoGen (2010-06-06 19:30:00) [6]http вроде бы позволяет поддерживать подключение и выполнять несколько запросов в ходе одного подключение, я так понял об этом и речь
DVM (2010-06-05 13:27:00) [7]
> Медвежонок Пятачок © (04.06.10 01:00) [8]
Установление соединения требует в разы больше ресурсов, чем поддержание. Не фат что будет более эффективно.
Медвежонок Пятачок (2010-06-04 19:08:00) [8]да ради бога.
пиши наздоровье свой сервер на сотни тысяч коннектов. пенсия еще поди далеко
Eraser (2010-06-04 18:38:00) [9]товарищ, см. сабж.
Медвежонок Пятачок (2010-06-04 15:31:00) [10]специфика не много другая. нужен постоянно работающий канал, к сожалению, по другому никак. другой велосипед не изобретешь, у всех конкурентов так.
никак это только потому что протокол такой. и больше не почему.
у моих конкурентов тоже проекта аналогичные моему работают как у тебя и как они работали ранее у меня.
я изменил протокол и теперь мне не нужен постоянный канал.
Eraser (2010-06-04 15:25:00) [11]> [13] Медвежонок Пятачок © (04.06.10 14:55)
> клиенты обращаются с нему с запросами.
специфика не много другая. нужен постоянно работающий канал, к сожалению, по другому никак. другой велосипед не изобретешь, у всех конкурентов так.
> у тебя там поди еще и каждая клиентская сессия порождает
> коннект к какой-нибудь базе данных и висит пока клиент держит
> коннект с тсп сервером.
нет, БД вообще не при чем )
Медвежонок Пятачок (2010-06-04 14:57:00) [12]у тебя там поди еще и каждая клиентская сессия порождает коннект к какой-нибудь базе данных и висит пока клиент держит коннект с тсп сервером.
здесь никаких ресурсов не хватит при таком количестве соединений.
Медвежонок Пятачок (2010-06-04 14:55:00) [13]Так что постоянно стучаться на сервер просто не реально.
стучаться не надо.
сервер обслуживает клиентов.
клиенты обращаются с нему с запросами.
если запрос не назрел, стучаться на сервер не надо.
Eraser (2010-06-04 14:44:00) [14]> [11] Медвежонок Пятачок © (04.06.10 10:22)
> Ежели имеется ввиду, что это клиент должен постоянно ждать
> управляющих команд сервера, то это другое дело.
да, именно так. других вариантов нет. реакция на команды сервера должна быть в районе 5 секунд. Так что постоянно стучаться на сервер просто не реально.
> Клиент что-то захотел - сформировал запрос. Выполнил post,
> назад получил результат и не отнимает ресурсы сервера до
> следующего раза
это не годится для моей ситуации. собственно сабж не об этом.
Медвежонок Пятачок (2010-06-04 10:22:00) [15]не подходит, в моем случае нужно все время ожидать получения.
Ежели имеется ввиду, что это клиент должен постоянно ждать управляющих команд сервера, то это другое дело.
Это просто прикладной протокол так у тебя спроектирован.
У меня тоже когда-то давно была похожая модель
Но я от нее отказался (правда совсем по другой причине).
Взял за основу http и убрал "многофазность" из старого прикладного протокола.
Клиент что-то захотел - сформировал запрос. Выполнил post, назад получил результат и не отнимает ресурсы сервера до следующего раза
Медвежонок Пятачок (2010-06-04 10:07:00) [16]все подходит.
жди себе на здоровье.
Eraser (2010-06-04 01:40:00) [17]> [8] Медвежонок Пятачок © (04.06.10 01:00)
> в смысле пришел - получил - отвалил.
не подходит, в моем случае нужно все время ожидать получения.
Медвежонок Пятачок (2010-06-04 01:00:00) [18]ем более, что, в моем случае, работа будет вестись менее чем с 1% соединений, остальные будут просто поддерживать связь
я в таком случае отказался бы от "голого" тсп и перешел бы к http.
украл-выпил-в тюрьму.
в смысле пришел - получил - отвалил.
Eraser (2010-06-03 23:48:00) [19]> Но это все равно очень сложно, программа должна быть очень,
> очень четко написано. Ошибки там уже не прощаются.
безусловно, но главное - с самого начала выбрать правильный подход, потому и задал здесь вопрос.
Eraser (2010-06-03 23:47:00) [20]> [5] Anatoly Podgoretsky © (03.06.10 20:10)
сейчас активно изучаю вопрос, вроде бы, если речь идет о десятках тысяч соединений (тем более, что, в моем случае, работа будет вестись менее чем с 1% соединений, остальные будут просто поддерживать связь), то можно отбиться легкой артилерий в лице одного сервера. все таки рекомендуют I/O Completion Ports, а ICS, на сколько помню, просто на обычных асинхронных сокетах построен.
| |
Страницы: 