[Qt-interest] QSslSocket: poor throughput over long fat pipes ?

[Thiago Macieira]

Em Terça-feira 28 Julho 2009, às 18:11:26, Stephen Collyer escreveu:
> 2009/7/27 Thiago Macieira <thiago.macieira at trolltech.com>
>
> > Can you check if your Qt program is saturating one CPU? The Qt overhead
> > would
> > explain for a 3x performance drop compared to curl if the problem is CPU.
> > But
> > usually it isn't: the limiting factor is bandwidth and Qt should reach
> > the bandwidth limit.
>
> I've identified what may be the problem in my code, but have not
> yet had the opportunity to try it out on a faster network. I have
> logging statements in the code which should have been compiled
> out, but weren't (due to a screwup in a #define) and I've been measuring
> with logging statements present. When I correct this, via 127.0.0.1,
> I get a speed-up of ~5x so I'm hopeful that this is the problem.
>
> (I get about 35MB/s though - what machine are you running on to give
> you 600MB/s ?)

Intel Core2 Duo running at 2.13 GHz. I'm using the QNetworkReply unit test as 
a basis of comparison (tests/auto/qnetworkreply). Note that this test 
saturates the CPU first, so run it on an idle system (cachegrind reports that 
most time is consumed in memcpy):

4.5 debug:
./tst_qnetworkreply downloadPerformance uploadPerformance 
performanceControlRate
QDEBUG : tst_QNetworkReply::downloadPerformance() receive rate: 193951 kB/s in 
5001 ms
QDEBUG : tst_QNetworkReply::uploadPerformance() send rate: 343769 kB/s
QDEBUG : tst_QNetworkReply::performanceControlRate() The following are the 
maximum transfer rates that we can get in this system (bypassing 
QNetworkAccess)
QDEBUG : tst_QNetworkReply::performanceControlRate() receive rate: 445293 kB/s 
and 5001 ms
8,94s user 5,35s system 95% cpu 15,016 total

4.5 release:
QDEBUG : tst_QNetworkReply::downloadPerformance() receive rate: 329879 kB/s 
and 5001 ms
PASS   : tst_QNetworkReply::downloadPerformance()
QDEBUG : tst_QNetworkReply::uploadPerformance() send rate: 449401 kB/s
PASS   : tst_QNetworkReply::uploadPerformance()
QDEBUG : tst_QNetworkReply::performanceControlRate() The following are the 
maximum transfer rates that we can get in this system (bypassing 
QNetworkAccess)
QDEBUG : tst_QNetworkReply::performanceControlRate() receive rate: 611673 kB/s 
in 5000 ms

4.6 debug:
QDEBUG : tst_QNetworkReply::downloadPerformance() TimedSender::run receive 
rate: 250113 kB/s in 5001 ms
QDEBUG : tst_QNetworkReply::uploadPerformance() ThreadedDataReader::run send 
rate: 328438 kB/s in 5000 msec
QDEBUG : tst_QNetworkReply::performanceControlRate() The following are the 
maximum transfer rates that we can get in this system (bypassing 
QNetworkAccess)
QDEBUG : tst_QNetworkReply::performanceControlRate() TimedSender::run receive 
rate: 579193 kB/s in 5000 ms

4.6 release:
QDEBUG : tst_QNetworkReply::downloadPerformance() 
tst_QNetworkReply::downloadPerformance receive rate: 301412 kB/s and 5003 ms
QDEBUG : tst_QNetworkReply::uploadPerformance() ThreadedDataReader::run send 
rate: 392593 kB/s in 4999 msec
QDEBUG : tst_QNetworkReply::performanceControlRate() The following are the 
maximum transfer rates that we can get in this system (bypassing 
QNetworkAccess)
QDEBUG : tst_QNetworkReply::performanceControlRate() TimedSender::run receive 
rate: 583505 kB/s in 5001 ms


Note that the protocol being tested in downloadPerformance and 
uploadPerformance changed between 4.5 and 4.6, so you should take these values 
with a grain of salt.

However, the performanceControlRate is still the same. It basically is trying 
to use QTcpSocket and QTcpServer to transfer as much data as it can in 5 
seconds.


Another test to look at is QNativeSocketEngine:
4.5 debug:
QDEBUG : tst_QNativeSocketEngine::udpLoopbackPerformance()              
2066.3MB/4.9s: 413.3MB/s
QDEBUG : tst_QNativeSocketEngine::tcpLoopbackPerformance()              
4557.7MB/4.9s: 911.5MB/s

4.5 release:
[had problems rebuilding]

4.6 debug:
QDEBUG : tst_QNativeSocketEngine::udpLoopbackPerformance()              
2337.8MB/4.9s: 467.6MB/s
QDEBUG : tst_QNativeSocketEngine::tcpLoopbackPerformance()              
4912.5MB/4.9s: 982.5MB/s

4.6 release:
QDEBUG : tst_QNativeSocketEngine::udpLoopbackPerformance()              
2357.0MB/4.9s: 471.4MB/s
QDEBUG : tst_QNativeSocketEngine::tcpLoopbackPerformance()              
4907.9MB/4.9s: 981.6MB/s

Finally, QUdpSocket:
QDEBUG : tst_QUdpSocket::performance(WithoutProxy)      4127.34MB/5.00s: 
825.47MB/s
QDEBUG : tst_QUdpSocket::performance(WithoutProxy)      4123.44MB/5.00s: 
824.69MB/s
QDEBUG : tst_QUdpSocket::performance(WithoutProxy)      4632.81MB/5.00s: 
926.56MB/s

-- 
Thiago Macieira - thiago.macieira (AT) nokia.com
  Senior Product Manager - Nokia, Qt Software
     Sandakerveien 116, NO-0402 Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20090729/e7a4a158/attachment.bin