Russian Qt Forum

Дали мне задания создать высоконагруженный сервер для приема, обработки и отправки информации. Так как я пока что "зеленый" и не имел дела с высоконагруженными серверами, а сделать надо за неделю то по глупости решил положиться на кьютовские сигнал/слоты.
Расчет делается на то что он должен выдерживать 100 000 соединений и каждое соединение раз в секунду шлет данные.
На прием, обработку, отправку(каждая операция производится в отдельном потоке) для одного соединения в лучшем случае составляет 4 междупоточных сигнала, то-есть целых 400 000 сигналов в секунду.
В интернете попытался найти информацию по производительности и наткнулся на статью в которой утверждалось что типа на процессоре i586-500 кьют позволяет отослать 2 000 000 сигналов. Ну успокоившись, этого-то точно должно хватить я решил потестить на своем Athlon 64 X2 4800+ (2.5GHz). И каково же было мое удивление что съев почти одно ядро кьют генерировал всего 80 000 сигналов. От чего так мало?
На какой более производительный аналог кьют сигналов можно наименее безболезненно заменить?

400000 сигналов в секунду. 400 сигналов в милисекунду...

Интересно, у вас программа сразу загнётся или нет? :P

Генерировать-то он может на вашем проце и значительно больше 2кк сигналов, а если через очередб, то ~800к в секунду (хотя вероятно зависит от аргументов).
А вот обрабатывать их у вас  вряд ли получится с такой скоростью.

Ну прямых вызовов за миллисекунду целых 500 000. Еслиб сигналы были всего-лишь в 100 раз медленнее, то было бы хорошо.

Ну так я сделал тест: три потока main, loop, sendLoop.
sendLoop после запуска посылает сам себе сигнал process. Функция process делает всего две вещи: посылает сигнал process и nextLoop потоку loop.
Функция nextLoop в loop делает всего одну вещь: инкрементирует счетчик.
main раз в секунду считывает счетчик и обнуляет его.
То-есть в результате sendLoop бесконечно генерирует сигналы и посылает их в loop, а loop тупо инкрементирует счетчик. И происходит это всего 80 000 раз в секунду. Я прям разочаровался, ибо если напрямую делать вызовы то получается от 300 000 000 до 1 000 000 000 (значения скачут сильно) вызовов. То-есть сигналы в среднем в 5 000 раз медленнее прямых вызовов, что печалит. Я надеялся что будет медленнее всего в 100-200 раз.

а давно высоконагруженные сервера на Qt писать стали?

Ну так ты сравниваешь прямой вызов метода (грубо говоря прыжок на адрес) с созданием и передачей объекта-сообщения через QEventLoop. Конечно межпоточные сигналы сильно медленнее получаются

А что Вы посоветуете использовать для высоконагруженных серверов? Просто не очень хочется использовать связку прямые вызовы + мьютексы, ибо я их нормально врятли смогу использовать.
Хочется просто информировать другой поток что он должен добавить в очередь выполнения функцию, и чтоб это максимально быстро было.
Было бы неплохо еслиб посоветовали литературу по этой области, ибо я даже не знаю куда копать.

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

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

с Qt вам не избежать проблем производительности, как минимум. в остальном все зависит от специфики задачи и ваших познаний. для распределенного сервера православно будет использовать erlang.

Я думал, что вы пример для теста сделали и с производительностью заткнулись, а если у вас целый проект уже, то можно только гадать где и что у вас тормозит.

Сам сервер щас работает нормально ибо нагрузка на него маленькая. Просто я решил проверить производительность сигналов дабы приблизительно понять их предел. Ибо когда начнет тормозить будет поздно что-то переделывать.

+пицот =)))

У меня вон запара сделать хотя бы 20 вызовов в мс, а тут целых 400 ;)

Странно, у меня 20 холостых межпоточных вызовов доходят примерно за 0.3 мс. А если сразу по 20 сигналов посылать, то доходят за 0.04 мс.
Я попробовал посылать по 50 сигналов за раз, так производительность поднялась до 500 000 сигналов в секунду. Только толку от этого нету. Я надеюсь что база данных начнет загибаться раньше чем программа упрется в производительность сигналов.

Кхм. я наверно неверно выразился :D

У меня запара в 20 полных(с анализом, обработкой, выводом) сигналов в мс. И это ток начало ;)

Попробуй юзать прямой вызов с QMutex по крайней мере тест показывает что он в 10 раз быстрее.
Я постоянно в гугле роюсь на эту тему но пока ничего нормального не увидел.

Та я уже разобрался. Ошибка была в моей архитектуре ;) Чуть чуть с мутексами запоролся.

Но спасибо на добром совете ;)


PS если ты про замену "сигналов" прямыми вызовами - то это верно. Я так их и использую. А сигналы они скорее для инициализации/гуи/передачи больших объемов у меня.

всегда был уверен в том, что на прогорг попадают исключительно по воле судьбы.
так, писать высоконагруженный сервер на куте - верх глупости. а основная глупость - кутя ;D
в добавок, 100 000 соединений, когда на одном интерфейсе можно создать максимум 65535, в идеале. обычно, 25-45 тыс. ибо я уверен в том, что сабжевый афтор даже не задумывался о необходимости мультиплексирования нескольких интерфейсов, и тем более не задумывался о способе реализации этой задачи.

в общем, :facepalm

niXman брысь с форума Qt. Ты недостоин его :)

А достичь примерно 120к возможно ;)

- сказал достойный мэн, подымая окурок с асфальта.

конечно! и ты мне расскажешь как ;)

Очевидно что "высоко-нагруженный стервер за неделю" - явная авантюра, ну наверно "так надо". И всем понятно что нельзя использовать весь комфорт Qt сигналов и одновременно выжать скорость - тут уж или туда или сюда. Так что простой ответ "нечем".

Однако "сигнал сигналу рознь". Возможно производительность удастся существенно поднять оптимизируя сами сигналы. Напр посмотреть сигналы передающие (большие) структуры по значению - там собака точно порылась..

все намного проще.
кутя для поллинга использует select() ;D и что еще более весело - на всех платформах! да еще и в нынешнее время, когда select() остался как дань прошлому!!! я всегда был уверен, что кутю производят кутешники ;D

О чем Вы говорите, большинство тут не знает что это такое. Зато с пенной у рта будут доказывать что написали супер-пупер-мега-сервер, который держит 120к)

и на одном интерфейсе!

ты тупой. нет там (в виндовых сокетах, например) селекта, ВНЕЗАПНО, да?

как скажете, дохтар ::)

нет.

может как-то в рамках все-таки нужно?
Или будем всем показывать насколько далеко Вы ушли от уровня быдла.

Сахаб. ты бы это говорил niXman у, который пришёл на форум, посвящённый Qt и повально его обсирает...

Я общаюсь с ним терминами, доступными его пониманию:) И да, он не вызывает никакого баттхерта. Просто он порет чушь и я его поправляю.

Ну во-первых он открыто никого не оскорбляет.
А во-вторых к его троллизме есть доля правды.
И что, если форум посвящен куте, так у нее нет недостатков?

пруф?

т.е. ты настолько "понимающий", что убежден в том, что я нет?

может ты таки покажешь нам всем, использование IOCP/epoll/kqueue для полинга?
или поступить с тобой как с break? ;)

Авварон, ты все правильно делаешь. иногда лучше жевать.

ну что ж, подытожим? ;)

1.

тыц (http://qt.gitorious.org/qt/qt/blobs/4.8/src/network/socket/qnativesocketengine_win.cpp#line1359) и тыц (http://qt.gitorious.org/qt/qt/blobs/4.8/src/network/socket/qnativesocketengine_win.cpp#line1406).
внезапно, да?

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

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

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

удачи :)

хех) заскринил для истории)

А вот, что думает по этому поводу сам микрософт: select function (http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=vs.85%29.aspx).

В драку лезть не буду, но все же оставлю пять копеек, я хоть и оч. люблю Qt и постоянно на нем кодю, но ни когда не стал бы писать высоко нагруженный сервер на нем, ИМХО с сетью он работает не так хорошо как тот же boost::asio, тем более в asio и возможностей побольше. Так что тут я полностью согласен с nixman. Не стучите пяткой в грудь защищая инструмент которым умеете пользоваться, ищите подходящий инструмент в зависимости от задачи.

Действительно, странные дебаты.
Qt - "all-in-one" инструментарий, который по определению не годится для узко-специфичных задач.

кончил?

Когда я смотрел в сокеты в последний раз, они под виндой ловили эвенты от системы, щаз я что-то этого кода не вижу, зато вижу селект.

select() я помню там с 4.6.2

В 4.6 он появился (коммит e5fcad302d), глубже копать лень. Я точно помню что они ловили системные события и это жутко медленно было.

Поглядел 4.5, там тоже был селект. Хз, откуда у меня память про эвенты.