Алгоритм высоконагруженного сервера

[JamS007]

Как сказал один человек на этом форуме: "потоки не плодят ядра в системе".

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

По моему лучший вариант в таком случае - количество тредов = количество ядер в системе. Сервер в таком случае функционирует приблизительно так:
В главном потоке обрабатываются все соединения. Каждое новое соединение проверяется в бан-листе и если его там нет - передается дескриптор сокета в наименее загруженный рабочий поток, в котором осуществляется последующая обработка клиента.

Коэффициент загруженности потоков определять каждый раз, когда нужно передать нового клиента.

[_govorilka]

А почему если надо всего лишь отдавать файлики в сеть просто не взять nginx? Чем существующие решения не устраивают?

Писать высоко нагруженный сервер на Qt... Мне, кажется, что вместо решение проблемы с нитями, тут надо подумать: "а нужны ли в данном проекте сигналы и слоты, которые в 10-100 медленнее обычных вызовов функций"...

Интересно, а кто-нибудь когда-нибудь вообще писал демоны на Qt, с такой нагрузкой, как здесь описано?.. Только не ради курсовой или диплома, написать и использовать не одно и тоже...

[RedDog]

А почему если надо всего лишь отдавать файлики в сеть просто не взять nginx? Чем существующие решения не устраивают?

Писать высоко нагруженный сервер на Qt... Мне, кажется, что вместо решение проблемы с нитями, тут надо подумать: "а нужны ли в данном проекте сигналы и слоты, которые в 10-100 медленнее обычных вызовов функций"...

Интересно, а кто-нибудь когда-нибудь вообще писал демоны на Qt, с такой нагрузкой, как здесь описано?.. Только не ради курсовой или диплома, написать и использовать не одно и тоже...

Сказали написать, хозяин - барин

[_govorilka]

Сказали написать, хозяин - барин

Но если сказали...

Очень много зависит от задачи: протокол, платформа, количество клиентов. Если протокол должен быть HTTP/HTTPS то всё-таки лучше взять готовый сервер, например nginx и завернуть его в обёртки на Qt, если уж сказали. Если протокол и безопасность передачи не имеет значения, то можно попробывать P2P, тогда у тебя получиться бесплатный кластер, пример использования torrent есть в Qt.

[brankovic]

Не так много, как top пишет. Большая часть памяти маппится, но не используется. 10000 тредов на тестах тянет легко...

А ты сам пробовал запускать или так думаешь? 

Только без кьют, примерно такой код под pthread, машина такая же (intel 4x core, 8Gb), плюс на чистом C. На счёт памяти сколько съела, так не надо setStackSize делать. В любом случае 92 мега это копейки для сервера.

У меня она откушала 92 Мб реальной (не виртуальной!) памяти и почти 20% процессорного времени (по мнению top'а).

Ну так это 10000 тредов _только_ переключающихся, и съела всего 20% core cpu time / 4 cores = 5% cpu time, не так и много, учитывая, что полезной нагрузки нет. А как только полезная нагрузка появляется, то 5% превращаются в 0.5%, просто треды не будут успевать отрабатывать.

Сказали написать, хозяин - барин

Я так думал, что задача учебная, для практики лучше nginx трудно сделать.

[BRE]

Только без кьют, примерно такой код под pthread, машина такая же (intel 4x core, 8Gb), плюс на чистом C.

А ты думаешь в Qt какие-то особые потоки? Или их как то "утолстили"? QThread это просто врапер над pthread (это под linux).

На счёт памяти сколько съела, так не надо setStackSize делать. В любом случае 92 мега это копейки для сервера.

На самом деле не важно использовал я setStackSize или нет. Установка размера стека влияет в первую очередь на виртуальную память выделяемую для процесса, реально же для стека каждого потока все равно выделилось по одной странице (4 Кб) физической памяти. А расширятся стеки будут при необходимости. Поэтому, для оценки затрат физической памяти и не важно какой использовался размер стека в потоке: 64000 байт как установил его я или 10 Мб (!) как установила бы его система по умолчанию.
Кстати, на стеки для 10 тысяч потоков нужно реальной памяти:
стек 4 Кб - 40 Мб
стек 8 Кб - 80 Мб
...
стек 64 Кб - 640 Мб
...

Ну так это 10000 тредов _только_ переключающихся, и съела всего 20% core cpu time / 4 cores = 5% cpu time, не так и много, учитывая, что полезной нагрузки нет. А как только полезная нагрузка появляется, то 5% превращаются в 0.5%, просто треды не будут успевать отрабатывать.

Нууу. Если программа, которая ничего не делая отъедает 5% процессорного времени, считается нормальной... 

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

[brankovic]

Нууу. Если программа, которая ничего не делая отъедает 5% процессорного времени, считается нормальной... 

Не совсем так. Как только даём полезную нагрузку, число тредов упадёт (скажем, до 2000 -- просто упрёмся в мощность цпу), после этого доля переключений станет 0.01%. Т.е. в тесте 5%, в реальной задаче меньше.

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

Ну да. Только один момент: железо по-мощнее уже есть всегда, поскольку есть кластера. А вопрос только в том, стОит ли платить 120 штук супер-программисту или дешевле платить 50 и на сэкономленные покупать по серваку в месяц. Тут чистая экономика.

[BRE]

Не совсем так. Как только даём полезную нагрузку, число тредов упадёт (скажем, до 2000 -- просто упрёмся в мощность цпу), после этого доля переключений станет 0.01%. Т.е. в тесте 5%, в реальной задаче меньше.

Ээээ... Что значит упрется в мощность цпу? А если нужно реально обслужить 5000 клиентов, пусть и с меньшей скоростью? А если 10000? Выход твой подход с этим не справиться?
А еще совсем недавно, каких нибудь 10 лет назад, вычислительная мощность компьютеров была послабей, а сервера были и клиентов обслуживали... 

Ну да. Только один момент: железо по-мощнее уже есть всегда, поскольку есть кластера. А вопрос только в том, стОит ли платить 120 штук супер-программисту или дешевле платить 50 и на сэкономленные покупать по серваку в месяц. Тут чистая экономика.

Да это все понятно.
Все идет к тому, что скоро хомячки будут сервера писать, на java.

[developer]

Ну да. Только один момент: железо по-мощнее уже есть всегда, поскольку есть кластера. А вопрос только в том, стОит ли платить 120 штук супер-программисту или дешевле платить 50 и на сэкономленные покупать по серваку в месяц. Тут чистая экономика.

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

Тут нужно найти золотую середину, или убедить супер-программиста работать за те деньги которие вы можете платить.

[brankovic]

А если нужно реально обслужить 5000 клиентов, пусть и с меньшей скоростью? А если 10000?

Тогда кластер + разбиение клиентов по слоям и будет хоть миллион клиентов. Ну хорошо, допустим випилен сервер на 10к клиентов, а завтра нужно держать 100к, так всё равно придётся разносить по машинам. Тут опять вопрос: сколько времени понадобилось на выпиливание (+отладка, сервер-то сложный), сколько это стоило? Не дешевле ли было прикупить компов для тривиальной реализации, а потом выпиливать сложный сервер? А если функциональность с низким траффиком, но нетривиальной логикой, насколько просто будет добавить новую фичу в сложный сервер?

Да это все понятно.
Все идет к тому, что скоро хомячки будут сервера писать, на java.

не совсем, просто супер-программисты научатся своё время ценить больше, чем ресурсы и да, перейдут на какой-нибудь питон. Это неизбежно, рано или поздно память и ресурсы процессора станут (почти) бесконечными. Уже сейчас есть такая тенденция: пишем по-быстрому на perl/php/python, потом переписываем на C, чтобы урезать расходы, в то время, как бизнес уже работает. Постепенно этап переписывания отпадёт.

[Igors]

Тогда кластер + разбиение клиентов по слоям и будет хоть миллион клиентов. Ну хорошо, допустим випилен сервер на 10к клиентов, а завтра нужно держать 100к, так всё равно придётся разносить по машинам. Тут опять вопрос: сколько времени понадобилось на выпиливание (+отладка, сервер-то сложный), сколько это стоило? Не дешевле ли было прикупить компов для тривиальной реализации, а потом выпиливать сложный сервер? А если функциональность с низким траффиком, но нетривиальной логикой, насколько просто будет добавить новую фичу в сложный сервер?

Я далек от всего этого веба (и слава богу), но мне было бы интересно узнать что то за волшебный "кластер". То есть можно написать "тупо" (1 коннект на 1 клиента) и потом "кластер" решит все проблемы? Если несложно, "на пальцах" поясните основные идеи

Спасибо

[ufna]

А первая ссылка в гугле не? )

[brankovic]

Я далек от всего этого веба (и слава богу), но мне было бы интересно узнать что то за волшебный "кластер".

Кластеры бывают разные, я имею ввиду не суперкомпьютерный кластер, а множество машин соединённых по лану в датацентре. Схема примерно такая:

Есть некий сервер, пусть отдающий файлы. Есть N машин, на каждой стоит такой сервер. Есть M "внешних" машин, на которых стоит nginx. Клиент обращается на одну из внешних M машин, nginx, в зависимости от слоя клиента, проксирует запрос на один из несколько из N серверов. Существуют нюансы, но в целом всё примитивно.