Какую архитектуру выбрать для многопоточного сетевого приложения на Qt?
Я разрабатываю приложение, которое выкачивает с сетевых камер изображения. Затем их обрабатывает. А потом по запросу отправляет результаты (json). Приложение Разрабатывается на Qt, так как мат. библиотека написана на C/C++.
Сейчас я использую QThreadPool, а точнее его global instance, в качества воркеров выступают классы наследованные от QObject(для работы сигналов и слотов) & QRunnable.
Предполагаю, что при большом числе камер и запросов данных могут начаться тормоза:
1. Из-за постоянного создания воркеров для загрузки и отправки данных, которые на самом деле отличаются лишь парой полей;
2. Из-за постоянного переключения контекста.
А теперь собственно сам вопрос:
Какая оптимальная архитектура для такого приложения, если оно разрабатывается на Qt?
P.S. Для загрузки и отправки данных используется QNetworkAccessManager
Надо минимизировать количество пере-подключений TCP, создавая каждый раз сокет или QNetworkAccessManager в QRunnable вы делаете переподключение.
QNetworkAccessManager не оптимален для вашей задачи, он преспособлен для загрузки сайтов. В нем по умолчанию есть 4 сокета и используются параллельно для запросов. Советую сделать примитивную реализацию HTTP на QSslSocket/QTcpSocket, чем проще тем лучше.
Сомневаюсь что у вас там 10 тыс камер, так что оптимальный вариант - запустить отдельный QThread для каждого подключения камеры, поддерживать его и доставать изображения с интервалом. Дальше указатель на данные изображения отправлять в накопительный QThread, который будет возвращять json по запросу.
Хорошая идея, правда вот QThread на камеру не пойдет, но это я не так сформулировал описание, заказчик сам складывает изображения с камер на сервер, а я тяну фотки с соответствующей камеры по https.
Denis: если сервер один то лучше все делать с одного QThread, по интервалу все доставать и указатель отправлять в другой QThread в котором уже QTcpServer выдающий json
Архитектура от Qt мало зависит.
Если у вас потоки серьезно грузят процессор (на 100%), то смысла заводить потоков больше чем процессорных ядер нет - быстрее уже не будет.
Поэтому делайте очередь и ограниченное количество потоков. Задания складывайте в очередь, а потоки будут сами из нее извлекать задания и обрабатывать.
Для работы с сетью можно попробовать асинхронный ввод/вывод.
Простой
