Всем привет!

Есть многопоточный сервер, в главном потоке сидит наследник QTcpServer'а и слушает порт, а принятые соединения раздает рабочим потокам, которые сам и создает при необходимости. Один рабочий поток может обслуживать несколько соединений. Характер вычислений, производимых в потоке для какого-либо соединения совершенно непредсказуем. Это может быть простой обмен сообщениями, может быть и запрос в базу, может быть обращение к ядру сервера за какими-то system-wide данными, могут быть вычисления, передача файлов, соединения могут быть защищенными SSL, короче, характер нагрузки на поток количественному анализу не поддается, т.е. нет прямой зависимости от количества подключений.

Вопрос в следующем: есть ли способ оценить нагрузку на поток (т.е. эффективность его Event-Loop'a) средствами Qt, и, если эта нагрузка превысит критический уровень, создать новый?

Держать каждое соединение в отдельном потоке и предоставить операционной системе разбираться самостоятельно может оказаться неэффективным, так как возможна ситуация с большим количеством неактивных/слабо активных соединений, и threading overhead превысит полезную нагрузку по обслуживанию клиентов.

такого способа нет, насколько я знаю.
можно, конечно, извратиться и сделать примерно так: задать функторам "вес" в относительных единицах (например, обмен сообщениями - 1, соединение с бд - 2, выборка данных - 5, запись в бд - 7, ...) и суммировать значения веса по ходу выполнения...даже звучит корявенько...

это вообще неэффективно...

Случай, где на каждое соединение используется отдельная нить не рассматриваем совсем из-за непомерных расходов ресурсов.
Случай, где несколько клиентов обслуживаются в одной ните. При формировании ответа для одного клиента, останавливаются обслуживание всех остальные клиентов в данной ните. Даже если для большинства клиентов данные уже сформированы и их нужно просто отправлять.
В случае с разделением, получаем следующее. Фронтэнд получает данные от клиента в буфер, если пакет пришел полностью, он передается на обслуживание бэкэнду и фронтэнд о нем забывает (или продолжает принимать следующие данные от клиента). Бекенд принимает решение, запустить другую нить для формирования ответа или при "легком" ответе сформировать его сразу и отдать его фронтэнду. Дальше уже фронтэнд имея данные для клиента небольшими частями начинает отправлять их клиенту.
Бэкэнд может подготовить данные для нескольких клиентов и фронтэнд непрерывно будет раздавать их с учетом возможности клиента (одни могут забирать данные медленно, другие быстро).
Потоки будут создаваться (браться из пула простаивающих) только для конкретных заданий. Передача не будет останавливаться при формировании ответов.

Т.е. ты успеваешь формировать данные для клиентов, но не успеваешь их отдавать?
Как происходит отдача? Ты же не пытаешься пропихнуть все данные одному клиенту разом?
Описывай? 

Достоинство описанного метода как раз в том, что он может отдавать данные практически одновременно всем клиентам в одном потоке. При необходимости, есть возможность масштабирования, например по количеству ядер процессора.
Главное это отдавать данные частями, а не упираться в одного клиента и пихать ему весь блок целиком. С каждым клиентом ассоциируется выходной буфер (это абстракция, может быть буфер в памяти, а может быть файлом на диске), если в нем есть данные они должны быть отправлены. В цикле проверяем для каждого клиента, если данные есть, отправляем кусок (chunk) и переходим к следующему клиенту. Размер "куска" можно задать фиксированным или проверять количество свободных байт в буфере отправки tcp-стека.
Этот метод легко ложиться на архитектуру Qt-сокетов, т.к. они работают по принципу не блокируемых сокетов.

Хммм. Поправь меня если я ошибаюсь. Насколько я знаю, буферизацией в данном случае занимается QIODevice, от которого отнаследован QTcpSocket. Т.е. данные из очереди на отправку сериализуются в сокет с помощью write() или QDataStream, сокет их буферизует, и уже сам решает, когда и какими кусками их отправлять. Отправив кусок, эмитит bytesWritten, который воткнут в слот моего объекта-клиента, где я проверяю, есть ли у сокета еще данные в буфере, и если нет, то сериализую туда следующий объект из очереди. Сокет, как я понимаю, работает асинхронно, в цикле событий потока. Так что я совсем не забочусь об отправке данных по частям параллельно всем клиентам - это должен за меня делать эвент-луп, который обходит все объекты, созданные в потоке, и говорит им, что делать. Сокет в момент вызова write() ничего никуда не пишет, а просто копирует данные в свой буфер. Когда метод, вызвавший write(), вернет управление циклу событий, и когда этот цикл дойдет до объекта сокета, вот тут-то кусок данных будет отправлен непосредственно на интерфейс, и проэмичен сигнал bytesWritten.
Это подразумевает выполнение в несколько потоков, так ведь? Пусть даже их количество фиксировано и равно числу ядер, но мне в любом случае необходимо будет при новом входящем подключении выяснить, какой их них наименее загружен, чтобы отдать это подключение именно ему. А как я раньше писал, в моем случае прямой корреляции между загрузкой потока и количеством обслуживаемых подключений нет. Хотя бы потому, что подключения могут быть шифрованными, что съедает немало процессорного времени, а могут не быть. Вот к тому и вопрос, как выяснить загрузку потока?
Какие есть мнения по поводу вот этого:
Какие тут могут быть подводные камни?

Плюс, можно назначать разные приоритеты на отдачу, одним клиентам отдавать по 100 кб за раз, а другим урезать до 20 кб.

Красиво но сложно   Почему не простенько: задачи принимаются и складываются в одну общую очередь. Каждая нитка берет следующую задачу из этой очереди как только закончит предыдущую. Число ниток просто фиксировано. Вероятно задачи могут быть зависимыми, напр задача "B" может требовать результатов задачи "A". Мне кажется не стоит решать это созданием новых ниток (напр. нитка не может принять "C" потому что она ждет "B", давайте создадим еще нитку). Лучше сохранять результаты/контекст а потом восстанавливать.