HTTP response time with QNetworkAccessManager is more when compared to Dlib and Libcurl

[ksranjith786]

Hi,

We are using QT application for a Client Server model, where we are using QNetworkAccessManager to call HTTP or HTTPS URLs (GET, POST & HEAD).

We have observed that the HTTP response time is more when compared to Dlib and Libcurl.

Could you please let me know how to optimize the QT logic to obtain quick response time. Or Does QT have any other API to call http url. ?

Regards
Ranjith KS

[ksranjith786]

Hi,

There is a difference of 260 msec with QT and LibCurl;

Regards
Ranjith

[the_]

@ksranjith786

Why not use libcurl then? (but I for myself would not recommend this)

[p3c0]

Hi @ksranjith786,

You have a good chances of getting better replies if you post this question on Qt Interest Mailing. It is probably related to QNetworkAccessManager's implementation.

[ksranjith786]

@p3c0 Our application is written completely on QT framework. Thus I am looking for better response time with QT api itself. I am looking for any alternative ways of using QT api for networking.

[kshegunov]

@ksranjith786

I am looking for any alternative ways of using QT api for networking.

Depending on how you connect your signals, the problem might not be in the QNetworkAccessManager at all. If you connect the signals to slots in the main thread, then the delay may be caused by the main thread's event loop being busy with other things. Perhaps you could provide a minimal snippet for how you set your communication?

Kind regards.

[ksranjith786]

Our application is multithreaded, where each thread can have concurrent http(s) requests.
The code snippet of the each thread is as given below. We did not use any EventLoops here.

QNetworkRequest request;
request.setUrl(QUrl(strURL));
request.setHeader(QNetworkRequest::ContentTypeHeader, "application/json");

QNetworkReply* m_pReply = m_pNetworkMgr->post(request, aData);

connect(m_pReply, SIGNAL(finished()), this, SLOT(ProcessReply()));
connect(m_pReply, SIGNAL(error(QNetworkReply::NetworkError)), this, SLOT(ProcessNetworkError(QNetworkReply::NetworkError)));
connect(m_pReply, SIGNAL(sslErrors(QList<QSslError>)), this, SLOT(ProcessSSLError(QList<QSslError>)));

[kshegunov]

@ksranjith786
Hello,

Our application is multithreaded, where each thread can have concurrent http(s) requests.

QNetworkAccessManager is threaded internally, and the requests are executed according to that without you starting any threads. That said, if the provided code sits in its own thread, then only the response processing (that is the slot connected to the replies' signals) is executed in your thread.

See also the note here:
"Note: QNetworkAccessManager queues the requests it receives. The number of requests executed in parallel is dependent on the protocol. Currently, for the HTTP protocol on desktop platforms, 6 requests are executed in parallel for one host/port combination."

The code snippet of the each thread is as given below. We did not use any EventLoops here.

If you don't override QThread::run, which you shouldn't, each thread has an event loop, and in this particular case that event loop is used to invoke your slots.

[ksranjith786]

Could you please provide guidelines or code snippet to use QNetworkAccessManager using multi threaded env.

[kshegunov]

@ksranjith786 said:

Could you please provide guidelines or code snippet to use QNetworkAccessManager using multi threaded env.

No, I can't, sorry.
Not that I don't want to, but I don't know of any way you can control the number of threads QNetworkAccessManager uses internally (I think it's hardcoded). If I were to do multithreading with NAM I'd do it like you - thread the reply's processing. Unfortunately this bears no weight on the HTTP response time.

On a related note, I would always prefer to use TCP/IP directly, as it provides much more fine-grained control of what's happening (including threading). The downside of that approach however, is that it'd require implementing the HTTP protocol by hand.

Perhaps, as @p3c0 suggested, you could try to ask the question on the mailing list were you might get responses from the actual developers of the module.

Kind regards.